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