JIRA not caching LDAP calls when behind Apache2 reverse proxy?

[Dave]

I have JIRA v5.2.8 (running on Ubuntu 12.04 x64) configured to use our OpenLDAP server for user authentication (not group membership however). Currently we have an Apache2 server as a reverse proxy configured in front of JIRA with basic authentication enabled.

Today, I noticed that the Apache/JIRA combination is doing a search/bind on our LDAP server multiple times per request on every request. This is hampering performance and shouldn't be neccessary.

I know that tools like Apache2 have an LDAP cache to improve performance and I have verified via two different methods that this cache is functioning normally. The http://localhost/ldap-status on the reverse proxy reports the cache is working and other servers (Confluence, Nexus, Jenkins, Fisheye, etc.) do not have this problem of over-taxing our LDAP server.

I also ran a test on JIRA where I logged in directly without going through the reverse proxy and JIRA does seem to cache credentials because after the initial lookup, additional lookups where infrequent.

So the problem must be the combination of basic authentication and JIRA that causes this issue. Again, neither Confluence nor Fisheye exhibit this problem.

[Kai Gottschalk]

Just a guess, but do you use LDAP where permissions are set to authentication only, with local groups. As you can see in this documentation, data caching does not occur for this user directory type.

Maybe - if you have not done so far - you can follow that guide, which might help you to debug. Another solution might be Atlassian's CROWD which reduces the LDAP calls even further (see this quite old, but still valid blog post).

I am curious to know, if this helps you!

Kind regards
Kai

[Dave]

I was revising my question when you were typing your answer - thanks for the help. The link you provided is a 404 -- did you mean this: https://confluence.atlassian.com/display/JIRA/Synchronising+Data+from+External+Directories

Our LDAP permission scheme is set to "Read Only, with Local Groups", which, according to the documentation should allow for caching. Not sure where to go next...

[Kai Gottschalk]

Yes I meant the link :

https://confluence.atlassian.com/display/JIRA/Synchronising+Data+from+External+Directories

Interstingly my provided link pointed to that URL and I was exeriencing also some unavailability "due to maintenance" as Atlassian says.

Cheers
Kai

[Dave C]

Sounds like you're using a connector with periodic synchronisation configured as detailed in https://confluence.atlassian.com/display/JIRA/Connecting+to+an+LDAP+Directory - is that right? If so, JIRA will periodically synchronise details by comparing the local cache of users/groups and group membership against openLDAP (typically set at a 60min interval). JIRA will bind to openLDAP when a user attempts to login as it will authenticate the user then, as these details aren't stored within the DB.

Outside of the periodic synchronisations and authentication attempts, JIRA will not attempt to connect to openLDAP.

I haven't seen anyone use the LDAP cache with JIRA before, so I'm guessing you have the openLDAP server sitting behind Apache and JIRA is connecting to OpenLDAP through Apache rather than directly connecting to it - is that right? If it's not going through Apache it wouldn't be able to cache it. That is to say: is the hostname of the User Directory in JIRA using the proxy or the direct connection to OpenLDAP? I realise this is something obvious, just want to make sure!

As for FishEye and Confluence, are they both delegating user management to JIRA, or is Confluence connecting to the OpenLDAP server? FishEye will need to delegate its user management to something else, so that shouldn't be touching OpenLDAP directly at all (it'll sync with JIRA which syncs with OpenLDAP). You can configure Confluence to do this as well, so that may be why you don't see those other applications accessing OpenLDAP.

Also, what kind of numbers are you talking about? It sounds like you must have a very large openLDAP server for there to be performance implications. Depending upon the configuration of the User Directory this can result in syncing more users are necessary. For example, if you sync the root DN of OpenLDAP and there are a significant number of objects in it, it'll increase the sync time. It'd help to get some more info on this. Can you provide the following so we can take a look:

• https://confluence.atlassian.com/display/JIRAKB/How+to+Generate+a++Directory+Configuration+Summary
• The details of your Apache configuration

That summary will have IPs in it as well as DNs (no passwords!), so please be aware if this is sensitive information. Other things we could look at:

• Restricting the objects returned by modifying your base / user / group DNs
• Restrict objects returned with a more restrictive filter (https://confluence.atlassian.com/display/DEV/How+to+write+LDAP+search+filters)
• Switch to a delegating user directory. This won't sync, so no updates on groups/users will be pushed to JIRA. It will only bind on password authentication and you will have to manually administer users more than in a connector.