[Date Prev][Date Next]
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
> 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.
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).
> The manpage is (fortunately:-) unclear on what happens in this case.
> Check if op->orb_method == LDAP_AUTH_SIMPLE:
> Yes: config, bdb, meta, monitor.
> No: ldif, null, sql, overlay retcode.
I don't think we can get to calling bi_op_bind() otherwise... could even
be an assertion.
> Set op->orb_edn (op->oq_bind.rb_edn) from be_root_dn() on success:
> config, bdb, monitor, sql.
> Set op->orb_edn on failure:
> bdb: Sometimes, from &e->e_name.
> sql: Always, from op->o_req_ndn.
Not sure what does this mean: op->orb_edn should only be set in case of
> Set rs->sr_err = LDAP_SUCCESS on success:
> ldif, meta
For consistency, I presume. The caller will just check the response code.
> Reset rs->sr_text:
> Which behavior is right? I'm wondering if Bind should fail if rootpw
> exists but the Bind password does not match it.
> In any case, methinks we need a be_rootpw_bind(op, rs) function which
> takes care of this consistently, so bi_op_bind in most cases can just do
> if (be_rootpw_bind(op, rs)) return rs->sr_err;
> If needed it could accept rs==NULL to just check the password - like
> be_isroot_pw() but with more return codes to distinguish different
At this point, it might be worth moving this check outside bi_op_bind().
Wait a moment: we need to do something else at least in back-meta if
rootdn bind succeeds... but I think that could be changed.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172