hi Michael,
many thanks for the help!
Michael Ströder michael@stroeder.com writes:
On 2/23/22 22:02, Felix Natter wrote:
ldappasswd(1) is the right tool for the command-line but takes a DN to specify the user's entry.
I tried this (which would be fine as a solution): ldappasswd -H ldap://<ip> -x -D \ cn=ldaptestuser1,ou=users,dc=company,dc=com -W -A -S but it does not enforce the pwdMinLength:3 restriction of the PP.
It works for me:
xkcd@ae-dir-suse-p1:~> ldappasswd uid=aacj,cn=test,ou=ae-dir -s 123 Result: Constraint violation (19) Additional info: Password fails quality checking policy
xkcd@ae-dir-suse-p1:~> ldappasswd uid=aacj,cn=test,ou=ae-dir -s Geheimer123456789
xkcd@ae-dir-suse-p1:~> ldapwhoami -x -D uid=aacj,cn=test,ou=ae-dir -w Geheimer123456789 dn:uid=aacj,cn=test,ou=ae-dir
Are you sure your pwdPolicy entry is applied, and e.g. has pwdCheckQuality: 2?
Indeed, I was setting this to 0 :-/ I assumed that since it has "quality" in the name, that it is only for the "pqchecker.so" invocatation!
Now it works, and I'm pretty sure I did not need any changes on the client(s).
For the record: - the passwords are still hashed on the server - it most probably works thanks to "olcPPolicyHashCleartext: TRUE" in the ppolicy overlay (OLC!) - encryption is mandatory
Again, Many Thanks and Best Regards! Felix