Hello -
I am trying to find what the best practice is to manage our sys_user table and importing records into with LDAP.
Currently, we have it setup to import any new records built within Active Directory on a nightly basis as well as deactivate any that have been deactivated. This works fine.
Some of the attributes we capture in our Import from AD to determine if this is a unique/new record are: givenname, sn, samaccountname, userprinciplename, objectguid (this is a main one I am having issues with).
The problem I am running into: In our environment, we delete Active Directory accounts after a number of months of being disabled (6 months).
This does not delete the sys_user record in ServiceNow as we would not really want that (I think).
So to the problem: once an account is disabled and deleted in Active Directory, if the employee is rehired AFTER their original account is deleted, a new account is then built for them, usually using the same samaccountname they previously had (ex: John.Smith). This new AD object now has a NEW objectguid which is one of the main attributes we use to determine if ServiceNow needs to create a new record in the sys_user table for that. BUT, becasue there is already a deactivated sys_user account with the same samaccountname, or User ID, BUT a different objectguid, it ignores creating this record.
I should also mention, we created a custom field called 'u_adguid' which this objectguid attribute gets passed to, and ServiceNow encrypts this field as well, so when looking at that on the sys_user record, its not the same as what is actually in AD's objectguid attribute.
I have been having to manually look up any errors on the scheduled LDAP load and manually go in to any old, deactivated accounts in the sys_user table with the same User ID and append the User ID with a ".old" or something similar. Then the next time the scheduled load runs, it will import that new AD object record.
What is the best way to handle this? What is recommended in this scenario?
