Re: please publish ldap password policy draft

[Helmut Volpers <Helmut.Volpers@icn.siemens.de>]

Hi,


Ludovic Poitou schrieb:
> 
> 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.

But in a normal environment an administrator will not allow a compare
to the Password for anonymous bind ?
> 
> >
> >
> > >      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 it mean if you have a password policy it have not been checked by
the Server if you do a compare ?

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

Does it mean the compare should only be used for authentication ?

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

begin:vcard 
n:Volpers;Helmut
tel;fax:+49-89-636-45860
tel;work:+49-89-636-46713
x-mozilla-html:FALSE
url:http://www.siemens.com/bus-com
org:Siemens AG
adr:;;;Munich;;81730;Germany
version:2.1
email;internet:Helmut.Volpers@icn.siemens.de
title:Directory Server Architect
fn:Helmut Volpers
end:vcard