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; } } }

Migrating users to Internal Directory with LDAP Authentication

Per Eriksson1

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

Accepted answers

JamieA

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

All comments

JamieA

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 Eriksson1

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

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 Eriksson1

Hi Manse,

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

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.

Per Eriksson1

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

Brian Brian8

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

Welcome!

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

Quick Links

Find more posts tagged with

migration

account

authentication

user

ldap