Re: please publish ldap password policy draft

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

Helmut Volpers wrote:

> Hi,
>
> Some comments and questions.
>
> <ZAP>
> >       Specifically, the password policy defines:
> >
> >       1.  The maximum length of time that a given password is valid.
> >       2.  The minimum length of time required between password changes.
> >       3.  The amount of time before a user's password is due to expire
> >           that the user will be sent a warning message.
> >       4.  Whether users can reuse passwords.
> >       5.  The minimum number of characters a password must contain.
> >       6.  Whether the password syntax is checked before a new password
> >           is saved.
> >       7.  Whether users are allowed to change their own passwords.
>
> Why is it needed in the password policy ? It's an item of AccessControl.
>

This is an element of definition of a Password Policy. It can be implemented as
an AccessControl or by other means...

> <...>
> >       ( pwdSchema.1.3
> >         NAME 'pwdAllowUserChange'
> >         DESC'a flag which indicates whether users can change their
> >             passwords'
> >         EQUALITY booleanMatch
> >         SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
> >         SINGLE-VALUE
> >         USAGE directoryOperation )
>
> Again I think this is Access Control.

Same as above... It's a definition of an element of the policy.
Yes, it could be implemented as an ACI.

> <...>

> >    12. Server Implementation
> >    12.1 Password policy initialization
> >
> >       The pwdPolicy object class holds the password policy settings for
> >       a set of user accounts.
>
> How is the set of user-accounts specified ? over a Subtree specification
> or
> a filter ? Is it not a case where subentries (operational objects) make
> sense?
> Subentries because you don't want to see this entries when you browse
> through the DIT.
>

This need to be worked. We need to specify a way to associate a user with a
password policy.
This could be subtree based via the use of subentries. But you may want to
define your policies with Groups or other means.
The question is still open to discussion. See section 14.


>
> <...>
> >    12.5 Compare Operation
> >
> >      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
> >      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.
>
> what's the overhead here ? before you compare you will also bind
> authenticated ?
>

This is for 3-tier application that uses LDAP to authenticate users. The
application opens an LDAP connection to the Directory Server, authenticate
itself and then uses compare operations to authenticate its own clients.


>
> >      ACLs may be used to restrict this comparison from being made.
>
> In the normal case the compare to a UserPassword is not allowed by ACLs.

It may be allowed for specific users such as Administrators or Applicative
Users.


>
> >
> >      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
>
> will the returncodes and errormessages change for the compare operation
> ?

The return code should always be CompareTrue or CompareFalse. Error messages
may change. Controls should be added in case of failures due to a violation of
the password policy or in case of success and expiring password. The document
will be update in that sense.


>
> >
> >       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.
> >
> >       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.
> >
> >    13.  Client Implementation
> >    13.1. Bind Response
> >
> >      For every bind response received, the client needs to parse the
> >      bind result code, error message, and controls to determine if any
> >      of the following conditions are true and prompt the user
> >      accordingly.
>
> what happens if existing V2 or V3 clients get that bind responses back ?

Good question... We need to think about LDAP v2 clients who don't support
controls.


> <...>
> >    14. Association between Users and Password Policy
> >
> >       We have so far described two new objectclasses; one contains the
> >       password policy and the other contains password-related
> >       information in a user?s entry. We need an association between the
> >       password policy and users. Association via DIT or groups or any
> >       other method can be used. To make this policy work in a
> >       heterogeneous environment we need to describe a mechanism for the
> >       association. This work is still under investigation.
>
> I think there should be different password policies for "users",
> "administrators",
> "services", "CAs", etc.

This is a division of "Users" into roles, groups or categories. By user, I
guess we meant any entry that can be authenticated (contains a UserPassword
attribute).
This is why there's a need to associate an entry to a password policy.
This is still under investigation and subentries is one way.


>
> >
> >    15. Password Policy and Replication
> >
> >       The pwdPolicyObject defines the password policy for a set of
> >       users of the directory and must be replicated on all the
> >       replicas.
>
> I think that is easy if we define a subentry for the password policy.

This is the easy part.

>
> >
> >       The pwdInfObject class holds information related to password
> >       policy in the user?s entry. Some of the attributes have to be
> >       replicated on all servers, for the consistency of passwords and
> >       the policy. This is the case for pwdHistory, pwdExpirationTime,
> >       pwdAllowChangeTime which changes along with the userPassword.
> >       The other attributes may change each time the user binds to a
> >       server. It is up to the administrator to decide to replicate them
> >       or not.
> >       If they are replicated, it means that the retry counter, the
> >       grace login counter and the account locking are applied on the
> >       whole set of servers, but that the replication updates will be
> >       very important and may lead to conflicts in a multi-master
> >       environment.
> >       If they?re not replicated, it means that the limits apply on each
> >       server and therefore, a user can try to bind N times on each
> >       server.
> >       As long as the number of retries and the number of server are
> >       low, this can be an acceptable policy.
> >
> <...>

Ludovic.

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