Whenever a relatively recently added user attempts passwd he receives the error:
"passwd: Authentication token manipulation error" when he enters his current password. Root and longer term users can change passwords without any problems.

So far I've recreated the password shadow file and made sure passwd had the correct suid

System-auth-ac content:
#%PAM-1.0

auth required pam_env.so
auth required pam_tally2.so deny=3 onerr=fail unlock_time900
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 broken_shadow
account required pam_tally2.so
account sufficient pam_succeed_if.so uid < 500 quiet
account required pam_permit.so

password requisite pam_cracklib.so pam_passwdqc.so min=8,8,8,7,6 enforce=users passphase=0 similar=permit retry=3
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


Extract from /var/log/secure:
Jun 30 xx:xx:xx head passwd: pam_unix(passwd:chuathtok): authentication failure; logname=pxxxxxxx uid=508 euid=0 tty=pts/2 ruser= rhost= user=pxxxxxxx
Jun 30 xx:xx:xx head passwd: pam_cracklib(passwd:chauthtok): pam_parse: unknown option; pam_passwdqc.so
Jun 30 xx:xx:xx head passwd: pam_cracklib(passwd:chauthtok): pam_parse: unknown option; min=8,8,8,7,6
Jun 30 xx:xx:xx head passwd: pam_cracklib(passwd:chauthtok): pam_parse: unknown option; enforce=users
Jun 30 xx:xx:xx head passwd: pam_cracklib(passwd:chauthtok): pam_parse: unknown option; passphase=0
Jun 30 xx:xx:xx head passwd: pam_cracklib(passwd:chauthtok): pam_parse: unknown option; similar=permit

There are problems with the 2 bolded lines.

For the pam_tally2.so line, it should be "unlock_time=900". So, add the missing '=' there.

For the other line, someone stuck pam_cracklib.so before pam_passwdqc.so. So, everything after pam_cracklib.so is treated as an option for it, but nothing on the remainder of that line is a valid cracklib option. Remove the pam_cracklib.so, and you are left with the pam_passwdqc.so configuration, and those options look ok for that module.

Thanks sgrlscz, that appears to have resolved the passwd problems I was having.

I initiated the changes as suggested by sgrlscz but I then had some users complaining that they couldn't login and I found they were getting account lockouts after 3 failures. Is it correct to assume that their existing passwords don't meet minimum password requirements defined in the pam_passwdqc module? Is there a way I can "grandfather" in their existing passwords and/or allow them to login but force them to change upon login? Thanks.

The password settings only affect when they change passwords. It has nothing to do with the lockouts.

They are getting locked out after 3 failures because that's what you are doing with the pam_tally2 line at the top. The "deny=3" says to lock the account after 3 failed attempts (the unlock_time says to unlock the account 900 seconds later).

Thanks for the reply sgrlscz. Yes, I figured that and sorry I wasn't specific but the users are getting locked out after I make the change. At that point when they login and type their known/existing passwords the system doesn't recognize those passwords and of course after three attempts they get locked out. I thought that the pam_passwdqc module was for setting password policies but when I configure the line in question to use the pam_cracklib module instead users are able to login with their existing passwords and use passwd command without error.