On 09/18/2009 08:10 AM, Kenneth Holter wrote:
I'm running Red Hat Directory Server 8.1.0, and are having some
problems with password syntax checking. When I don't enable the syntax
checking, everything works fine. But when I enable it it seems to
discard even pretty strong passwords. In the example belov I've
configured password syntax checking like this:
* Password minimum length: 8
* Minimum required character categories: 1
* Minimum token length: 3 (btw, don't know why I need to set this)
This is the token length to use for a "trivial words" check. This
prevents someone from using portions of their cn, uid, etc. values in
their password. The values are broken into tokens of this length and
the password is then checked to see if any of the tokens exist.
The new password I try to change to has two digits, four lower case
letters, one uppercase letter, and one special character. So it should
be far more complicated that the above settings call for. This is the
#### Output start
[root@server ~]# ssh kenneth@localhost
You are required to change your LDAP password immediately.
Last login: Fri Sep 18 16:37:26 2009 from localhost.localdomain
Welcome to the server!
WARNING: Your password has expired.
You must change your password now and login again!
Changing password for user kenneth.
Enter login(LDAP) password:
New UNIX password:
Retype new UNIX password:
LDAP password information update failed: Constraint violation
invalid password syntax - passwords with storage scheme are not allowed
passwd: Permission denied
Connection to localhost closed.
##### Output end
So basically what I'm wondering about is exactly which constraint I'm
violating. In other words, what does the "password with storage scheme
are not allowed" tell me?
Your password is being hashed by your client system
before it is sent to
the Directory Server. This is not allowed since the server would have
no way to enforce it's password policy against a pre-hashed password.
You need to configure /etc/ldap.conf to send the clear text password to
the LDAP server. You should use SSL/TLS to protect the password in transit.
389 users mailing list