Re: please publish ldap password policy draft

[Ludovic Poitou <ludovic.poitou@france.Sun.COM>]

Bob Joslin wrote:

> See comments under 12.5...
>
> Thanks,
>
> Bob Joslin
>
> <...>
> >    12.5 Compare Operation
> >
>
> I assume you propose this as a new extended operation.  Do you propose
> adding a new API?

No the Compare operation is an LDAPv2 and v3 operation.


>
>
> Also, I assume you must have bound to the directory to perform this
> operation.  Correct?

You may or may not have bound. This is an administrator choice.

>
>
> >      The compare operation may be used to compare a userPassword. This
> >      might be performed when a client wishes to verify that user's
> >      supplied password is correct. An example of this is an LDAP PAM
>
> When you say PAM, are you referring to a Posix compliant system that
> supports the Open Group defined PAM subsystem?  If so, how does the compare
> operation help?  I am having trouble coming up with feasable implemtation
> where the pam_authenticate back-end procedure does not need to open a new
> connection to the LDAP server each time it is called.  Thus I don't see how
> that example shows how you can eliminate the overhead of the bind operation.
>

Several 3-tier applications are using LDAP to perform password based
authentication. This can be the case of an web-ldap gateway, an Mail server, an
FTP server...or the LDAP Pluggable Authentication Module (PAM).
It's true that opening a connection for each authentication doesn't really
scale.
Many of these applications open one connection, authenticate themselves and
just check the user password using a compare operation using the User DN and
the user password. The compare operation is much faster because you don't have
to perform extra checking and computing that the bind operation has to do.


>
> >      redirector or an LDAP HTTP authentication redirector. It is
> >      desirable to use this rather than performing a bind operation in
> >      order to reduce possible overhead involved in performing a bind.
> >      ACLs may be used to restrict this comparison from being made.
> >
> >      If a server supports this behavior, it MUST comply with the
> >      following. Otherwise the password policy described in this
> >      document may be circumvented.
> >
> >    12.5.1 During a compare operation on the userPassword attribute
> >
> >      The server should
> >
> >       1. Check the pwdAccountUnlockTime attribute. If it exists, return
> >          LDAP_UNWILLING_TO_PERFORM to indicate that the account is
> >          locked.
> >
> >       2. If ACLs permit, compare the password.
>
> How are the ACLs evaluated?  Are ACLs applied for the user who is calling
> the compare operation or as the one being tested?  I assume the former but
> would like clairification.
>

ACL are applied for the user who is calling the compare operation.


>
> >
> >       3. If the password compares true, the server should clear the
> >          failure counter. If it compares false, it should check to see
> >
> >    Behera, Chu, Poitou, Sermersheim  Expires 20 April 2000    [Page 14]
> >
> >
> >    Internet-Draft             Password Policy           20 October 1999
> >
> >          if it's time to reset the failure counter, if so, set the
> >          failure counter to 1, otherwise increment the failure counter.
> >          If the failure counter exceeds the allowed maximum value, the
> >          server MUST lock the user account.
>
> Am I correct in understanding that you don't examine all password policy
> rules for a compare operation?  For example, suppose that the entry has a
> login time of day restriction (defind outside the scope of this schema.)

This is out of the scope of this draft. We're thinking about such services but
they are not dealing with passwords. So they should appear in a separate
document.


>
> Suppose a rule exists that says the DN may not bind from the hours of 6:00pm
> to 6:00am?  If a compare operation is performed at 7:00pm, should it return
> true (assuming no other failure conditions?)

This would have to be specified for a "Constrained Login Service".


>
>
> Should the compare operation return the extented controls that indicate if a
> password is about to expire, etc...?
>

I think it should. This will be clarified in the next version of the document.


>
> How should zero length password strings be treated?  In a bind operation the
> null string is a special syntax that means bind anonymously.  What does it
> mean for a compare?

It doesn't mean anything. You cannot compare with zero length password. The
client should not call the compare operation if it
doesn't want to perform authentication.

Ludovic.

--
Ludovic Poitou
Sun Microsystems Inc.
Sun-Netscape Alliance - Directory Group - Grenoble - France