I realise this is a long shot,
but if pwdCheckModule is enabled in ppolicy AND the module it calls FAILS a prospective password (for being too weak) - should slapd actually be calling the next overlay in the stack?? Common sense says ppolicy should bomb out?
Here are the overlay configs in slapd.conf:
<backend hdb database stuff>
overlay smbkrb5pwd smbkrb5pwd-enable krb5 smbkrb5pwd-krb5realm DIGHUM.KCL.AC.UK smbkrb5pwd-requiredclass posixAccount # # Password Policy - this runs check_password.so compiled from # /vol/source/ldap_check_password/1.0/check_password.c # # overlay ppolicy ppolicy_default "cn=default,ou=pwpolicies,dc=dighum,dc=kcl,dc=ac,dc=uk" ppolicy_use_lockout ppolicy_hash_cleartext
The idea is:
ppolicy is configured to call my own password_check.so and that works nicely - that exits with EXIT_FAILURE if it fails.
smbkrb5pwd is OpinSys.fi's modification to smbk5pwd to work with MIT kerberos. That works too (after I fixed something). It will set the principle's password and create the principle is it doesn't exist.
The failure scenario is:
1) No principle for the UID in question;
2) The UID in question has a DN in slapd;
3) Set password for UID - choose one that will fail the ppolicy checks;
4) do an ldappasswd change for UID
Result: ldappasswd says it fails and the user password hash in slapd is not changed. However, smbkrb5pwd was still called and managed to create a principle for UID with the weak password - bypassing the policy.
The best answer to my mind is:
Fix smbkrb5pwd to be able to add a default kerberos policy to any created principles. Such a policy can replace ppolicy for password strength checking. I think I can do this.
However, it bothers me - is there no way to make the failure of one overlay bomb the stack out (rather like PAM)?
Or perhaps ppolicy is not actually "failing" as such??
Any ideas?
Cheers!
Tim