-
Bug
-
Resolution: Not a bug
-
High
-
None
-
6.0, 5.10, 6.6.0, 7.12.5, 7.14.1
-
126
-
Severity 2 - Major
-
18
-
NOTE: This bug report is for Confluence Server.
Summary
Unknown Users appears in various places such as Mentions:
Page restrictions:
And everywhere else. This causes degraded functions:
- Mentioned users are not notified
- Permissions and restrictions are not properly set - eg, users unable to edit pages
How to replicate
The issue happens when we rename LDAP users to usernames that already exists in Confluence. For example:
- Set a user directory connection to LDAP A with username attribute: SAMAccountname
- Set another user directory connection to LDAP A with username attribute: mail
- Edit the second user directory's username attribute to SAMAccountname
Expected Result
Since the newly renamed users are being renamed to existing set of users, it's expected that the users are now "merged".
Actual Results
Duplicated users exists in the user_mapping table. One of them has NULL lower_username and causing sightings of Unknown User in Confluence UI.
Notes
When connecting to a new user directory with a new set of usernames, Confluence will create records of these users in the user_mapping table.
When user are renamed, Confluence will update user records in the user_mapping table. This is where the issue happens as users are being renamed to an already existing username and forced one of the records' lower_username to be NULL to avoid duplicate constraint in the database:
- user_mapping table after connecting to 2 LDAP with different usernames
user_key | username | lower_username |
---|---|---|
ff8080814a5a97df014a5b16c37c0008 | usera@mail.com | usera@mail.com |
ff8080814a5a97df014a5a97fb240001 | userA | usera |
- user_mapping table after renaming one of the user in LDAP side:
user_key | username | lower_username |
---|---|---|
ff8080814a5a97df014a5b16c37c0008 | userA | usera |
ff8080814a5a97df014a5a97fb240001 | userA |
Diagnosis
This can occur because user_mapping.lower_user_name is null. You may have a single user record for the affected user, or you may have another record which does include a lower_username.
- Single user record
user_key username lower_username ff8080814a5a97df014a5a97fb240001 userA
- Duplicated users (taken from an OnDemand instance)
user_key username lower_username ff8080814a5a97df014a5b16c37c0008 userA usera ff8080814a5a97df014a5a97fb240001 userA
Diagnosis - is this affecting you?
First, try a content reindex. If this doesn't help, run this query (on any version). If it returns any results, this bug is the cause of your duplicates.
Check and confirm if the user showing as unknown user is indeed affected by this bug:
SELECT * FROM user_mapping where lower(username) = '<username_lowercase>';
Replace <username_lowercase> with the lower cased version of the username that's observed to be having this behavior.
Check if there are more users affected by this bug:
SELECT * FROM user_mapping where lower_username is null;
If the above SQL query returns with some results, now you need to determine if you have single records or duplicated records, as the workaround you perform will depend on this.
select u.* from user_mapping u where lower(u.username) in (select nullrecord.username from user_mapping nullrecord where lower_username is null) order by u.username;
Workaround:
Follow the workaround provided in the bug report CONFSERVER-36018
- causes
-
CONFSERVER-54074 Create a user interface to facilitate the process of cleaning up duplicate users in the database
- Future Consideration
- is cloned from
-
CONFSERVER-36018 Duplicates in the People Directory due to duplicates in the user_mapping table
- Closed
- is related to
-
CONFSERVER-34473 Deleted users still active on watcher's list for Confluence pages - show as an Unknown User and Cannot Be Deleted.
- Closed
-
CONFSERVER-55117 Renaming users in LDAP to a previously deleted user causes duplicates in user_mapping.
- Closed
-
PSSRV-13146 Loading...
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...