[Date Prev][Date Next]
Re: [ldapext] Unfinished business: password policy and VLV
pwdCheckQuality Enforcement, I think, must be a choice on Auth and on all operations.
There are conditions where this could force everyone who authenticates to change their password in a single day. With 1,000's or 1,000,000's of users, an organization would be overwhelmed.
Some conditions I could think of are:
- Change to the password policy
- Transitioning to a new LDAP server or version. Where the "old" LDAP server did not use the or enforce the password policy.
- Synchronization engines used to sync a password from a system whith a weaker policy to a system with a stronger policy. It sometimes difficult to match password policys between different vendors/versions of LDAP servers.
On Mon, Aug 10, 2009 at 11:19 PM, Howard Chu <firstname.lastname@example.org>
Fixed, will be in next draft.
Howard Chu wrote:
9) In 7.4 (oops. forgot to take pwdGraceExpiry into account on this edit.)
Equivalent text probably belongs in 4.3.
12) In 8., note that if a single password value is stored in multiple formats
simultaneously, it still counts as just a single password value. It's common
when centralizing multiple systems (SASL, Samba, Kerberos, NSS) into LDAP to
need to have the password in multiple forms. They are all equivalent and are
always changed simultaneously, so they are effectively only one password.
This appears to be a mistake, I'm reverting this to the 09 version.
16) 9.5 Other Operations - also allow accountLocked result. This allows
Search+ppolicy control to be used by SASL etc., instead of the ExternalBind
stuff I mentioned in previous emails.
There are still several TODO sections from 09 which I didn't touch.
do we need to have configurable backoff algorithms for login delays? seems like overkill.
password safe modification, intruder detection - one possibility is to force the session to immediately terminate on failure. That then accomplishes the aim of requiring users to authenticate first.
pwdCheckQuality, checking during authentication. Sounds like a good idea; should it be done always, only when the stored password is hashed, or as a configurable choice? The result should be that pwdReset is effectively set when the verification succeeds.
advertisement and discovery - the control should be advertised in supportedControls in the rootDSE, what else needs to be said?
administrativeRole - will use another OID under the current arc.
ppolicy and replication - I think there are enough caveats in here now.
IANA considerations - I've filled these in according to RFC4520.
Ldapext mailing list