Does anyone have LDAP integration enabled for large directories?

[JamieA]

Hello, I'm considering upgrading to 4.3+ and enabling proper LDAP integration. Currently we use an SSO solution, but osuser.xml is also set up to authenticate against the directory.

A fairly common support request is people trying to add a user to a role, but they can't find the user. The solution is to get the user to hit jira once which will create their account automatically, but if we enable proper LDAP integration this won't be necessary. Similar issue with user custom fields.

I have got it to work with local groups, with a reduced page size, the problem is that even the incremental synchronisation takes 20 minutes, and I am vaguely worried about performance problems of both jira and the ldap server (more the former). It's possible though that I could reduce the sync interval to once every 24 hours.

There are 47,000 users imported, and I'm not able to reduce this by using a narrower LDAP query.

So my question is does anyone else do this successfully, or has anyone else tried and had to stop? Are there better alternatives, such as copying the user on first login?

cheers, jamie

[EddieW · Accepted solution]

We had a similar issue connecting to and LDAP directory of 40,000 + users. It seems Jira and Confluence handle the choirs very diffferently, with confluencing being quick and cheap, and Jira being slow and expensive.

After much support interaction our only solution was to use Crowd to cache our LDAP on a nightly basis. Because ebverythiong is stored in Crowd's DB it gives us drastically better performance, and keeps the load off the central LDAP server too.

We did have an enhancement ticket opened to re-evaluate and perhaps revise the Jira approach to LDAP management.

https://jira.atlassian.com/browse/JRA-24544

[Radu Dumitriu]

My 2 cents:

We had a problem with the auth at one of our client's sites: in a certain time interval the authentication took a loong time. It seems that at this version 4.3 / 4.4 Jira, when doing LDAP synchronization, prevents users to log in and waits for the synchonization to finish. More, you cannot control when synchonization should take place (there's no such synchronize between X and Y hours). Our temporary solution was to put it to synchonize at 24h and we started it automatically at midnight (ugly, huh!)

At this very moment, Jira has to improve synchronization of the LDAP directory (or allow more methods for this to happen). IMHO, caching the users without offering at least another method to avoid it (I'm thinking of a WeakHashMap here) is not very good: besides the unique lock on synchonization stuff, there are some setups that will want immediate changes to all the systems when somebody changes the LDAP.

[JamieA]

Thanks... I was thinking of the midnight trick too, but I couldn't have users locked out for 20 mins even at midnight (London time... equals 8am SGP, 7pm NYC). But it's a quartz scheduled job, so you could schedule it to run at midnight with a bit of tinkering with the db or some groovy.

One consequence of having 47k users is the ajax user picker is ridiculously slow, 5-20s. A similar db query is very fast.

[Radu Dumitriu]

Well, not enough time to dig it more deep. I was just happy that the problem was resolved :) But I promised myself I'll go back to that problem as soon as possible ...