[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: RFC2256: userPassword



At 11:17 AM 6/30/99 -0700, David Boreham wrote:
>Yes, the whole discussion dissapeared in a puff of logic.

I concur.

The following is just to clarify common practices...

>Clients shouldn't be granted permission to
>read userPassword.

Setting the password, of course, requires write permission
(preferably only "self write" is granted). Write permission
should be orthogonal to read permission but isn't on some
implementations (such as OpenLDAP 1.x).

>Clients have no business wondering what the
>value of userPassword means.

In general, I agree.  However, if a client-side password
hash generation model is used (such as in OpenLDAP 1.x),
the client setting the password must have knowledge what
values are acceptable to the server.

Note: a later version of OpenLDAP will, in addition,
support server side password hash generation.

>However, sometimes folk do care:
>
>1. When replication sends the password
>information from one server to another.
>2. When the contents of a server are
>exported to a flat file, and subsequently
>imported into another server.
>3. When user information, including hashed
>password values, is migrated from another
>database (e.g. NIS, Oracle).
4.  When client side hash generation model is used.

>> So, it _is_ different for each different vendor. As percieved by clients.
>Until a standard is defined, yes.

I concur.