Deactivating Active Directory User Management

[X]

Anyone know how to replace an old Active Directory user directory with an OpenLDAP user directory?

[Andy Heinzer · Accepted solution]

There is a good piece of documentation on this process over in Migrating users between user directories - Atlassian Documentation.   I would recommend starting there to better understand the different methods you can use to migrate users.

If the new LDAP instance already has all the same user accounts, then one way to get all the users to use that directory instead is just to create a new user directory in jira with the new OpenLDAP connector and order this directory to be above your existing Active Directory entry there.

This way users would start using the OpenLDAP for authentication.  The only thing to watch out for when doing this is to understand where your groups in Jira come from.  Jira is using group membership for application access as well as permissions and notification schemes. If all your groups are in the Jira internal user directory, and your AD connector was using the Read only with local groups option, then you probably won't have any problems making this switch.   But if your users are currently getting their groups and group memberships from the AD connector in Jira, then you will either need to replicate those groups/memberships, or create new ones so that users can continue to access all the same resources in Jira.

Before doing this in a production instance, I would recommend testing this out in a staging server first.

[X]

Hi Andrew,

Thanks for the advice. I've already come across that document and few important things to note in my instance:

1. JIRA does not allow me to prioritise my OpenLDAP server over my depreciated Active Directory server as it claim's I will lose administrative access to JIRA. This is odd because I've switched off the Active Directory server and created the same JIRA groups and users that were present on the AD server in my OLDAP server and am authenticating via the OpenLDAP server. Even if the AD server is on I am still unable to change the order.

2. The migrating users section found in Additional Configuration & Troubleshooting  simply gives me the LDAP schema of the now depreciated AD schema whether the AD server is on or off.

3. I originally set up my AD server up as read only access. I've also done the same with OLDAP as I don't want any of this information to be modified by JIRA.

While things are working just fine in production with OLDAP and the AD switched off, it's just a bit annoying that I can't reorder the servers to remove the AD server entries.

Any ideas? Next steps for me will be either live with it or go and hack the entries in database, which I'm loathed to do because there's a good chance I'll break something.

[Andy Heinzer]

I recommend that you use the Jira internal directory to get past this problem.   Since you cannot change the order of that directory, it tends to mean that your current account is being logged into Jira through that particular user directory.

If you can create a Jira System administrator level account that exists in the Jira internal directory, and then login to Jira using that account, you can then change the order of those other directories.

I suggest that when you create this user account, it should have a unique username that does not exist in either of the other user directories.  This way we can be more confident that you are actually being authenticated on that Jira Internal user directory, and not another directory that is currently ordered higher up in Jira.

Alternative to this would be to hack at the database to correct this.   You can see the order of these directories with a SQL command such as:

select * from cwd_directory;

The results will all have a value in the directory_position field that dictates where that directory appears in Jira, where 0 is the highest value, and 1 is beneath that, 2 beneath that, etc.

You could change these via SQL, but if you do that, I would recommend creating a database backup first, and stopping Jira before you make this change in SQL directly.  It's also a good idea to keep this KB handy: Retrieving the JIRA Administrator

If you make changes to this table, you could lock yourself out of Jira in which case the steps in that KB would be needed to get admin access back to Jira.

[X]

Of course! The internal directory. All sorted now, thanks for your help!