(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.