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.