|Summary:||ldap caching not sufficient|
|Product:||Apache httpd-2||Reporter:||Philipp Gühring <pg>|
|Component:||mod_authnz_ldap||Assignee:||Apache HTTPD Bugs Mailing List <bugs>|
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 10.0.0.1]  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
Hi. 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 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: http://askubuntu.com/questions/167205/apache-2-4-install-on-12-04-ends-up-with-non-standard-configuarion http://ubuntuforums.org/showthread.php?t=2011603 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 and 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.