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.
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.
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.
-- -- 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 Ldapext@ietf.org https://www.ietf.org/mailman/listinfo/ldapext