Re: 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.

-jim
Jim Willeke


On Mon, Aug 10, 2009 at 11:19 PM, Howard Chu <[email protected]> wrote:

> 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.
>>
>
> TODOs:
>  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.
>
>
> --
>  -- 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ldapext
>

_______________________________________________
Ldapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ldapext