[Date Prev][Date Next]
Re: [ldapext] Unfinished business: password policy and VLV
Howard Chu wrote:
9) In 7.4 (oops. forgot to take pwdGraceExpiry into account on this edit.)
Fixed, will be in next draft.
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.
Equivalent text probably belongs in 4.3.
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.
This appears to be a mistake, I'm reverting this to the 09 version.
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
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.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Ldapext mailing list