Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-54971

Unknown Users appears in Mentions, permissions, etc due to duplicates in the user_mapping table

    • Icon: Bug Bug
    • Resolution: Not a bug
    • Icon: High High
    • None
    • 6.0, 5.10, 6.6.0, 7.12.5, 7.14.1
    • User - Management

      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:

      1. Set a user directory connection to LDAP A with username attribute: SAMAccountname
      2. Set another user directory connection to LDAP A with username attribute: mail
      3. 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:

      diagnosis for specific users
      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:

      NULL users diagnosis
      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.

      pair NULL users
      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

       

       

        1. unknownusermention.PNG
          46 kB
          Monique Khairuliana
        2. unknownuserrestrictions.PNG
          50 kB
          Monique Khairuliana

            [CONFSERVER-54971] Unknown Users appears in Mentions, permissions, etc due to duplicates in the user_mapping table

            Saba Taseer made changes -
            Remote Link Original: This issue links to "Page (Bulldog)" [ 379027 ]
            Irina Tiapchenko made changes -
            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 ]

            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.

            Irina Tiapchenko added a comment - 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.
            Irina Tiapchenko made changes -
            Remote Link New: This issue links to "Page (Extranet)" [ 798934 ]
            SET Analytics Bot made changes -
            UIS Original: 37 New: 18
            Alex Cooksey made changes -
            Remote Link Original: This issue links to "Page (Confluence)" [ 796049 ]
            Alex Cooksey made changes -
            Remote Link New: This issue links to "Page (Confluence)" [ 796049 ]
            SET Analytics Bot made changes -
            UIS Original: 56 New: 37
            Rob made changes -
            Remote Link New: This issue links to "Page (Confluence)" [ 795042 ]
            SET Analytics Bot made changes -
            UIS Original: 93 New: 56

              03cb0c04aa4f Irina Tiapchenko
              mkhairuliana Monique Khairuliana (Inactive)
              Affected customers:
              19 This affects my team
              Watchers:
              36 Start watching this issue

                Created:
                Updated:
                Resolved: