[Date Prev][Date Next]
Re: (ITS#4962) inconsistent Bind(rootdn) behavior
> 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/