Re: Unfinished business: password policy and VLV

Michael Ströder wrote:
> 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?

I have already dropped this line of thought, so it's a moot point now.

I was thinking of SASL, Kerberos, and Samba ("external authentication 
agents"), which each can use LDAP as an authentication store, but perform the 
actual credential verification themselves. I wanted the ppolicy control 
attached to the Search request, to indicate that an authentication was being 
started. And I wanted the control to be attached to a Bind request, to allow 
the external agent to tell LDAP what the outcome of the authentication attempt 
was. This way the directory server can continue to maintain all the policy 
state thru the Bind mechanism. The external agent cannot simply issue an LDAP 
Simple Bind because they won't have the plaintext credentials on hand. I 
wanted a cookie in the control to authenticate that this Bind was a legitimate 
followon to the earlier Search, to prevent arbitrary clients from sending 
bogus "Bind/Failed" requests to the directory and thus effortlessly locking 
out any user of their choice.

But the existing ppolicy spec already allows external authentication, by 
virtue of the Compare request. After an external agent retrieves the secret 
and verifies the client, it just needs to do a Compare request to update the 
directory's policy state. Since it has already retrieved the actual 
credentials, it can do a Compare with the current value to indicate a 
successful authentication, and a Compare with some different value to indicate 
a failed authentication. And the issue of bogus requests is mitigated by using 
access controls to restrict who can do search/compare on the authentication 
secret.
-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/