[Date Prev][Date Next] [Chronological] [Thread] [Top]

[ldapext] password policy: multiple subentries, multiple password attributes, ....



The spec specifically allows for an user entry to be controlled by multiple policies (each for a different password attribute) but then defines pwdPolicySubentry to be single-valued.

It seems to me that the text as a whole doesn't really well consider the implications of multiple applicable password policies.

In our current implementation, we do implement 5.3.1, and mandate that only a single password policy be applicable to a given user.

We currently looking at userPassword v. authPassword implications with regard to auto-migration, as we're now supporting the latter for SCRAM authentication.  I think we'll assume that if both are present in an entry, they represent the same same user password.   We'll like need to support both RFC 2307 hashing and in conjunction with SCRAM authPassword hashing so that users can use either TLS+SimpleBind(WithPassword) or SCRAM.

I don't see the value of having two disjoint password policies, one for each attribute.   What I believe our customers will demand is an unified password policy covering both of these attributes.  (I can see a possible desire to support a disjoint password policy covering passwords for directory application specific passwords, such as when one has a different directory password from say an email password stored in the directory.  However, our customers which have different passwords for different directory applications tend to rely on multiple entries per user, one per directory application (with service-level authorization restrictions), not multiple passwords attributes in a single entry.)

-- Kurt
_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext