LDAP looking at samaccountname - Need to change to ObjectID

Andy_B
Tera Contributor

‎01-21-2025 04:58 AM

Our ServiceNow instance was set up many years ago and as far as I can tell it is creating new user accounts based on the samaccountname in AD.  This works well, every new account created in AD gets an account created in ServiceNow.

 

The issue we have has been highlighted by a person who recently had a name change.  When they next logged into ServiceNow (which uses SSO) all of their recent requests were gone.  What we realised is that ServiceNow has spotted a "new" samaccountname so has created a new ServiceNow user account.  SSO then logged them into this new account.

 

A colleague recently found the attached list showing samaccountname as the one true coalesce.  

 

Can anyone tell me - in as dumbed down fashion as possible so I stand a chance of following the instructions - how we would go about altering what ServiceNow is looking at to be the ObjectID that I can see for all Azure user accounts?  My hope is that ServiceNow would then update the existing user account with the new UPN, samaccountname and other name fields (just as it does when we change their job title or manager name) instead of creating a new account.

 

Also... will this only work for future name changes and not correct historical ones (or worse there will be conflicts with unique identifiers on 2 accounts)?

 

Many thanks

Andy

Preview file
74 KB
0 Helpfuls
  • 543 Views
1 REPLY 1

JenniferRah
Mega Sage

‎01-31-2025 07:23 AM

We did something similar. Basically, you have to do this: 

  1. Create a field in the user record to hold the Object GUID.
  2. In your transform map for your LDAP connection, add a mapping from the Object GUID field to your new field.
  3. Set coalesce on the Object GUID field to true.
  4. Set coalesce on the samaccountname to false.

Now the trick is that I don't remember what happened when we first did this. You may need to do steps 1 and 2, run a sync to get the data, then do steps 3 and 4 so that it doesn't create duplicate records. Most definitely take a backup of your user table before doing this, and optimally do it in a test environment first, if possible.

0 Helpfuls