Performance issues with large LDAP repository in Jira server

Still need help?

The Atlassian Community is here for you.

Ask the community

Platform notice: Server and Data Center only. This article only applies to Atlassian products on the Server and Data Center platforms.

Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible


Permission checking and logins can take minutes with huge LDAP repositories.


In case a user and its group memberships have not been cached the query runs through all levels of the AD hierarchy searching for groups that this user belongs to, retrieving all possible group memberships that match the query and returning the results for Jira. This expensive query is responsible for the massive amount of data returned to JIRA as all matching groups with all members in each group are returned. This is the way the ldap group adaptor is implemented - each group object is returned as a list of members.


Here are Atlassian's suggested options:

  1. Use Atlassian Crowd as your Single Sign On interface to Active Directory.
  2. Restructure Active Directory for JIRA users and group them in new groups so that queries do not return these very large groups objects. You can then use a more specific base for the group search. Configure a more specific node in your baseUserNameSpace setting and set userSearchAllDepths to false. Alternatively, set a user search filter. See Reduce the number of users synchronised from LDAP to JIRA.
  3. Revert back and manage groups within JIRA - ie modify atlassian user to ignore groups. See Add LDAP Integration For User Authentication Only.

(info) Please see our Troubleshooting LDAP User Management documentation for further assistance with diagnosing LDAP problems.

Last modified on Aug 15, 2023

Was this helpful?

Provide feedback about this article
Powered by Confluence and Scroll Viewport.