Re: please publish ldap password policy draft

[Anil SRIVASTAVA <anil.srivastava@Eng.Sun.COM>]

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

Does the DS apply the pwdDefaultStorageScheme hash to the password BEFORE the
compare is done?  All LDAP directory servers don't apply the storage hash
before the compare.  This is done only on a bind.  Hence using a compare for
user authentication is not gauranteed to work.


Anil Srivastava
iPlanet Messaging Server

| 
| >
| > >      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
| 
| 
|