changed notes
changed state Open to Closed

>When a '{crypt}xxxx..' or '{sha}xxxx...' userpassword is modified with a
>cleartext value, that value is written un-encrypted into the attribute.

As per the defined syntax of userPassword [X.520].

>One would expect the server to encrypt the new value instead, following a
>default scheme (as in slapd.conf) or using the encryption scheme of the old
>value.

No.  One should expect the server to perform operations upon
attributes per their defined syntax.

Your suggestion cannot be implemented without redefining the
userPassword attribute type or violating the LDAP Information
Model.  userPassword is a "user" attribute.  As such, the
server cannot muck with the client provided values.

For further discussions on this issue (RFC 2307 abuse of
userPassword), see the archives of the OpenLDAP Software <http://www.openldap.org/lists/#archives> and IETF LDAPext WG
<ftp://ftp.innosoft.com/ietf-ldapext/> mailing lists.

OpenLDAP 2.0 will sport a new attribute type (authPassword)
specifically designed to store hashed user passwords and
will support server side password generation via an extended
operation (passwd-exop).  We are working with IETF to
standardize such mechanisms.

Kurt

At 12:21 AM 3/2/00 GMT, Michiel.Steltman@disway.nl wrote:
>Full_Name: Michiel Steltman
>Version: 1.2.8
>OS: Solaris 2.6
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (212.187.22.96)
>
>
>Change request:
>
>When a '{crypt}xxxx..' or '{sha}xxxx...' userpassword is modified with a
>cleartext value, that value is written un-encrypted into the attribute.
>One would expect the server to encrypt the new value instead, following a
>default scheme (as in slapd.conf) or using the encryption scheme of the old
>value.
>
>Regards,
>
>Michiel Steltman
>
>
>
>
>
>

Unimplementable request (conflicts with LDAP Information Model)