I am currently trying to use
pam_cracklib which properly fails according to my debug.log but even though it is setup as a
password requisite entry in my PAM config file, it still falls through to the next
pam_unix module which allows for a password change. Why is it allowing for a password change?
I am executing a login driver application through
sudo, which is the only way I know how to authenticate.
Here is my PAM config file (named
auth required pam_env.so auth required pam_tally.so onerr=fail deny=3 auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account required pam_unix.so account required pam_tally.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.so password requisite pam_cracklib.so debug retry=3 minlen=14 lcredit=-1 ucredit=-1 dcredit=-1 ocredit=-1 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so
I invalidate my user password forcing them to change it:
# chage -d 0 <user>
when I run the custom application using
/var/log/debug.log produces the following.
pam_unix(validate:account): expired password for user mike (root enforced) pam_cracklib(validate:chauthtok): bad password: it is WAY too short pam_unix(validate:chauthtok): password changed for mike