Full_Name: George Tzanetis Version: 2.4.23 stable OS: Red Hat Enterprise 5.5 URL: Submission from: (NULL) (62.169.213.126)

I have built openldap 2.4.23 with the back-ndb in 4 machines.

I created the slapd.conf as follows:

pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args

####################################################################### # NDB database definitions ####################################################################### #NDB database defintions database ndb suffix "dc=example,dc=gr" rootdn "cn=root,dc=example,dc=gr" rootpw secret dbconnect 192.168.6.11 dbhost 192.168.6.12 dbport 3306 dbname openldap dbuser ldapUser dbpass "1234" dbconnections 3 dbsocket /tmp/mysql.sock

attrblob description index uid

####################################################################### # Monitor Database definitions ####################################################################### database monitor

loglevel 5

My problem is that I can authenticate to the ldap with any password for the cn=root,dc=example,dc=gr (rootdn) user, as long as I specify a password.

To make it clearer, all the following ldapsearches work:

ldapsearch -h 192.168.6.10 -b 'dc=example,dc=gr' -w secret1 -D "cn=root,dc=example,dc=gr"

ldapsearch -h 192.168.6.10 -b 'dc=example,dc=gr' -w secret -D "cn=root,dc=example,dc=gr"

ldapsearch -h 192.168.6.10 -b 'dc=example,dc=gr' -w sec -D "cn=root,dc=example,dc=gr"

ldapsearch -h 192.168.6.10 -b 'dc=example,dc=gr' -w " " -D "cn=root,dc=example,dc=gr"

If I do not specify a password, (i.e. -w flag is omitted) I get the message: ldap_bind: Server is unwilling to perform (53) additional info: unauthenticated bind (DN with no password) disallowed

In addition if I don input the correct rootdn user, I get the message: ldap_bind: Invalid credentials (49).

This behavior exists in all instances of openldap with ndb as back-end.

I did some more testing, and I built openldap with the bdb and ndb backends. The issue appears only to the suffix that is stored in the ndb back-end and not to the bdb back-end, so there must be something wrong with the bind operation of the slapd-ndb.

Finally, I would like to state that with the slapd-ndb, all the ldapsearches / modifications / deletions are performed correctly, even if the rootpw password is wrong.