要約

When performing a User Directory synchronization, it fails and in the logs we can see:

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.

環境

Jira Core 7.x と 8.x のすべてのバージョン

User Directory synchronizing to MS Active Directory or Azure AD.

診断

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.

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"):

SELECT lower_user_name
FROM cwd_user
WHERE lower_user_name NOT IN (SELECT lower_user_name FROM app_user)
ORDER BY 1;

原因

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

ソリューション

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.