nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Migrate users to new user directory (Confluence 5.4.4)

Matt Anderson

Hi all,

hoping someone has already been through this, in Confluence 5.4.4 I have two old legacy user directories with some users in each, both Active Directory. I would like to migrate all users from both over toa new "Internal with LDAP Authentication" user directory and delete the two legacy ones. Must maintain permissions, etc.

I found this article but the comment saying it only copies not migrates has stopped me using that one. It was handy to find the users in each directory however.

Any clues?

Accepted answers

Deividi Luvison

Hey Matt,

I have a method that might work, however is not support and involves some database sorcery , so if you decide to try this, set up a test instance to try this, if it works fine and you decide to give prod a go, backup your production database and application directories before trying to apply this on production:

Have your new directory (lets call new directory) with the same set of your legacy ones (lets say Legacy A and .
You will also need to ask your LDAP admin to make sure the new directory have the same set of groups (and the users added under those groups) as the legacy A and B directory.
Create a new user directory in Confluence and make sue to add a search filter that returns no resuts (we don't want to sync anything now).
Leave the Confluence Internal Directory in first position.
Have the Confluence internal administrator account (you will need to login with this one).
Disable the other two legacy directories.
Shutdown Confluence.
Run the "SELECT * FROM cwd_directory;" against COnfluence database.
If the information you gave me you will see 4 user directories, Internal, New Directory, Legacy A and Legacy B.
Take note of the id of the new directory and the internal COnfluence directory.
Now run this query ""UPDATE cwd_user SET directory_id='New directory ID noted from previous step' WHERE directory_id <> 'id from internal directory'
The "UPDATE cwd_user SET credential='nopass' WHERE directory_id <> 'id from internal'"
In case your new directory is a delagated directory instead of connector you will need to update as "NULL" instead of "nopass"
And lastly "UPDATE cwd_user SET external_id='' WHERE directory_id <> 'id from internal'"
Start Confluence.
Edit the user directory filter of the new directory so it can correctly sync and pull the users and group information.
Move this directory to first position.
Try to log in again and check your if the permissions are working permissions.
Once you confirm everything is Ok, delete the Legacy A and B directories.
Profit!

This method will tie all users that are not members of the internal user directory into to the "new directory", once they try to authenticate confluence will update the external id.

Another key point is that this method will only works for Confluence on versions 5.3 to 5.5.2, if we ever change our table structure again in future versions this not might work.

Lastly, as I said before, this is a pretty invasive method, which is not supported by us (support team) and is not recommended at all to try in production without testing, however I believe it worth a shot doing into a test env .

Hope it helps.

Thanks and Regards,

David|Atlassian Support

All comments

Deividi Luvison

Hey Matt,

Have your new directory (lets call new directory) with the same set of your legacy ones (lets say Legacy A and .
You will also need to ask your LDAP admin to make sure the new directory have the same set of groups (and the users added under those groups) as the legacy A and B directory.
Create a new user directory in Confluence and make sue to add a search filter that returns no resuts (we don't want to sync anything now).
Leave the Confluence Internal Directory in first position.
Have the Confluence internal administrator account (you will need to login with this one).
Disable the other two legacy directories.
Shutdown Confluence.
Run the "SELECT * FROM cwd_directory;" against COnfluence database.
If the information you gave me you will see 4 user directories, Internal, New Directory, Legacy A and Legacy B.
Take note of the id of the new directory and the internal COnfluence directory.
Now run this query ""UPDATE cwd_user SET directory_id='New directory ID noted from previous step' WHERE directory_id <> 'id from internal directory'
The "UPDATE cwd_user SET credential='nopass' WHERE directory_id <> 'id from internal'"
In case your new directory is a delagated directory instead of connector you will need to update as "NULL" instead of "nopass"
And lastly "UPDATE cwd_user SET external_id='' WHERE directory_id <> 'id from internal'"
Start Confluence.
Edit the user directory filter of the new directory so it can correctly sync and pull the users and group information.
Move this directory to first position.
Try to log in again and check your if the permissions are working permissions.
Once you confirm everything is Ok, delete the Legacy A and B directories.
Profit!

This method will tie all users that are not members of the internal user directory into to the "new directory", once they try to authenticate confluence will update the external id.

Another key point is that this method will only works for Confluence on versions 5.3 to 5.5.2, if we ever change our table structure again in future versions this not might work.

Hope it helps.

Thanks and Regards,

David|Atlassian Support

Deividi Luvison

Also make sure to vote up for this feature request:

https://jira.atlassian.com/browse/CONF-25630

So we can have a supported way to migrated users in Confluence trough the UI instead of the above work around.

Matt Anderson

Thanks Deividi, I will give that a go after I spin up a test environment.

Have upvoted that ticket above.

Matt Anderson

Following up at last in case anyone reads this in future, just tried this on a test server - it works!

Only changes worth mentioning, in the new Delegated directory i had to tick Sync Group Membership, and Ijust had to fix a couple of quick internal group memberships that didnt come across. I also did not need to do steps 3, 16 & 17.

Happy to move onto the live server now.

Justin Leader6

Thanks @Matt Anderson for putting together these steps. Would it be a similar process to migrate from one AD to another?

Matt Anderson

funnily enough I will be doing exactly that in 9 days, but I'm hoping that all I will really need to do is update the existing user directory with the new LDAP server settings. If not then yes I imagine the same process above will take care of it. I'll update here how it goes.

Phillip Ponzer _Cprime_

How'd it go?

Matt Anderson

it worked fine. Only one side effect, some people did not come across as members of the confluence-uers group, I just added manually as they popped up.

AbrahamA

Hello

Is this same for JIRA?

Thanks

Abe

Corentin Méhat

Hello,

I found an easier way for Confluence > 5.7, since the group memberships are merged in case of duplicate users.

use case :

* initial state : 1 internal user directory, with some usernames matching LDAP

* target state : 1 internal user directory + 1 delegated LDAP dir for LDAP users authentication.

By configuring the delegated LDAP with the "copy user on login" and by adding them to a newly created group to identify which ones are created, I managed to have the user who were in the internal directory but also in the LDAP authentify themselves from the LDAP, while users that were only in the internal directory (and not the LDAP) were not impacted.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

confluence-administration