Bug 21787 - LDAP authentication failure does not recover properly
LDAP authentication failure does not recover properly
Status: CLOSED DUPLICATE of bug 27748
Product: Apache httpd-2
Classification: Unclassified
Component: mod_auth_ldap
2.0.47
All All
: P3 critical with 3 votes (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
: PatchAvailable
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2003-07-22 01:23 UTC by Dave Wietzel
Modified: 2004-11-16 19:05 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dave Wietzel 2003-07-22 01:23:01 UTC
I am using the ldap module to connect to a IBM SecureWay LDAP for my DAV area.

Here is my configuration parameters:

<Location /webdocs>

	Dav On
	
	AuthType Basic
	AuthName DAV
	AuthLDAPEnabled on
	AuthLDAPURL "ldap://myldap.fritolay.pvt/ou=people,dc=pepsico,dc=com"
	AuthLDAPBindDN "uid=xxxxxx,ou=agents,dc=pepsico,dc=com"
	AuthLDAPBindPassword "xxxxxxx"

	#AuthUserFile user.passwd

    AllowOverride None
    Options None
	
	<LimitExcept GET OPTIONS>
		require valid-user
	</LimitExcept>
	
</Location>

I am able to connect one time. As long as I enter a valid ID/password I am 
fine. But when I put in a bas password, it fails, but then fails consistently 
afterwards even with a valid password. Here are the log entries:

[Mon Jul 21 19:43:31 2003] [debug] mod_auth_ldap.c(343): [client 
156.81.28.142] [4344] auth_ldap authenticate: using URL 
ldap://replicas.ldapdfw.fritolay.pvt/ou=people,dc=pepsico,dc=com
[Mon Jul 21 19:43:31 2003] [debug] mod_auth_ldap.c(418): [client 
156.81.28.142] [4344] auth_ldap authenticate: accepting dwietzel
[Mon Jul 21 19:43:31 2003] [debug] mod_auth_ldap.c(537): [client 
156.81.28.142] [4344] auth_ldap authorise: successful authorisation because 
user is valid-user
[Mon Jul 21 19:44:00 2003] [debug] mod_auth_ldap.c(343): [client 
156.81.28.142] [4344] auth_ldap authenticate: using URL 
ldap://replicas.ldapdfw.fritolay.pvt/ou=people,dc=pepsico,dc=com
[Mon Jul 21 19:44:00 2003] [debug] mod_auth_ldap.c(348): [client 
156.81.28.142] [4344] auth_ldap authenticate: ap_get_basic_auth_pw() returns 
401
[Mon Jul 21 19:44:00 2003] [debug] mod_auth_ldap.c(343): [client 
156.81.28.142] [4344] auth_ldap authenticate: using URL 
ldap://replicas.ldapdfw.fritolay.pvt/ou=people,dc=pepsico,dc=com
[Mon Jul 21 19:44:00 2003] [warn] [client 156.81.28.142] [4344] auth_ldap 
authenticate: user dwietzel authentication failed; URI /webdocs 
[ldap_simple_bind_s() to check user credentials failed][Invalid Credentials]
[Mon Jul 21 19:44:05 2003] [debug] mod_auth_ldap.c(343): [client 
156.81.28.142] [4344] auth_ldap authenticate: using URL 
ldap://replicas.ldapdfw.fritolay.pvt/ou=people,dc=pepsico,dc=com
[Mon Jul 21 19:44:05 2003] [debug] mod_auth_ldap.c(348): [client 
156.81.28.142] [4344] auth_ldap authenticate: ap_get_basic_auth_pw() returns 
401
[Mon Jul 21 19:44:05 2003] [debug] mod_auth_ldap.c(343): [client 
156.81.28.142] [4344] auth_ldap authenticate: using URL 
ldap://replicas.ldapdfw.fritolay.pvt/ou=people,dc=pepsico,dc=com
[Mon Jul 21 19:44:05 2003] [warn] [client 156.81.28.142] [4344] auth_ldap 
authenticate: user dwietzel authentication failed; URI /webdocs [User not 
found][No Such Object]
[Mon Jul 21 19:44:06 2003] [debug] mod_auth_ldap.c(343): [client 
156.81.28.142] [4344] auth_ldap authenticate: using URL 
ldap://replicas.ldapdfw.fritolay.pvt/ou=people,dc=pepsico,dc=com
[Mon Jul 21 19:44:06 2003] [debug] mod_auth_ldap.c(348): [client 
156.81.28.142] [4344] auth_ldap authenticate: ap_get_basic_auth_pw() returns 
401
[Mon Jul 21 19:44:06 2003] [debug] mod_auth_ldap.c(343): [client 
156.81.28.142] [4344] auth_ldap authenticate: using URL 
ldap://replicas.ldapdfw.fritolay.pvt/ou=people,dc=pepsico,dc=com
[Mon Jul 21 19:44:06 2003] [warn] [client 156.81.28.142] [4344] auth_ldap 
authenticate: user dwietzel authentication failed; URI /webdocs [User not 
found][No Such Object]

Everytime after the failure it looks as though I get a [No Such Object].

Dave Wietzel
Comment 1 webmaster 2003-09-25 04:18:34 UTC
We were having the exactly same problem (without running mod_dav) trying to 
authenticate to SunOne Directory Server 5.

The workaround we used (was originally suggested in Bug #17274) was to close 
the connection to LDAP server completely after every search:

$ diff mod_auth_ldap.c~  mod_auth_ldap.c
368c368
<     util_ldap_connection_close(ldc);
---
>     util_ldap_connection_destroy(ldc);

Would be great if someone could investigate this properly!




Comment 2 Bradley Schwoerer 2003-10-14 04:14:04 UTC
We have also experienced the same problem.  The listed change from above does 
work at least for 2.0.47 on Windows 2003 against AD on 2003.  After 
investigating this problem further I also come to the conclusion that the 
problem does occur because in the util_ldap_cache_checkuserid function 
(util_ldap.c) it is using an existing connection for the simple bind (line 874) 
and then allowing reuse of this connection (good or bad credentials). 

IMO after determining the credential pair doesn't exist in cache and getting 
the dn using the binddn+bindpw search, a new connection should be created to 
check the users credentials.  After this has completed successfully or 
unsuccessfully this connection should be destroyed leaving the other connection 
untouched.  This allows for the binddn+bindpw pair to be used for the searches 
and compares.  This is also needed because in some environments the last 
authenticated user might not have the access to search for all users, while the 
binddn user should.

I would take a shot at coding this, but I am not good with memory cleanup.
Comment 3 Ben Kibler 2003-11-04 19:22:01 UTC
I have also run across this same problem with mod_auth_ldap, where after an 
failed bind attempt, subsequent requests fail.  In my Apache 2.0.47 test 
environments (Windows 2000, Redhat Linux 9, HP-UX 11i) this problem is 
repeatable when connecting to a Windows 2003 AD server, but I can't get the 
problem to occur when connecting to a Sun Directory Server 5.2.

Rather than destroying the connection after a failed bind attempt, I wanted to 
keep the connection open to avoid the performance hit of reconnecting.  So, 
after a failed user/password bind in util_ldap_cache_checkuserid, I simply mark 
the connection as unbound.

$ diff util_ldap.c.orig util_ldap.c.new
884a885
>       ldc->bound = 0;

On the next call to util_ldap_connection_open, the existing code will notice 
that the connection is unbound, bind again as the BindDN user, and return a 
properly bound connection.

I agree with Bradley that only the binddn+bindpw should be used for initial 
searches.  However, rather than actually destroying user-bound connections, I 
prefer to simply mark the connection as unbound after any user-specific bind 
operation.  This avoids the overhead of establishing a new socket connections 
for every login.

Ben Kibler
Comment 4 Markus Schiegl 2003-11-11 21:11:34 UTC
thanks Ben!

applying your proposed patch (marking the connection as unbound) solved the 
same problem i had on my solaris/httpd2048 system.

if everybody else is happy with this modification, i vote for a checkin so i 
don't have redo this after each new installation/compile... :-)
Comment 5 Bradley Schwoerer 2003-11-11 21:37:13 UTC
I agree that the simple solution that Ben proposed works well.  Although, I 
would suggest that after all user-specific bind operations, (failed or not) the 
connection should become unbound.  The will result in always using the bind-dn, 
bind-pw for searches.  So I am proposing that we use this instead:

$ diff util_ldap.c.orig util_ldap.c.new
881a882
>       ldc->bound = 0;


-Bradley Schwoerer
Comment 6 Jeff Trawick 2003-11-21 17:32:55 UTC
I'm going through the bug db to make sure patches are findable.  Please see 
http://httpd.apache.org/dev/patches.html
Comment 7 Todd Jeffers 2003-12-09 16:11:11 UTC
This sounds like a symptom of the same problem reported in bug #17599. I took a 
different (not necessarily better) approach of using the connection caching 
logic for this bind as well. I have posted a propsed patch there. Can someone 
more knowledgable than I shed some insight on which resolution is better?

THX.
Comment 8 Denis Gervalle 2004-02-21 15:21:36 UTC
I have added more information on this issue in bug 27134.
(I have created a new bug since component/version are different)
Just to let you know.
Comment 9 Graham Leggett 2004-05-20 22:58:00 UTC
Please try the patch at http://nagoya.apache.org/bugzilla/show_bug.cgi?id=27748
and tell me if it fixes this problem. This patch has been applied to v2.1.0-dev,
and awaits backporting to v2.0.50-dev.
Comment 10 Bradley Schwoerer 2004-05-21 03:38:17 UTC
From my perspective the patches for bug 27748 looks like it solves the problems 
in a good way.  I have not tested the code yet in any environments yet.
Comment 11 Graham Leggett 2004-05-21 14:49:35 UTC

*** This bug has been marked as a duplicate of 27748 ***