Bug 17274 - MS Active Directory 2000 SP3 always returns "user is not unique" after an erroneous login attempt
Summary: MS Active Directory 2000 SP3 always returns "user is not unique" after an err...
Status: RESOLVED FIXED
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ldap (show other bugs)
Version: 2.0.44
Hardware: All All
: P3 normal with 17 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: PatchAvailable
Depends on:
Blocks:
 
Reported: 2003-02-21 10:14 UTC by Laurent Blume
Modified: 2012-05-31 06:02 UTC (History)
1 user (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Laurent Blume 2003-02-21 10:14:27 UTC
(this is the copy of an email I posted on the mod_ldap list and the Apache users
list - two emails actually, I replied to myself - I hope nobody will mind, I
already spent time diagnosing the bug, I just had no time to follow a bug report
till now :-)

I can confirm that this problem is a bug related to how mod_ldap handles the
behaviour of the AD server.
When a bind has succeeded, the module keeps the session open for any following
request. However, when the first bind (with AuthLDAPBindDN) was successful, and
then the second (with login/wrong password) failed, the module considers the
session is still bound, while the AD server thinks it has no permission anymore.
So, on the next search, the AD server replies with a 'Success' with no entry,
that the module interprets as a 'User not unique'.

Since I don't mind the module establishing a new session everytime, I made sure
that it's killed after every search.

If I have the time, I'll try to make a more consistent patch

IS this the right mailing list to post it or should it go to an Apache one now
that this module has been included ?

My quick fix:
$ diff mod_auth_ldap.c~  mod_auth_ldap.c
279c279
<     util_ldap_connection_close(ldc);
---
>     util_ldap_connection_destroy(ldc);


Laurent Blume wrote:

> I snooped the packets, and I did notice something weird:
>
> When there is a successful authentication (login and password are ok on the
first try), the conversation between the Apache server and the LDAP server goes
like this:
>  - new TCP session established;
>  - bind request with the AuthLDAPBindDN and AuthLDAPBindPassword;
>  - bind result: success;
>  - search request with the Base DN, attribute name, and the login entered as
the attribute value;
>  - search result: success, containing only one value;
>  - bind request with the DN in the value just received;
>  - bind result: success;
>  - TCP session ends;
>
> All those steps are repeated every time.
>
> When the login password is wrong for the first try, it goes like this:
>  - new TCP session established;
>  - bind request with the AuthLDAPBindDN and AuthLDAPBindPassword;
>  - bind result: success;
>  - search request with the Base DN, attribute name, and the login entered as
the attribute value;
>  - search result: success, containing only one value;
>  - bind request with the DN in the value just received;
>  - bind result: Invalid credentials;
>
> The main difference being, _the TCP session is not closed_.
> When there is another try with the same login, whatever the password is, there
is no new TCP session, it continues in the same, right after the bind result,
like this:
>  - search request with the Base DN, attribute name, and the login entered as
the attribute value;
>  - search result: success, containing no value;
>
> Nothing else, the TCP session is still *not* closed, it continues with the
same values for every try.
>
>  From what I understand, since the last Bind request failed, the AD server
considers the client has no authorization. Its behaviour in that case is to
reply with a Success, but with no value returned. 0 being different from 1, the
module interprets this as 'User is not unique'.
> I haven't used any other LDAP server so far, but I've seen that AD is
different in that it requires authentication before allowing a search.
> Actually, a server allowing an anonymous search would probably work in my
case, so I guess it's AD particular behaviour that is not correctly handled.
>
> I've started to look at the sources to get a better understanding on what goes
on, but my C days are a bit far in my past, I'm not sure I'll be able to fix that.
Comment 1 till toenges 2003-02-21 10:58:43 UTC
i have exactly the same problem with openldap 2.0.25, apache 2.0.44 and freebsd 4.7. the quick fix solved the problem for me. i agree that the problem seems to be that the module assumes that the session can be used for authentication attempts again, which is not be permitted by the ldap servers access control.
Comment 2 Marte Castro 2003-04-30 22:50:23 UTC
I have the same problem, I'm using:
httpd-2.0.44 against ms active directory (ms w2k)
Comment 3 Jeff Trawick 2003-11-21 17:22:01 UTC
I'm going through the bug db to make sure patches are findable.  Please see 
http://httpd.apache.org/dev/patches.html
Comment 4 John Coonrod 2004-03-26 13:31:00 UTC
I have this problem in my production mandrake 9.2 server, and would love to just
get a fixed binary - is this being fixed in the actual binaries, or will this
just continue to be a sourcecode patch?
Comment 5 Stephen Duncan Jr 2004-04-05 13:42:06 UTC
Seeing this on Windows 200 SP4 Active Directory, using Apache HTTP Server 2.0.49
on Windows.  

When incorrect password is input, error log logs:

[*date*] [warn] [client *ipaddress*] [832] auth_ldap authenticate: user
*username* authentication failed; URI *uri* [ldap_simple_bind_s() to check user
credentials failed][Invalid Credentials]

Subsequent attempt to login with correct password cause this error in the logs:

[*date] [warn] [client *ipaddress*] [832] auth_ldap authenticate: user
*username* authentication failed; URI *uri* [User not found][No Such Object]
Comment 6 Graham Leggett 2004-05-20 23:01:41 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 7 Laurent Blume 2004-05-21 15:15:31 UTC
I applied the patch to 2.0.49, built it with similar options.
It now authenticates correctly against the AD server, even when entering invalid
login/password combinations first.

So it seems to fix the problem for me.
Comment 8 Graham Leggett 2004-05-21 16:36:00 UTC
Sweet, thanks :)
Comment 9 joshua@idx.com.au 2005-02-09 07:15:08 UTC
Does 2.0.53 fix this problem?? 
I was using 2.0.47 and it has the same problem...

I couldnt change the source,

from:
<     util_ldap_connection_close(ldc);

to
>     util_ldap_connection_destroy(ldc);


 It would give compile errors




thanks

Joshua
Comment 10 Graham Leggett 2005-06-13 12:18:53 UTC
This was fixed in v2.0.51 - can you confirm whether this is still broken, and
reopen if so?