Michael Ströder wrote:
Howard Chu wrote:
The text also states The practice of storing hashed passwords in userPassword violates Standard Track (RFC 4519) schema specifications and may hinder interoperability.
In practice we all live very well with this for years. That's least of a problem today.
Anyone building operational procedures on something that violates the specs was asking for trouble. Users should be using ldappasswd, that's what it's for.
ldappasswd writes a hashed password to - tataa - attribute 'userPassword'. I cannot see how this is different from using ldapadd/ldapmodify.
Wrong, ldappasswd sends a PasswordModify exop to a server. The server may implement that exop in any implementation-specific manner, and there is no guarantee that the password a server uses is ever instantiated in any LDAP entry. There is no guarantee that setting a userPassword attribute using ldapadd/ldapmodify will ever do anything useful for any given LDAP user.