User Directory sync fails with message Trying to rename user but no user key is mapped in Jira
Platform Notice: Data Center Only - This article only applies to Atlassian products on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
When performing a User Directory synchronization, it fails and in the logs we can see:
1
2
2021-05-24 19:13:00,029+0000 Caesium-1-4 ERROR ServiceRunner [c.a.crowd.directory.DbCachingDirectoryPoller] Error occurred while refreshing the cache for directory [ 10200 ].
java.lang.IllegalStateException: Trying to rename user 'someusername#2' but no user key is mapped.This error is also related to Jira throws error user exists but has no unique key mapping on login, which manifests upon a login attempt, not the User Directory sync.
Environment
All versions of Jira Core 7.x and 8.x.
User Directory synchronizing to MS Active Directory or Azure AD.
Diagnosis
1) Log message
The User Directory full synchronization should fail constantly with a message similar to the one below, given "10200". is the directory Id, and "someusername", a user that's being synced.
1
2
2021-05-24 19:13:00,029+0000 Caesium-1-4 ERROR ServiceRunner [c.a.crowd.directory.DbCachingDirectoryPoller] Error occurred while refreshing the cache for directory [ 10200 ].
java.lang.IllegalStateException: Trying to rename user 'someusername#2' but no user key is mapped.2) User Management
In Jira's User Management, search for the username "someusername". You should see at least 2 entries and at least one with a # and a number after it, like #1, #2, etc.
3) Database
Run the below query in Jira's database. It should bring at least one result, and the same username in the logs should be present (eg "someusername#2"):
1
2
3
4
SELECT lower_user_name
FROM cwd_user
WHERE lower_user_name NOT IN (SELECT lower_user_name FROM app_user)
ORDER BY 1;Cause
Active Directory allows renaming users, and Jira should understand this scenario — unless there has been some other User Directory config change that could compromise Jira's detection of unique (and correct) users.
Usernames should be unique in Jira, and whenever it finds a conflict (an already existing such someusername in app_user table), it appends a #<number> to the new username. Having high numbers after the #, like #9, #20 or #64 is a strong evidence the LDAP configs aren't adequate and Jira's not being able to correctly identify users to sync (the LDAP configs should map to other attributes or some data is being input into the external directory that Jira's unable to process adequately e.g. invalid characters, etc).
Solution
Check if there have been recent changes in the User Directory LDAP configuration and revert it back to what it was previously, specially the User Name Attribute(usually defaults to sAMAccountName or msDS-AzureADMailNickname) or User Unique ID Attribute(default's usually objectGUID).
In some scenarios, you could also delete orphaned app_user entries from the database if they're left-over data and are conflicting with data coming from the AD, but this should only be considered after the LDAP config's been reverted to one previously working. Reach out for Atlassian Support if reverting the LDAP configs didn't get the User Directory to sync successfully again.
Was this helpful?