Confluence - change LDAP but preserve user permissions and ownership

[Greg Fischer]

Hi all,

In Confluence, I need to change the existing four AD User Directories being used for authentication and create just a single new User Directory which points to a different LDAP where all the users exist but have completely different user names.  Their first name, last name and email should be the same (with possible upper/lower-case differences).  I don't find a REST API call I can make to rename users in Confluence, and can't possibly update all of the users manually.

After disabling the four current ADs and adding the new LDAP User Directory, if I just let the new directory synchronize, will it recognize all the current users and update them accordingly?  Change their user name, their associated user directory, etc without having them lose any existing permissions or ownership of any objects?

If not, I would think then that the only way to proceed is to update the user's USER_NAME field in the CWD_USER table directly in the database (and possibly the  DIRECTORY_ID?) and let the new User Directory synchronize.  Any hazards to doing that?  Jira and Bitbucket both have an APP_USER table and if that gets out of sync with the CWD_USER table, things go badly wrong.  I am not finding an APP_USER table in Confluence.

Thanks,

-Greg

-

[AnnWorley · Accepted solution]

Hi Greg,

I understand you want to change from four LDAP user directories to one and the user names are different in the new directory.

Simply changing the user names in cwd_user will not be effective. There is another table, user_mapping that maps each user name to a user key, that key is used throughout the database to identify that user for content associations like bylines and user profiles. There is an attribute "User Unique ID Attribute" that is synched over from LDAP, since this would be different in the new directory the users would be seen as new users.

Any strategy that entails directly modifying the database is going to introduce a lot of complexity and unreliability.

Whatever strategy you decide to go with, I urge you to set up a test instance of Confluence to try the changes on before updating the Production instance. Here is the doc for setting up the test instance: Restoring a Test Instance from Production

 My recommendation for changing to the new LDAP servers may sound a little convoluted but should work. The key to my strategy is that you said the email addresses will be the same. Here is what I suggest (in the test instance first of course):

1. Set up the test instance with the four user directories just like production.
2. Edit each LDAP user directory to use the Active Directory "mail" attribute for the "User Name Attribute" field.
3. Sync the directories, so the user name all over the database will be the email address and the email address will be the logon credential.
4. Set up the new LDAP user directory, making "mail" the username attribute for the new directory.
5. Sync the new LDAP user directory
6. Disable the 4 old directories
7. Make sure you can log in with credentials from the new AD and your avatar is associated with your profile as expected.
8. Change the "User Name Attribute" field in the Confluence user directory to the "cn" attribute in AD.
9. After the next sync, the logon credential will be the AD username instead of the email address and Confluence will "see" the new AD users as the same as the old ones.
10. Remove the old LDAP user directories after testing is successful with them disabled.

I look forward to hearing how it goes.

Thanks,

Ann

[Greg Fischer]

Hi Ann,

So I believe this will work.  I have updated my test instance so the user's "username" is the email, and that seems to have updated everyone.  My next issue is on my side - our QA LDAP uses different email addresses (so people don't get tons of junk email from QA environments), so I can't enable that User Directory - it will just create new users.  I plan on restricting the valid Confluence users to one specific LDAP group, and that group won't be created in our production LDAP until the end of next week.  At that point, I can update the new User Directory in my test instance and enable it and continue with your step 4 onward.

I will let you know how that works!

Thanks,

-Greg

[AnnWorley]

The plan sounds good. I am super happy you have a QA environment.

In case you need help filtering the users down to the one group there are examples of AD compatible user filters at the bottom of this page: How to write LDAP search filters

[Greg Fischer]

Thanks Ann.  I am setting this up exactly the way we have Bitbucket already set up.  So I have my LDAP settings and search filters all set - a direct copy of the Bitbucket settings and just the group name changes from Bitbucket_Users to Confluence_Users :-)

[Greg Fischer]

Hi Ann,

I got my group in production LDAP today, and can verify that the steps work.   Thank you very much!

[AnnWorley]

Happy I was able to help. Thanks for keeping me in the loop and have a great weekend!