Users appearing from nowhere in sys_user??

[jlaps]

Very strange issue we are having. We sync users in via LDAP. As part of this, I datestamp LDAP REFRESHED (datetime) to track the last time things synced in addition to the usual fields on sys_user. We will get incidents in for a user that is unable to login to the portal, and when investigating it, it is always because of a duplicate USER_NAME or duplicate email address colliding in the SSO resolution.

The issue is that the duplicate that 'appears' is from YEARS ago (last updated 5 years ago, created 7 years ago, LDAP Refreshed NEVER). These accounts are for people that are gone, accounts were not present in sys_user, at least not with the duplicate userID... its like zombies are coming back to life out of nowhere.

The history on these zombie accounts look just like a 5 year old account should. The history on the current account with same user_name also looks like it should. And yet, suddenly today a zombie raises from  the dead and prevents a user from logging in SSO.

Where can these accounts be appearing from? How can they be appearing with 5 year old create/update dates? How can they be created when never having been synced from LDAP? Honestly stumped, hoping for some possible bread crumb trails I can follow if you have any ideas.

Thanks!

[Maik Skoddow]

Hi @jlaps 

This is indeed a perplexing issue that points to several potential root causes in ServiceNow's user management and LDAP integration. Based on the symptoms you're describing, here are the most likely explanations and investigation paths:

Data Restoration or Import Activities

The most probable cause for zombie accounts appearing with historical timestamps is unintentional data restoration. These could originate from:

• Update set imports that contained old user records from development or other instances

• Data imports from CSV files or other sources that included historical user data

• Instance cloning or refresh activities where old data was merged back into production

• Third-party integrations that may have reintroduced old user records

The fact that these accounts show "LDAP Refreshed NEVER" while having legitimate-looking history strongly suggests they weren't created through your current LDAP process.

Transform Map and Coalescing Issues

Your LDAP integration may have coalescing problems that are causing old records to resurface5. Check your transform maps for:

• Multiple coalesce fields that might be matching against old, inactive records

• Coalescing on non-unique fields like display names or partial identifiers

• Transform map changes that altered how user matching occurs

The community discussions indicate that improper coalescing configuration is a common cause of duplicate user creation during LDAP synchronization.

SSO and Authentication Conflicts

The SSO resolution issues you're experiencing are well-documented problems when duplicate email addresses or usernames exist. ServiceNow's SSO process queries the sys_user table and may return the first match regardless of the active status, which explains why inactive zombie accounts can interfere with current users' authentication.

Investigation Steps

Audit Trail Analysis:

• Check the sys_audit table for these zombie accounts to see if there are any creation or modification entries that don't align with the displayed timestamps

• Review sys_import_set_run and sys_transform_entry tables for any recent imports that might have included these users

LDAP Integration Review:

• Examine your transform maps, particularly the coalesce settings

• Check if there have been any recent changes to LDAP server configurations or transform scripts

• Review the sys_user_grmember table to see if group memberships were also restored

Update Set Investigation:

• Review recent update set installations that might have included user data

• Check if any development-to-production migrations included user records

Immediate Remediation

Short-term Fix:

• Implement a scheduled job to identify and deactivate duplicate accounts based on your LDAP refresh timestamp logic

• Create a business rule that prevents duplicate usernames or emails from being created

• Consider making the email field unique in your sys_user table configuration

Long-term Solution:

• Establish proper coalescing on immutable fields like objectGUID from Active Directory

• Implement monitoring for duplicate user creation

• Review and tighten your data import and update set processes to prevent user data from being inadvertently restored

The pattern you're describing - old accounts with never-refreshed LDAP timestamps suddenly appearing - strongly suggests these records are being reintroduced through some form of data import or restoration process rather than being created by your LDAP integration. Focus your investigation on recent system changes, imports, and update set activities to identify the source.

Hope that helps!
Maik

[Ankur Bawiskar]

@jlaps 

check duplicates in sys_user based on user_name or email including inactive users.

If my response helped please mark it correct and close the thread so that it benefits future readers.