Re: ldap password policy approach

["Kurt D. Zeilenga" <kurt@boolean.net>]

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.


> Who polices all the 3rd party authentication applications to
> make sure they're well behaved?

The administrator.  No approach which can stop a 3rd party
authentication application from circumventing the password
policy.  It's up to the administrator to choose well behaved
applications (and to define "well behaved").



----
Kurt D. Zeilenga		<kurt@boolean.net>
Net Boolean Incorporated	<http://www.boolean.net/>