| Summary: | LDAPConnectionPoolTTL - AH01618 error | ||
|---|---|---|---|
| Product: | Apache httpd-2 | Reporter: | Jorgen <jorgen.sandstrom> |
| Component: | mod_ldap | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | ||
| Priority: | P2 | ||
| Version: | 2.4.10 | ||
| Target Milestone: | --- | ||
| Hardware: | HP | ||
| OS: | Linux | ||
|
Description
Jorgen
2014-11-12 13:07:35 UTC
There is a fix in 2.4.11 that may be related, but tough to tell w/o context:
*) mod_ldap: In 2.4.10, some LDAP searches or comparisons might be done with
the wrong credentials when a backend connection is reused.
Can you get it to fail under loglevel debug or trace8?
Otherwise you are right that you should just see a retry and maybe a short delay if a connection in the pool goes south.
(In reply to Eric Covener from comment #1) > There is a fix in 2.4.11 that may be related, but tough to tell w/o context: > > *) mod_ldap: In 2.4.10, some LDAP searches or comparisons might be done > with > the wrong credentials when a backend connection is reused. > > Can you get it to fail under loglevel debug or trace8? > > Otherwise you are right that you should just see a retry and maybe a short > delay if a connection in the pool goes south. I have logs from Subversion edge in debug mode (I think thats trace8) [Thu Nov 06 09:44:54.159442 2014] [ssl:debug] [pid 23265] ssl_engine_kernel.c(236): [client 10.249.66.28:49770] AH02034: Subsequent (No.2) HTTPS request received for child 1 (server svn-it.got.company.net:443) [Thu Nov 06 09:44:54.159483 2014] [authz_core:debug] [pid 23265] mod_authz_core.c(799): [client 10.249.66.28:49770] AH01626: authorization result of Require valid-user : denied (no authenticated user yet) [Thu Nov 06 09:44:54.159488 2014] [authz_core:debug] [pid 23265] mod_authz_core.c(799): [client 10.249.66.28:49770] AH01626: authorization result of <RequireAny>: denied (no authenticated user yet) [Thu Nov 06 09:44:54.159560 2014] [authnz_ldap:debug] [pid 23265] mod_authnz_ldap.c(515): [client 10.249.66.28:49770] AH01691: auth_ldap authenticate: using URL ldaps://vds.company.biz:636/ou=Internal,ou=Users,o=XXX?uid?sub [Thu Nov 06 09:44:54.161569 2014] [authnz_ldap:info] [pid 23265] [client 10.249.66.28:49770] AH01695: auth_ldap authenticate: user userX authentication failed; URI /svn/some-path/pom.xml [User not found][No such object] [Thu Nov 06 09:44:54.161580 2014] [auth_basic:error] [pid 23265] [client 10.249.66.28:49770] AH01618: user userX not found: /svn/EIE/!svn/rvr/452/some-path/pom.xml That could actually be a match. You could probably test this using e.g. ldapsearch. The issue would be that your actual users (userX) can't perform the DN search themselves (and get that same "object not found") but the webserver LDAPBindDN can. Hi again Eric. I always validate with ldapsearch before configuring the tool (the server must accept ldap cert and connect thru firewall) Do the search with 'ldapmanger-user' in ldap for looking up 'myuser' -- This always works, no surprise -- ldapsearch -xLLLH ldaps://vds.company.biz:636 -D "cn=ldapmanger-user,ou=Internal,ou=Users,o=company" -w '*****' -b "ou=Internal,ou=Users,o=Company" "(&(objectClass=inetOrgPerson)(cn=myuser))" Do the search with 'myuser' in ldap for looking up 'myuser' -- This return nothing -- ldapsearch -xLLLH ldaps://vds.company.biz:636 -D "cn=myuser,ou=Internal,ou=Users,o=company" -w '*****' -b "ou=Internal,ou=Users,o=Company" "(&(objectClass=inetOrgPerson)(cn=myuser))" Do the search with 'unkownuser' in ldap for looking up 'myuser' -- This return 'ldap_bind: Invalid credentials (49)' , no surprise -- ldapsearch -xLLLH ldaps://vds.company.biz:636 -D "cn=unkownuser,ou=Internal,ou=Users,o=company" -w '*****' -b "ou=Internal,ou=Users,o=Company" "(&(objectClass=inetOrgPerson)(cn=myuser))" BR Jorgen okay, based on that then I think you are affected by that bug in 2.4.10 fixed in 2.4.11. Unfortunately you'll need a new mod_ldap (util_ldap.c) to verify. Thank you so much for your time Eric. Next upgrade from CollabNet Subversion Edge will problaby be shipped with 2.4.11. Until then, what do you recommend LDAPConnectionPoolTTL 60 or LDAPConnectionPoolTTL 0 (never try to reuse a ldap connection) BR Jorgen I think 60 is reasonable |