Bug 52790 - ldap caching not sufficient
Summary: ldap caching not sufficient
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_authnz_ldap (show other bugs)
Version: 2.2.16
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Keywords: MassUpdate
Depends on:
Reported: 2012-02-28 18:23 UTC by Philipp Gühring
Modified: 2018-11-07 21:08 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Philipp Gühring 2012-02-28 18:23:20 UTC
I am trying to connect a Subversion on Apache to an LDAP server. Unfortunately, the LDAP server does not like many requests for the same user, and returns 

[Tue Feb 28 18:21:46 2012] [info] [client] [18717] auth_ldap authenticate: user philipp authentication failed; URI /cgi-bin/anon.pl [LDAP: ldap_simple_bind_s() failed][Administrative limit exceeded]

when it thinks that it have been too many requests.
The problem on the other side is that Subversion does an HTTP request for every single file, and I have a repository with approximately 1 million files in it, so every operation can result in a lot of HTTP requests with the same user.

The amount of different users that are authenticating to my application is rather low, I have about 3 power-users, and up to 100 users that are using it sporadically (once per month or less often)
I have configured the cache like this:

LDAPSharedCacheSize 3000000
LDAPCacheEntries 1024
LDAPCacheTTL 600000
LDAPOpCacheEntries 1024
LDAPOpCacheTTL 600000
LDAPSharedCacheFile /var/cache/apache2/ldap.cache

The shared cache file is created properly, and the cache seems the be working, but it does not seem to really cache the authentication requests.

When I do approximately 30 requests, I am getting those statistics:

LDAP Cache Information

Cache Name	Entries	Avg. Chain Len.	Hits	Ins/Rem	Purges	Avg Purge Time
LDAP URL Cache	1 (0% full)	1.0	30/31	97%	1/0	(none) 	0ms
ldaps://ldap.intranet/ou=people,dc=eu?uid (Searches)	1 (0% full)	1.0	30/62	48%	25/24	(none) 	0ms
ldaps://ldap.intranet/ou=people,dc=eu?uid (Compares)	0 (0% full)	0.0	0/0	100%	0/0	(none) 	0ms
ldaps://ldap.intranet/ou=people,dc=eu?uid (DNCompares)	0 (0% full)	0.0	0/0	100%	0/0	(none) 	0ms

The LDAP URL Cache seems to fully cache all the requests, but the Searches only cache 50%, so for every Hit, it still does one LDAP query.

Is it possible to also cache the authentication requests? I do not see why repeated requests for exactly the same URL with exactly the same username and password need additional LDAP requests, I think they should be cached instead.

My Subversion config:

AuthzSVNAccessFile /etc/apache2/dav_svn.authz
AuthLDAPURL ldaps://ldap.intranet/ou=people,dc=eu?uid
AuthLDAPBindDN "uid=technuser,ou=people,dc=eu"
Require valid-user
Order deny,allow
Deny from All
AuthName "Please enter your UserID and password"
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative off
Satisfy any

I guess that the problem might be that Apache does not want to store cleartext-passwords in the cache, since that can be a security issue. I would suggest to either encrypt the cache, or to only write hashed username+password into the cache.
Comment 1 Stefan Fritsch 2012-03-12 09:57:37 UTC
In 2.4.1, there is mod_authn_socache, which allows to solve this problem. But I guess mod_ldap's caching should be improved, too.
Comment 2 Lazar Istvan A. 2012-11-07 13:57:27 UTC

Currently I'm using:
Ubuntu 12.04.1 LTS
with apache2: Candidate: 2.2.22-1ubuntu1
Ubuntu 12.04.4 LTS
with apache2: Candidate: 2.2.14-5ubuntu8.9

As you can see unfortunately in the default Ubuntu repositories (for 10.04 and 12.04) there is only apache 2.2, and not 2.4 apache yet.
I don't want to install apache 2.4 from binary sources, because I'm afraid that I will face another dependency issues after that. As how I see people are facing problems regarding to apache 2.4 (and it's modules) + Ubuntu 12.04 (or earlier) compatibility:

My question is that there is any workaround to solve this issue in apache 2.2? Do you have any plans to improve mod_ldap???
We are getting dozens of [LDAP: ldap_simple_bind_s() failed][Administrative limit exceeded] errors on a daily basis (we have a few hundred users and a few hundred commits daily) - receiving this error means that the commit also fails in this case.

Earlier we used Ubuntu 9.10 with 2.2.12-1ubuntu2.1, and this error was not present there. So we also tried to change the mod_authnz_ldap.so and mod_ldap.so in 12.04 with the ones from 9.10, but this didn't help, we still receive this error on 12.04 (with the 9.10 modules also).
Comment 3 Lazar Istvan A. 2012-11-07 14:05:23 UTC
(In reply to comment #2)
> Currently I'm using:
> Ubuntu 12.04.1 LTS
> with apache2: Candidate: 2.2.22-1ubuntu1
> and
> Ubuntu 12.04.4 LTS
> with apache2: Candidate: 2.2.14-5ubuntu8.9

Sorry, I meant Ubuntu 10.04.4 LTS, and not Ubuntu 12.04.4
So I'm currently using:
Ubuntu 12.04.1 LTS
with apache2: Candidate: 2.2.22-1ubuntu1
Ubuntu 10.04.4 LTS
with apache2: Candidate: 2.2.14-5ubuntu8.9
Comment 4 William A. Rowe Jr. 2018-11-07 21:08:14 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.