We are going to be changing from openldap using entryUUID to an active directory using ObjectGUID for the user unique ID attribute.
Can confluence handle that change without issues? I haven't found much in the way of instructions for doing this. I did see this thread: https://community.atlassian.com/t5/Confluence-questions/Confluence-change-LDAP-but-preserve-user-permissions-and/qaq-p/696207
and that makes me think that I might need to switch the existing unique attribute to something like username, then add the second directory and have it use username as a unique attribute. Let them sync a while, then change the second directory to use ObjectGUID, then remove the first directory. True/false?
I'd rather not make work if none is needed:)
I just left you a voice mail, was hoping to clarify a couple of points before answering true/false. I was not clear on when in the process the users are being migrated to AD.
If you want Confluence to recognize the users in Active Directory as being the same users that were in OpenLDAP, and the user names will be the same in both directories then my recommendation is:
There is a lot of room for error so I encourage you to test in a pre-production instance first.
Please make sure to pick the right directory type when you set up the user directory in Confluence because the directory attributes are very different in the different templates, for example:
If you pick OpenLDAP the attributes are as in this screenshot:
Please let me know any follow up questions or if I misunderstood the case.
Cheers,
Ann
Thanks. I'm back at my phone if you have additional questions.
That matches what I envisioned. Thanks for confirming. I assume that after both directories have been sync'd using username as the unique identifier, I can disable the first directory, then just change the new one to use the real identifier. I didn't notice a step in your list to disable/remove the old directory.
The last step moving from Openldap to Active Directory is mapping all the new attributes and recreating the user filter. Do you have a list of characters that need to be escaped or treated differently in an ldap search filter in the admin area? The first thing I'm noticing is that roles in the active directory have spaces in them. Like:
memberOf=CN=ROLE.APP System FINANCE,OU=Global,OU=Groups,OU=Stuff,DC=, etc...
I recall a very long time ago having to encode or escape ampersands. I do not see that in the documentation this time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Jason,
I didn't focus on the OpenLDAP directory after the migration step because I assumed that OpenLDAP itself would be retired, but you are correct that the old OpenLDAP User Directory should be disabled and eventually deleted to keep from cluttering the instance with legacy relics.
A lot of the filters on this page are written for AD. I have had good results with the filters on this doc: How to write LDAP search filters
It may be that you have to escape certain characters when you use a filter in an XML file, I don't have any experience escaping characters in filters entered in the UI.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It did not work. Everyone logging in has a new account created for them.
I'll open a support case and do this more systematically.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This thread is rather old but I've planned to do a similar migration and the steps you described seemed logical to me. How did you solve migrating from one AD to another? Thanks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It did work I believe. I just had to wait longer and make sure the changes were completely finished between each step.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So after 5 hours of updating users to use the login ID as their unique attribute with the openldap, I added the active directory as a second directory, with it using sAMAccountName as the unique attribute. Those attributes are identical between the systems.
In the logs, I see this:
2018-02-13 19:25:20,390 INFO [Caesium-1-4] [atlassian.crowd.directory.DbCachingRemoteChangeOperations] addUsers adding [ 97585 ] users
I hope its not thinking there are 97,585 new users. I also cannot test logging in from the user directory test area. It just spins. The basic connection was successful.
I'll let it sync for a few hours and see if the behavior changes.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.