Migrating users to Internal Directory with LDAP Authentication
Asked by 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


Answers:
author: JamieA
body: 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

comments: author: Per Eriksson
body: 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


author: JamieA
body: 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.


author: Brian Brian
body: 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;

comments: author: Rex Core
body: 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


author: Manse Wolken
body: > 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

comments: author: Per Eriksson
body: Hi Manse,

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

Best Regards

Per Eriksson


author: Per Eriksson
body: 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


Tags: account

authentication

ldap

migration

user