Re: OpenLDAP / GUI client password compatibility: advice requested

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

First, s/encrypt/hash/.

At 03:21 PM 12/14/2003, Betts, Chris wrote:
>    When an administrator creates a new user entry, or adds a
>userPassword for the first time, the userPassword value is passed in as
>plain text - the server may (depending on configuration) 'encrypt' (one
>way hash really) the value locally.

No.  slapd(8) never encrypts/hashes userPassword values provided
by the user/admin (via LDAP Add/Modify Entry or via slapadd(8)).
That would be clearly violate the data model -- servers are
required to preserve user application data -- userPassword is a user
applications attribute.

slapd(8) will, when configured to do so, hash passwords provided
via the LDAP Password Modify operation (RFC 3062) and store these
values in userPassword.  When this is done, it is wise not to
expose userPassword to user applications as user applications
do not generally expect values of userPassword to be
encrypted/hashed (RFC 2256).

>    When a user binds using username/password, they enter their plain
>text password - the server can then compute the 'encrypted' value for
>the purpose of comparision.

Basically (but see below).

>    When the user or administrator *modifies* an existing userPassword
>attribute, they need to encrypt(hash) it on the client.

No.  They should use the LDAP Password Modify operation to
request the server store the password per the server's policy.
(The password may not even end up in userPassword.)

>This modification is the *only* time that the client needs to encrypt the
>value.

The client never needs to encrypt values.

>    If the client accidently encrypted the userPassword value on
>binding, the bind would fail.

When the client is binding, it's not necessarily providing a
value of userPassword (or the value in which value(s) of userPassword
were derived), it is providing the user's password.  The user's
password may or may not be stored in the directory and, when so,
may or may not be stored in userPassword.  But, per standard, when
so, it should be clear text.  (Password schemes are a hack.)

>    If the client accidently encrypted the userPassword value on first
>creation, later binds would fail.

Well, some servers might not actually support hashed userPassword,
so a client which stores a hashed value in userPassword might be
quite surprised to find a server which treat the hashed value
as the password.

This is why clients should not hash password ever.  They should
just use Bind to bind and Password-Modify (RFC 3062) to modify
passwords.

>    Is this correct?

See above.

>Or is there some other way the client should work?

See ldappasswd(1).

>JXplorer is a generic ldap/dsml browser that attempts to work well with
>all common ldap servers, and I want to make it easy for my users to work
>well with openLDAP, so I'd like to avoid any misunderstandings, which is
>why I haven't incorporated the patches I've been given quite yet :-).
>
>    cheers,
>
>       Chris
>
>    
>Dr Christopher Betts
>Architect
>CA, Melbourne, Australia
>Dev Manager UDDI, DSML, JXplorer