2.4.31 slapd-meta

[Eugene Vilensky <evilensky@gmail.com>]

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