Changing Jira and Confluence LDAP Authentication Directory

[Dave Dabinett]

I have Jira (7.1.10) and Confluence (5.10.4) on-premise instances, they are currently connected to multiple Novell LDAP sources.

We are moving to AD for LDAP and need to migrate Jira and Confluence LDAP from the Novell eDirectory's to one AD.

There are over 10,000 accounts in AD, all users from eDir's exist in the AD and have the same username.

My plan is to (this will be done in DEV first):

1. Add AD to list of LDAP Directories
2. Move AD to top of Directories list
3. Synchronise AD (Should I do this before moving AD up the list?)
4. At this point my users should all list as being from the AD LDAP directory
5. Test using an AD account
6. Remove the Novell directories from the Directories list
7. Test using an AD account (again)

Anyone have thoughts on this approach? My main concern is about when to do the sync.

TIA, Dave

[Andy Heinzer · Accepted solution]

Hi Dave,

I understand you are planning to migrate user directories for both Jira and Confluence.  Your steps seem ok, but I would actually recommend swapping steps 2 with 3, at least when it comes to doing it in production.  The reason for this is that for larger user directories, like yours with more than 5,000 users, we have seen a performance hit Jira can take when trying to sync that much user/group data all at once.

This just means it can take a lot longer for Jira to get all those users into its system completely.  That isn't always a problem, but if you put that directory in the top order, it can cause issues sometimes when users try to login whether or not there account is in the system yet.  This problem is actually made worse by a documented bug in order versions like yours where a directory is removed during a sync, detailed in JRASERVER-40291.  The sync behavior in these older versions will remove the directory at the beginning of a sync, that poses a problem if the sync fails for some reason, and larger directories are more likely to fail the sync in my experience.

Moving the user directory to the top is certainly something you want to test, as when usernames exist in multiple directories, Jira always picks the highest ordered directory where that account exists first.  I'd make sure the sync completes at least once successfully before you do change the order.  That way the users are in the system at least.

On a side note, you should be aware that both of these versions are beyond the End of Life detailed here.  I know that Jira has had a few performance improvements that are specific to how it handles LDAP/AD user directories in the more recent versions, namely

• JRASERVER-36979 
• JRASERVER-61759 
• JRASERVER-62742 

just for starters.  We have seen a lot of support issues with these versions of Jira trying to sync very large directories like this.  I completely understand if you aren't looking to do an upgrade here, but I thought it might help mention these bugs in order to avoid some performance issues here.

You should still be able to make a directory switch like this without being required to do an upgrade.  Please let me know if you have any questions or concerns about this.

Thanks for planning to try this in staging first.  I think you'll be well prepared for when it comes time to do this in a production site.

Andy

[Dave Dabinett]

Hi Andy,

Thanks for the great response. There is a plan to upgrade the versions but I am unsure whether I will need to make this change before then, so thanks for providing the insight to the risks with the current versions and LDAP.

With the Jira and Confluence apps we currently have a number of LDAP connections for different subsets of users (due to organisation changes/mergers) which we will consolidate into one new corporate LDAP AD - which is the new connector.

I have thought some more about it and in the first instance I will implement the new AD at the bottom of the list and sync it. When it is sync'ed I will promote it to above the lowest of the current LDAP connections - which I think means the new AD will become the LDAP source for the one LDAP connection below it. Then I can test users in that LDAP to ensure they are working as required. Then move onto AD replacing the next one and perform the same steps and so on.

Does that make sense?

Also, we have a mix of Internal with LDAP Authentication and LDAP Connectors configured with Read Only, with Local Groups set for the LDAP connections.

We are working out whether we want the new AD LDAP connector to be an Internal with LDAP Authentication or an LDAP Connector configured with Read Only, with Local Groups setting.

Are there issues with migrating users authenticating from a standard LDAP Connector to an Internal with LDAP Authentication connection? Or vice versa? 

This will help us define our user provisioning strategy, because not everyone in the organisation uses the applications.

Cheers,

Dave

[Andy Heinzer]

Hi Dave,

I think your approach makes sense.  The concerns I have about a user directory change like this becomes understanding how users are assigned to groups.  The ability for a user to login to Jira is dependent upon their account having a group membership that grants application access.  Groups can only apply memberships to user accounts that original in the same user directory.  The exception to that rule is when you use an LDAP with local groups.  That's the only time that a user in an LDAP directory can gain group membership to Jira's internal user directory groups.

When you are changing user directory order, it is not always clear if the same user account in a new directory has the same group memberships being applied.  The most common problem I see when users make a change like this is that users suddenly can't login because, even though their username is the same, that account in the newly top ordered directory might be missing some group membership.

As for the differences between LDAP Connected directories and Internal with LDAP Auth, well there is known to be far less overhead for Jira using the internal one.  But drawback is that there is also no syncing happening here.  The Internal w/LDAP type does have an option to grant users a default group membership, this can be used as a means to make sure the account has at least a single group membership.   There is a tendency to use Internal w/ LDAP auth for large numbers of users, I recall a number of sysadmins that noted a performance difference with that type versus the connected directory which by default is scheduled to sync every hour. 

Let me know if you have any questions about this.

Andy