Hello,

I am trying to move a meta-directory from version 2.3.43 (included with RHEL 5) to version 2.4.31 (openldap-ltb packages on RHEL6). I've tried to follow the man pages and FAQ properly in using newer directives for the same functionality, but searches that previously worked on 2.3.43 no longer work.

The meta database in the 2.3.43 is defined like so:

----- database meta suffix "dc=example,dc=edu"

uri "ldap://central-ldap.example.edu/ou=people,dc=example,dc=edu" idassert-bind bindmethod=simple binddn "cn=account,ou=service,dc=example,dc=edu" bindpw secret

uri "ldap://localhost/ou=groups,dc=local,dc=example,dc=edu" idassert-bind bindmethod=simple binddn "cn=Manager,dc=local,dc=example,dc=edu" bindpw supersecret ---------- This seems to work (People are retrieved from the upstream ldap and a local bdb [not shown] database serves groupofnames memberships specific to our org unit), with deprecation warnings:

/etc/openldap/slapd.conf: line 118: "binddn" statement is deprecated; use "acl-authcDN" instead /etc/openldap/slapd.conf: line 119: "bindpw" statement is deprecated; use "acl-passwd" instead /etc/openldap/slapd.conf: line 123: "binddn" statement is deprecated; use "acl-authcDN" instead /etc/openldap/slapd.conf: line 124: "bindpw" statement is deprecated; use "acl-passwd" instead

[1] I've assumed binddn and bindpw are used by slapd-meta to perform searches against the remote directory. Is this wrong?

Moving these configuration options to 2.4.31, my <database meta> is defined like so (focusing on the remote LDAP entry):

database meta suffix "dc=example,dc=edu"

uri "ldap://central-ldap.example.edu/ou=people,dc=example,dc=edu" idassert-bind bindmethod=simple binddn="cn=account,ou=service,dc=example,dc=edu" credentials="secret"

Searches don't work and debug output includes among other information:

4fb288b5 conn=1001 op=11 meta_search_dobind_init[0] mc=0x7ff4c0104b20: non-empty dn with empty cred; binding anonymously request done: ld 0x7ff4c4101f40 msgid 2 res_errno: 48, res_error: <binds with a dn require a password>, res_matched: <>

Is there a reason why credentials aren't being used along with bind dn? Was I wrong about assumption [1]?

Hmm..the search works if I use "rebind-as-user yes" as an option for the remote URI, but I've not figured out from slapd-ldap(5) why this is so...the client credentials are not valid upstream, its a dn specific to the local database.

Any help greatly appreciated (as before!) -Eugene