Yet another question about migrating users from internal provider to ldap

Dominic Feig April 14, 2014

Hello there,

once upon a time our company introduced JIRA with the help of a consulting company. This was before I started to work there. Before buying a JIRA license they evaluated JIRA and added users to the internal user directory of JIRA. After buying a license they connected the company active directory (Microsoft Active Directory (Read Only, with Local Groups) to JIRA and synced it. That means the rest of the company is logging in with there AD login and the evaluating users are still login with there internal directory data. Also this ad connection was set up without an AD filter, that means all users regardless if they have to use JIRA or not are synced into JIRA. The directory order is 1. internal and 2. AD.

Luckily the internal users has the same login name as in there parallel existing AD system.

Now I come to my question. I want that ALL users have to login with there AD login data. For this case I would add "another" AD connection with READ/Write permission and migrate the users from the internal to the AD. And also disable the internal directory.

Firstly, is this possible? While reading the documentation it should be.

Secondly but far more interessting. What happens to the users in the AD while migrating the users?

Thirdly, if I am right the internal users will be able to login with there AD accounts and get access to there old profile and data in JIRA?

Thanks in advance for any answer.

Best regards, Dominic

2 answers

1 accepted

1 vote
Answer accepted
Dave Theodore [Coyote Creek Consulting]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 16, 2014

The best thing to do is test this in a development environment, since each case is a little different. If you stand up a dev instance using an XML dump of your production data, all you need to do is change the directory order in the "User Directories" in the admin section in order to test. The directory on top is searched first, so if you make your AD directory on top, that is where users will log in to, if they exist. If they don't exist, Jira will search the next directory down, etc. After you invert the order, when users log in, if they don't see their dashboards, assigned issues, etc, things just got really messy. You didn't say which version of Jira you're running, but the modern versions of Jira have some capabilities around changing usernames and directories, so I'd explore that before going with something more complicated. If you want to give that a shot, import your data into the latest Jira version, then change the directory order and see how things look (same procedure as above.) If the users can't see their data, you will probably want to get some help on this. The user entity model in Jira isn't... let's say, the way you would design it if you were to redesign it from scratch. This creates a host of problems when you try to do this type of change. There is an add-on called Script Runner that has the capability to do username changes and merge users together, however in your case, you'll hit a bug with Script Runner where it is not aware of multiple directories. When it sees the same user name in different directories, as in your situation, it chokes because it is not aware that the unique constraint is user_name + directory_id and not just user_name. This means you have to manipulate the database manually or do search & replace against the XML dump. Both of which are messy, since there are 28 or so places in the database the potentially need to be touched for each user.

My team does a lot of these type of migrations, so if you decide you need some help, let me know. Good luck!

Dominic Feig April 16, 2014

Thank you for your detailed answer.

Currently we are using JIRA 6.1.6 and also we are actually already using Script Runner (Unfortunately this bug exists). Is version 6.1.6 up-to-date enough?

I already set up a full test environment with cloning the jira/confluence server. So I'm pretty save here, but not with the AD. What happens if I start the user migration on the test environment to the user data stored in AD?

I will look for an user which have a legacy internal ldap user and he/she should try to log in after changing the directory order. I will inform you asap if he/she can't log in.

Dave Theodore [Coyote Creek Consulting]
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 16, 2014

The latest round of username change capability should be in your version of Jira. I can't think of anything else that was added in 6.2 that would be beneficial in this situation.

You're correct. In Dev, move the AD directory to the top and either use the "Switch to a different user" script in Script Runner to compare users in Prod to the same user in Dev or ask power users to do some testing for you. I'd choose users that have saved dashboards, saved filters, are Project Admins, etc. It should be pretty obvious whether the internal user was converted to be an AD user or if the AD user is a completely new account. It would be good to create a local user with Jira system-admin permissions and log in with that account so you don't get locked out after switching directory positions.

Dominic Feig April 21, 2014

Sorry for my late response.

I did it and it work fine as intented. I could log in as a different AD user without any issues and the user got all his dashboards and so on. Now can I migrate the user from the internal to the AD? What happens then?

0 votes
Jason Plumhoff
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 17, 2014
Dave is right - make sure you have a non AD administrator account so you can recover if there's a problem. Having said that, we went through this exact same situation ourselves recently without any issues. After testing in a dev environment, all we did was backup our live instance, added an actual AD directory (as opposed to read only with sync), and move that directory to the top of the list. Since all our users had the same usernames, it was all transparent. The only thing we saw was that the login counts were all reset to zero. Other than that, you'd never know we changed anything.

Suggest an answer

Log in or Sign up to answer