Migrating users to Internal Directory with LDAP Authentication

[Per Eriksson]

Hello,

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

Per

[JamieA · Accepted solution]

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

[Per Eriksson]

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]

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.

[Brian Brian]

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

select

ID + 50 as ID,

group_name,

lower_group_name,

active,

local,

created_date,

updated_date,

description,

lower_description,

group_type,

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 = u.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 = u.id and u.lower_user_name in ('jschmoe')

set ug.directory_id = 1, ug.parent_id = ug.parent_id + 50;

[Rex Core]

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!

Rex

[Manse Wolken]

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

[Per Eriksson]

Hi Manse,

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

Best Regards

Per Eriksson

[Per Eriksson]

Hi,

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.

Best

Per