ppolicy pwdCheckModule failure and still calling other overlays

[Tim Watts <tw@dionic.net>]

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

--
Tim Watts
Personal Blog:                          http://squiddy.blog.dionic.net/

http://www.sensorly.com/ Crowd mapping of 2G/3G/4G mobile signal coverage