Re: (ITS#4962) inconsistent Bind(rootdn) behavior

[hyc@symas.com]

h.b.furuseth@usit.uio.no wrote:
> Pierangelo Masarati writes:
>> Fixed in HEAD.  Now all backends honor rootdn bind (with slight
>> variations; see back-null) through a common interface; in some cases,
>> it's a blind fix (shell, perl, passwd).  I think I also fixed an
>> inconsistency in back-bdb: as far as I understand, a bind with rootdn
>> and incorrect rootdn password, or in case rootpw was null, originally
>> passed through, probably either by mistake or to check if an analogous
>> identity were defined in the database.  I consider this an
>> inconsistency, but please review.
> 
> The back-bdb behavior sounds right: It should remain possible to have
> the rootdn's password in an entry instead of in slapd.conf.  Among other
> things, if the site has routines for regular password changes and "your
> password is getting old" warnings, those will then cover rootdn as well.

(But aging out the administrator's password is a good way to lock yourself out 
of your system. Note that ppolicy always lets the rootdn past all policy checks 
for this reason.)

> OTOH if such an entry and rootpw both exist, I think it's a bug to
> accept both passwords.  I think an existing rootpw should override the
> entry's password, that's safest and least surprising (if the admin sets
> rootpw and someone else manages to create an entry with dn: <rootdn>).

I disagree; this behavior has existed for a long time and there are probably 
people out there relying on it. This isn't much different from the fact that 
userPassword itself is multivalued. I seem to recall this behavior being 
documented somewhere, can't find the reference at the moment.

> A few icky issues:
> 
> - if you've got rootdn from a SASL/EXTERNAL DN and rewrite it to inside
>   the database's DIT, it would be possible to create such an entry with
>   a password.  We could advise people to use a DN outside the database
>   suffix in this case, and/or accept 'rootpw' with no parameter as
>   explicitly refusing Simple Bind with the rootdn.

I don't think these cases merit any special consideration.

> - back-null's "bind on" (accept Simple Bind with any password).
>   Maybe in this case it's best to treat rootdn without rootpw as
>   "reject simple bind as rootdn", like your patch does.

If "bind on" means "accept Simple Bind with any password" then rootpw should be 
irrelevant here. Of course, for back-null the rootdn itself is pretty meaningless.
-- 
   -- Howard Chu
   Chief Architect, Symas Corp.  http://www.symas.com
   Director, Highland Sun        http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP     http://www.openldap.org/project/