LDAP Integration Best Practices to Handle Name Changes

MGanon · ‎06-11-2019

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 · ‎06-11-2019

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).

View solution in original post

MGanon · ‎06-13-2019

Deleting Records: Sorry for not being clear. By deleting records, I was referencing the (hopefully accidental) deletion of an LDAP user in the LDAP application such as Active Directory. The new LDAP user would have a different GUID so would be a different ServiceNow user.

That leads to a follow-on question: how does ServiceNow detect an account that is no longer in AD?

GUID location in ServiceNow: Thank you for the confirmation. As we want to avoid new fields whenever possible, I wanted to ensure that you added the new field in case I missed an available alternative.

Thanks again

TrevorK · ‎06-13-2019

As far as I know, ServiceNow does not have an Out-Of-Box way to detect someone is no longer in AD. Instead you have to build in your transform to do it. For example, you could have a flag set to indicate a user is (or is not) in AD as of the last import. It sounds a little strange but I have not personally come across with a better way.

Even if you sync other attributes like last AD Login Date/Time, you could have a user on a 1 year leave that simply does not log in during the time.

So I think the most reliable path is taking it in your own hands and using the flag. This will always be correct and does not rely on some series of logical conclusion (e.g. if the user has not logged in for 6 months they were removed from AD).

I double checked the sys_user table and could not see a value for GUID. We have been with ServiceNow since Aspen release so it's very possible there have been updates and such as we do not look for updates in this area (it works exactly how we need), I just don't see any off the top of my head.

MGanon · ‎06-13-2019

Also, in which field do you store the LDAP GUID?

TrevorK · ‎06-13-2019

We had to create a custom field on the sys_user table to store the AD GUID. There were several key fields missing we found, such as LDAP DN, that we have had to create that allow us to better manage our users.

MGanon · ‎07-16-2019

The objectsid query will not manually populate an import set if the samaccountname does not match. I opened a separate question for that.