DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17274>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=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 erroneous login attempt Product: Apache httpd-2.0 Version: 2.0.44 Platform: HP OS/Version: HP-UX Status: NEW Severity: Normal Priority: Other Component: mod_ldap AssignedTo: [email protected] ReportedBy: [EMAIL PROTECTED] (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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
