Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Migrating users to Internal Directory with LDAP Authentication


We are just in the process of upgrading our JIRA from 4.1.2 to 4.4.3, and at the same time moving the installation from one server to another.

When we have migrated the environment, we would like to setup our environment to using Internal Directory with LDAP Authentication, leveraging the internal Active Directory within the company to do the password lookups.

Is there any possibility to migrate the existing accounts in the internal directory to the Internal Directory with LDAP Authentication directory, simply tansferring then between the two directories? We would like to perform this move to make sure that all the users keep their existing issues, projects, roles etc.

Please ask if you need any more info.

Best Regards


4 answers

1 accepted

3 votes
Answer accepted
JamieA Rising Star Dec 01, 2011

Set it up first on 4.1 using the osuser.xml file. When upgrading, copy the osuser.xml file to the new installation directory before starting the upgrade.

Then on upgrading, an upgrade task will create a new internal directory for delegated ldap auth, and migrate all the users from the internal dir to the delegated dir.

I'm not sure of any other supported way for moving users between directoriesl

Hi Jamie,

Thank you very much for this help. We have now finished a new test migration and the directory is setup fine. Our old accounts are now available in the delegated LDAP directory. I only have two more questions:

1) If we would like to change the ldap settings, how do we edit the Directory configuration? It seems to be read-only.

2) Jira seems to still check passwords against its cwd_user table after migration. How do we troubleshoot this further?

Best Regards

Per Eriksson

JamieA Rising Star Dec 05, 2011

1) As Manse says. This should be made much clearer in the UI imho.

2) It will only do that for users in the internal directory. From the user browser you can see what directory any user is in.

BTW, feel free to give some upvotes/ticks for helpful comments.

Actually, you can move users via database hacking. Let's assume that the ID of the new, delegated directory is 10100.

-- Move all groups to delegated directory
update cwd_group set directory_id = 10100, local = 1;

-- Copy groups back to internal (the "+ 50" part is subjective)
insert into cwd_group
ID + 50 as ID,
1 as directory_id
from cwd_group;
-- Move all users/attributes/memberships to delegated directory
update cwd_user set directory_id = 10100;
update cwd_user_attributes set directory_id = 10100;
update cwd_membership set directory_id = 10100;
-- Switch the directory order
update cwd_directory set directory_position = directory_position ^ 1;
-- Move specific users/attributes/memberships back to old directory
update cwd_user set directory_id = 1 where lower_user_name in ('jschmoe');
update cwd_user_attributes ua
join cwd_user u on ua.user_id = and u.lower_user_name in ('jschmoe')
set ua.directory_id = 1;
update cwd_membership ug
join cwd_user u on ug.child_id = and u.lower_user_name in ('jschmoe')
set ug.directory_id = 1, ug.parent_id = ug.parent_id + 50;

Brian Brian, even though this was 10 years ago, I used the tables as a guide to do my own database hacking after the directory migration tool was only partly successful.

Thanks for the post!


1 vote

1) If we would like to change the ldap settings, how do we edit the Directory configuration? It seems to be read-only.

You cannot change a directory from wich you are logged in. -> Create an administrative user in the "internal" directory, (if it does'nt exist: create it). Log in with that user and change your ldap directory as needed.

Best Regards

Manse Wolken

Hi Manse,

Of course it is... it is just silly I was thinking something else...

Best Regards

Per Eriksson


We now seem to have got things straighten out. The environment works fine after migration, we had 2 domains which were not completely synchronized which led us to believe it was not working.

After setting the password in the database to "nopass" for one of the accounts and making sure the AD environment was sucessfully synchronized, we were now able to verify our setup.

Thanks a lot for your help.



Suggest an answer

Log in or Sign up to answer

Atlassian Community Events