Re: ldap password policy approach

[Jim Sermersheim <JIMSE@novell.com>]

Thanks Kurt.

After mulling this over, I see two general directions we can take this draft. We could attempt to solve the problems you bring up by applying one of these solutions: Define a new operational attribute which is used to modify passwords (via LDAP modify), or define a bind control (as you suggested) or an extension which would isolate the mechanism from the modify code. In either case, the server implementation would be free to store the user password in whatever attribute/format it chooses. Each solution has its pros and cons.

The other direction is to divorce the password policy document from the mechanisms used to change passwords.  In other words, the policy document would only present policy which is used when performing certain password related operations, not dictate how one goes about performing those operations. In this case, I would expect to see language like, "The LDAP modify operation MAY be used on the userPassword attribute, or another mechanism MAY be used to change the password". A future document could address the issue of standardizing the operation used to perform password modifications.

I'm leaning towards the second approach because it leaves the policy document in a cleaner state.  One issue I see is the prescribed format of the pwdHistory attribute.

What do you think?

Jim

>>> "Kurt D. Zeilenga" <kurt@boolean.net> 10/23/99 11:38:06 AM >>>
At 02:20 PM 10/22/99 -0600, Jim Sermersheim wrote:
>>>> "Kurt D. Zeilenga" <kurt@openldap.org> 10/22/99 1:22:33 PM >>>
>That said, I think using LDAP modify to modify your password is not so much of a leap that it's confusing or poor design

The first problem with using modify to modify your password is that it
assumes that the password is stored in a user modifiable attribute.
RFC2251 allows a server to use other means.  If your approach were
to become required, it would remove this flexibility.

The second problem is that approach requires broad modifications
to server implementions.  The behavior of most every operation
has to be changed.  The behavior is dependent upon additional
per-session state information.  Efficient implementation
of your approach may require significant server redesign.

The third problem is that the approach requires the server to
examine each and every add,modify,(delete?),and compare to
determine if it acts upon the password attribute such
that it can execute appropriate codes.   The increases the
general overhead of these operations.

The approach also disallows operations which must be allowed
(per RFC2251).  The client may, at times, be only be allowed
to modify the password attribute.  However, the client must
be allowed to examine of schema rules for that attribute.
The client should also be allowed to example the password
policy and RootDSE.  Though this can be resolved by special
case processing... it just adds more complexity.

It also appears that the approach appears to disallow
access to the stored value, requiring clients to provide
the password instead of the encoding of the hash of the
password.   There are numerous applications which require
such access (administrative purposes, replication, etc.).

The approach requires significant modification to applications
desiring to interact with the password policy system.  Existing
clients might get quite confused in some situations offerred
by the approach.

I am also concerned that this approach might have hidden
synchronization requirements placed upon servers to enforce
this policy in face of concurrent operations posted by the
client.