Antw: [EXT] Re: warning in SLAPO_PPOLICY(5) regarding ppolicy_hash_cleartext
>> Michael Ströder <michael(a)stroeder.com> schrieb am
22.03.2021 um 19:07 in
Nachricht
<d2b355b4-0c27-945c-21e4-418ccad1d8ca(a)stroeder.com>:
On 3/22/21 6:49 PM, Christopher Paul wrote:
> I read the warning in SLAPO_PPOLICY(5) regarding ppolicy_hash_cleartext:
> "It is recommended that when this option is used that compare, search,
> and read access be denied to all directory users".
Maybe at that point in the manual there could be a short explanation how
password authentication works: Obviously "someone" has to be able to read the
password in order to check it. At least all the typical UNIX password checks
work like that.
IMHO this is more a warning regarding the functional model than a
security warning.
Because strictly speaking an LDAP client expects the server not to muck
with attribute values. To be more clear: If the client writes value
'bar' to attribute 'foo' it expects a search with (foo=bar) to return
that entry later. Similar with compare requests.
Wording could be better though.
> Am I correct to presume that this means that the compare, search, read
> access be denied for directory users' _own_ (self) userPassword attrs,
> right?
In general access to attribute userPassword should be very restrictive.
Only replicas should be granted read access. Account owner (self) should
be able to write (not read!) the userPassword value (=w).
There are use-cases where userPassword values are read by an LDAP client
for using them as shared secret with challenge-response mechs, e.g. some
RADIUS methods. But in these cases passwords are not hashed anyway.
> Because compare, search, read access to _other_ users' userPassword
> is rightfully denied typically by any sensible access control
> ruleset. (Right?)
Right.
Ciao, Michael.