ando@sys-net.it wrote:

h.b.furuseth@usit.uio.no wrote:

...

Backends are quite inconsistent about how Bind treats rootdn/rootpw. After a quick browse of the HEAD code, it looks like this - I'll investigate closer if needed:

rootpw supported: Yes: config, bdb, meta, monitor, ldif, HEAD:null, sql, overlay retcode. No: dnssrv, ldap?, RE23:null, perl, relay, shell.

back-ldap doesn't care about rootdn/rootpw; back-meta does mostly for historical reasons (could be removed with some work).

...

(Bind not supported: passwd).

Rootpw vs. normal Bind as rootdn (typically when rootdn names an entry): config, bdb, null, sql, overlay retcode (I think): Try rootpw first, then if failure try normal Bind (even if rootpw exists but the Bind password does not match it). ldif: Do not try rootpw if rootdn names an existing entry. meta: Fail if rootpw is missing or does not match, more complicated otherwise. monitor: Fine - there are no entries with passwords.

(yet :)

I discovered that back-monitor may benefit from having a rootdn because this provides a means to easily workaround any ACLs. The availability of rootpw is also important because I ran into few cases where no other means to authenticate were available, and all in all this feature (I mean: rootdn w/ rootpw comes for free from the database infrastructure).

Don't you do this in test043:

"# HACK: use the RootDN of the monitor database as UpdateDN so ACLs apply"