hi Michael, many thanks for the help!
Michael Ströder <mich...@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 -- Felix Natter
