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.