>>> Michael Ströder <[email protected]> schrieb am 22.03.2021 um 19:07 in Nachricht <[email protected]>: > 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.
