-
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 You do not have permission to view this issue
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
[CONFSERVER-54971] Unknown Users appears in Mentions, permissions, etc due to duplicates in the user_mapping table
Remote Link | Original: This issue links to "Page (Bulldog)" [ 379027 ] |
QA Demo Status | Original: Not Done [ 14330 ] | New: Not Needed [ 14332 ] |
QA Kickoff Status | Original: Not Done [ 14234 ] | New: Not Needed [ 14236 ] |
Resolution | New: Not a bug [ 12 ] | |
Status | Original: In Progress [ 3 ] | New: Closed [ 6 ] |
Remote Link | New: This issue links to "Page (Extranet)" [ 798934 ] |
UIS | Original: 37 | New: 18 |
Remote Link | Original: This issue links to "Page (Confluence)" [ 796049 ] |
Remote Link | New: This issue links to "Page (Confluence)" [ 796049 ] |
UIS | Original: 56 | New: 37 |
Remote Link | New: This issue links to "Page (Confluence)" [ 795042 ] |
UIS | Original: 93 | New: 56 |
After thorough investigation of this issue we came to conclusion that this is not a bug and behaviour of the system is correct in this case. When user rename happens in LDAP directory, Confluence doesn't have enough context behind such rename to be able to confirm whether renamed user is genuinely the same user or it's two different users. If admin accidentally renames user to already existing one, this user could get access to the data which they shouldn't have been able to see. It also wouldn't be possible to revert such merge, so doing it without specific instructions from admin is too risky and could lead to a serious security issues.
We have another ticket open (CONFSERVER-56448) with suggestion to provide admin an ability to transfer content ownership from one username to another one. We encourage you to vote on the ticket to help us understand how we should prioritize this request.