[Date Prev][Date Next]
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
> email@example.com 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).
>> Do not try rootpw if rootdn names an existing entry.
>> Fail if rootpw is missing or does not match, more complicated
>> 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"