LDAP Integration Best Practices to Handle Name Changes

[MGanon]

Hi,
Our LDAP populates ServiceNow users and groups using the account name as the integration key. What are some best practices to accommodate changes to the account name? We don't to orphan the record with the previous name.

[TrevorK · Accepted solution]

I think it would depend on your AD Account renaming procedure. How ServiceNow handles it will depend entirely on how you handle it in AD.

We used to do it how you did - with the account name being the link. It became a problem for the exact reason your specified, account renames. For a bit we did those renames manually in ServiceNow and then decided to look for a better way. So we now coalesce on GUID.

For example, say we have John.Doe changing to John.Smith. We would rename John.Doe to John.Smith. We then create a placeholder account titled John.Doe from scratch so that no one can ever claim that user name again (for us this can cause a whole host of problems that we really do not want to deal with).

In this scenario we coalesce on the GUID. The GUID is the unique identifier attached to each AD Account (like a sys_id in ServiceNow). Because we rename the account the GUID stays the same, and therefore ServiceNow is updated with the new account info like any other field.

Renaming the account and keeping the GUID the same is what makes it super simple for AD management. Keeping the GUID the same means no issues with everyday items like folder permissions, group memberships, etc. Again just like the sys_id in ServiceNow allows you to change any element of the record but still retain things like the relationships.

I would suspect many organizations handle it like above because it's just the simpliest way to do it without introducing any potential loss of service (e.g. someone delegated their calendar and because the GUID is the same it just works).

[MGanon]

I suspected a similar approach. Thank you for the confirmation. How do you accommodate entries that are deleted and readded?

[TrevorK]

Luckily that's a problem we do not have to deal with. Our policy is to not remove AD accounts but to manage them. Because of the nature of our business we routinely have staff members who leave and come back (in the same or different capacity) and we disable accounts / remove access, not delete accounts.

Even when we do a rename (e.g. marriage, divorce) we create an account with the old name as a placeholder so that no one can use it again. Helps to prevent mistakes from happening - such as someone receiving email they should not simply because our president had the same username previously.

Our initial path was based on username - we ran into the same issue you did with renames. At first we had, as part of our procedure, to rename the SN account to the new name before it sync'ed with AD. This just required more coordination / effort as our staff that administer AD accounts do not administer SN accounts.

We have moved towards using a .NET app that was developed to do all our AD management. This helps to remove people from mucking around and forces them to follow our process. The eventual goal as I understand is that people should not be using AD Users and Computers to manage, but this custom tool so that our process is respected every time.

[TrevorK]

I should note - one strategy we discussed for fixing this is creating a flag in SN for "AD Account Removed". When ServiceNow detects an account that is not in AD this flag is set to true. Then we can still sync it up if it magically appears again and remove that flag.

You would never want to remove accounts out of SN since it orphans all their associated records (e.g. tickets). This strategy should work provided your process indicates you do not re-use names. Obviously if the username John.Smith can be handed out to any John Smith at your company and reused multiple times for different people then it's probably not a good idea.