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

[h.b.furuseth@usit.uio.no]

hyc@symas.com writes:
>> 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.

Sure, so it depends on just how central that password is.  But if I've
ignored a "your password is getting too old" warning for an admin user
and it gets disabled I've screwed up anyway, I prefer to set things up
to err on the side of caution.  Though if it's even hard to log in to
the server machine and fix things there, I'd be in trouble.

> Note that ppolicy always lets the rootdn
> past all policy checks for this reason.)

Actually I've never used ppolicy, so I was thinking of our site's
automatic emails when we need to change our passwords.

>> 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.

Good point.  I would still like to get rid of it though.  Even if it
takes an extra slapd.conf keyword.

> 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.

I disagree - the difference is that rootpw vs. userPassword are stored
in different places and different people can modify or create them.

The rootpw doc in slapd.conf(5) looks misleading to me - at least it's
easy to read it differently from how it works.

I'm getting a deja vu feeling here, but I'm not sure from which
discussion...

>> 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.

OK.  Well, I might do something more general to the doc which touches on
it anyway if I think of a better way to write it.

>> - 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.

I looked cross-eyed at that code.  I meant bind off.  Nevermind.

-- 
Hallvard