Re: Unfinished business: password policy and VLV

Howard Chu wrote:
> Howard Chu wrote:
>> And also an extended op "ExternalBind" for allowing external 
>> authentication providers to interact with the existing policy. I.e., this
>> op will supply an LDAP username and a success/fail code to the directory
>> server, and the server will execute the policy mechanisms accordingly.
>> (E.g., if a Fail code is supplied then the failure time and any relevant
>> lockouts are recorded.)
> 
> Thinking about this some more, I don't think a new exop is the right
> approach. Instead, I would use a new ppolicy control which can be
> attached to a Search request. It would only be valid for searches of
> Base scope. It would result in a ppolicy response control being attached
> to the search entry that fulfills the search request. This would allow
> an external authentication mechanism to discover if the account is
> already locked, password is expired, etc. The response control would
> also include an opaque cookie.

Thinking in this direction a bit further I wonder how requests with Proxy
Authz control attached should be handled in case of (temporarily) locked accounts.

> We would also define a new ppolicy control which can be attached to a
> Simple Bind request. This control would carry the cookie from the
> previous response control, and a boolean success/fail value. If the
> cookie is valid, the credentials of the Bind request will be ignored and
> the boolean success/fail code is used to update the ppolicy state for
> the specified user.

What's the use-case for that?

> At this point I'm preparing a new draft of the behera-ppolicy document
> with the several additions I've mentioned. I am also preparing a new
> revision of the RFC2307 schema, and a draft of a Kerberos 5 schema. Both
> of these latter documents will depend on the ppolicy draft. I plan to
> post these in the next couple of days.

This all sounds very reasonable.

Ciao, Michael.