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

Am I correct to presume that this means that the compare, search, read access be denied for directory users' _own_ (self) userPassword attrs, right?

Because compare, search, read access to _other_ users' userPassword is rightfully denied typically by any sensible access control ruleset. (Right?)

>> Michael Ströder <michael(a)stroeder.com&gt; 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".

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.