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
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!
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.
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.
In the past, Portfolio for Jira required a high degree of detail–foresight that was unrealistic for many businesses to have–in order to produce a reliable long-term roadmap. We're tur...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs