- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎09-08-2016 11:25 AM
The issue I'm describing is mostly from poor business policy but I won't get into the politics of it. I know it's bad practice.
We have a policy to allow usernames to be changed in AD. They use user ID markers to identify them as consultant or a FTE. When a conversion occurs, they change the user ID. This causes issues in ServiceNow because whenever the username is changed in AD, a new account is created in ServiceNow for the same person. What I'm looking for are for any solutions that would prevent this on the ServiceNow side. I've thought about coalescing on email address as well however that address may change in certain situations (like marriages and divorces). We're currently coalescing on user ID. This also occurs when a username is misspelled.
Any ideas that could prevent this from the SN side other than policy changes?
Solved! Go to Solution.
- Labels:
-
Service Mapping
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-07-2016 03:21 PM
I'm answering my own question if anyone else needs a straight forward solution.
It seems that the addition of GUID information via LDAP is the way to go. This is unique to each user regardless of the information displayed in any of the standard fields. Normally this wouldn't be an issue however because of our lack of policy around User ID changes, this is necessary.
As for added enforcement, a business rule was added to prevent the insertion of the same user ID in the case anyone decides to manually add a user account in ServiceNow.
Cleanup of duplicate users was still necessary however from the point you coalesce on the GUID, you won't run into issues with ID changes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-22-2021 12:35 PM
You're not creating anything new other than adding another field to the user table to capture AD GUID information.
You'll also need to add this new AD field into your transform to get it added to user accounts.
Additionally, you'll need to place rules in the transform to check against the GUID to make sure they match the target account. This will allow for user accounts to update if there's a username change. This should also mitigate any duplication as long as the GUID is the same in both AD and ServiceNow.
This will not exactly help if you have AD deletion policies. Deleting and/or recreating accounts will break the sync process and will not allow accounts from being imported if there's a conflict with usernames or GUID. This requires manual intervention if there are conflicts.
If your organization keeps accounts forever in AD or if they can create unique usernames, even if it's for people with the same name, you should be ok as accounts will always be one to one. These are big ifs however.
Make sure you try this in a dev/test environment first. You don't want to end up duplicating everyone if there's an error. You're only pulling the AD GUID information into the user table first.
You can then build out the logic to either update or ignore the user changes based on the combination of the username and GUID.
Generally:
- If the username matches and GUID mismatch, ignore (eg do nothing)
- If the username matches and GUID matches, update the target record
- If the username mismatches but GUID matches, update the target record
- If the username and GUID mismatch, insert the record (eg new record)
