>> Michael Ströder <michael(a)stroeder.com> schrieb am
22.03.2021 um 19:07 in
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
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,
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?)