How to handle two users who have same userID for domain accounts

[basher959]

We have two different AD imports being loaded into one ServiceNow instance (sister companies). We came across a user in each domain with the same domain account name and ServiceNow doesn't like this. When one of the two users attempt to log in, ServiceNow refuses to authenticate them even though there is nothing wrong with their LDAP data.

Are there any fixes for this?

Thanks,

[Mark Stanger]

Only fix is to ensure that all user IDs are unique. It has to be that way. In domain separated environments, email address usually works best.

[Tim_Berger]

We aren't using Domain Separation, but we are filtering work group visibility by the Group names. These groups must remain private. Example: Group A - has a specific private function but has 1 user ID that has the same ID as someone in Group D who has a separate private work function. These Groups have separate roles and responsibilities and never interact with each other. Can this "Group name" be used to prevent a User ID conflict?

[paul_pearce]

Short answer, no.
If you wanted to modify the BusinessRule that looks for duplicate UserID and modify it so that it concatenates userID and GroupName, this would still not overcome the issue of logging-in without unique UserID.

[Aaron40]

I worked in a massive global company who had two (going on three) AD domains feeding user accounts. This caused a whole lot of headache because the environments weren't perfect, we had duplicate userids across the domains. The duplicate userids happened to be the same user, we just onboarded them into our new AD feed as well as the legacy AD feed.

This caused problems when it came to getting updates through LDAP. Each feed would get greedy and overwrite the other (whenever an update was made or when we did our nightly feed pull).

To fix this I wrote an onBefore script that checked the source of the user and made sure no other source could modify those fields. This prevented AD 1 from overwriting accounts created by AD 2. If someone later said "we need our account coming in from AD 1", all we'd have to do is clear the "source" field on the user record and run the AD 1 ldap feed which would then gain control over the user account.

It's messy but that's the best solution I had at the time to allow a multi domain environment to bring and update users into a centralized SN environment.

On a side note: You'll also run into some odd behavior if you have two DIFFERENT user ids in different domains but the userids both use the same email address. ServiceNow does not work well when multiple people share the same email address, especially when it comes to approvals and determining if an account is active/inactive.