valid DN and empty password : bug?

[Michael Ströder]

Olivier Grisel wrote:
> 
> The server has an inetOrgPerson entry 'uid=toto,dc=mydomain,dc=com' with
> the corresponding userPassword set to some regular non empty value
> (something like '{SSHA}sgqsdfqs[...]' ).
> 
> When a do a simple_bind_s with toto's DN and the empty password string,
> the simple_bind_s succeeds! Although, if I try with another (non empty)
> wrong password string I get the expected ldap.INVALID_CREDENTIALS 
> exception.

This is a normal behaviour. But as you already experienced it depends on 
the LDAP server implementation.

(I remember this being debated to death on some IETF mailing lists.)

> but I
> haven't asked python-ldap to bind anonymously, I want it to try to bind
> with the specified DN (uid=toto,dc=mydomain,dc=com).

Some LDAP servers regard an empty password as implicitly being an 
anonymous bind but the log the bind-DN.

> I can't reproduce this bug with my OpenLDAP (slapd) server, since I get
> the following exception ( toto's DN with an empty password):
> """
> ldap.UNWILLING_TO_PERFORM: {'info': 'unauthenticated bind (DN with no
> password) disallowed', 'desc': 'Server is unwilling to perform'}
> """
> OpenLDAP refuses empty passwords.

The OpenLDAP developers simply had a different point of view how to 
handle such a simple bind request by default. You can change this 
behaviour. See the description for config directive "allow bind_anon_dn" in
man 5 slapd.conf:

allow <features>
[..]
bind_anon_dn allows unauthenticated (anonymous) bind when DN
is not empty.
[..]

Refer to the OpenLDAP lists and their archives for reading more about it.

> It seems to me that python-ldap falls back to anonymous if the
> authentication with empty password fails,

Nope! The LDAP client parts are just a primitive wrapper around the 
OpenLDAP API.

Note that my LDAP client application web2ldap implicitly assumes a anon 
bind if a users enters a bind-DN without a password. The bind-DN is set 
to empty string by web2ldap in this case. But python-ldap simply passes 
what the client application told it to send to the LDAP server.

> which is not the expected
> behavior (or is it ?). I would like it to raise ldap.INVALID_CREDENTIALS
> instead.

In case of an error python-ldap directly maps the result code returned 
by the LDAP server to an ldap.LDAPError exception raised. python-ldap 
has no additional behaviour regarding error handling. Your LDAP client 
application has to deal with different error codes returned by different 
LDAP server implementations.

> I am sorry if this is an known bug,

It's definitely not a python-ldap bug.

Ciao, Michael.