[SOLVED] Server failing to allow password change

theillien · 01-17-2012, 06:27 PM

I have a customer that has about 12 RHEL 6 servers. We enforce password aging so every 60 days each user that logs in much update his or her password. On every server but one one user (possibly more but only one has reported teh issue) has been able to update his password. On the one server that isn't working, he is getting the "passwd: Authentication token manipulation error" message.

When I look through /var/log/secure I'm seeing the following:

Code:

Jan 17 13:53:30 tcrbisprr6sg02 passwd: pam_cracklib(passwd:chauthtok): pam_get_authtok_verify returned error: Failed preliminary check by password service
Jan 17 13:53:41 tcrbisprr6sg02 passwd: pam_unix(passwd:chauthtok): can't open /etc/security/opasswd file to check old passwords

I've verified that the file exists and it has permissions identical to those on another server that he was able to change his password on. I've also verified that the pam_cracklib.so settings are the same for the two servers:

Code:

password    requisite     pam_cracklib.so try_first_pass retry=3 minlen=8 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=3

This is also identical to every other server.

I asked if he was entering a password that meets the requirements. He responded that yes, he was and that it is the same password as the one he set on the other servers.

I've also tested the issue with a password I know to meet the requirements.

Is there anything else I can be looking at to troubleshoot this problem?

kbp · 01-17-2012, 10:04 PM

Is selinux in enforcing mode?

Code:

getenforce

.. if so then the opasswd file may be mislabeled

Code:

restorecon -v /etc/security/opasswd

.. you may also want to confirm that the /etc/security directory permissions have r.x for other

theillien · 01-17-2012, 10:06 PM

Hmm...good question. I didn't even bother to check because it shouldn't be running. I'll take a look in the AM.

Thanks for the suggestion.

theillien · 01-18-2012, 01:03 PM

SELINUX=disabled
SELINUXTYPE=targeted

The perms on the security directory of the offending server:

Code:

drwxr-xr-x.  6 root root   4096 Jan 17 19:09 security

which matches those of another, working server:

Code:

drwxr-xr-x.  6 root root   4096 Jan 17 14:22 security

It doesn't seem selinux is a factor in this. I have also received word that others are also having the problem, not just the person that reported the issue.

Linux_Kidd · 01-18-2012, 01:19 PM

please post contents of /etc/pam.d/system-auth

use a better pam module, disable cracklib.so and use passwdqc.so (just a suggestion).

Code:

#my settings for rhel5
password    requisite      pam_passwdqc.so min=disabled,disabled,12,8,8 random=0 passphrase=0 retry=3 similar=deny enforce=everyone ask_oldauthtok
password    sufficient    pam_unix.so sha512 shadow remember=12 try_first_pass use_authtok
password    required      pam_deny.so

my opasswd is chown root:root and chmod 600

Code:

-rw-------  1 root root   290 Dec 20 10:02 opasswd

please post ownership and perms for your ospasswd file

also, if you "man login.defs" you'll see this statement?

Code:

Much of the functionality that used to be provided by the shadow password suite is now handled by PAM.
       Thus, /etc/login.defs is no longer used by programs such as: login(1), passwd(1), su(1). Please refer to
       the corresponding PAM configuration files instead.

chrism01 · 01-19-2012, 07:41 PM

Indeed, double check ownerships & perms; note that Linux_Kidd's opasswd listing doesn't show any ACL marker; guessing it's not on RHEL6.

Linux_Kidd · 01-20-2012, 10:47 AM

Quote:

Originally Posted by chrism01

Indeed, double check ownerships & perms; note that Linux_Kidd's opasswd listing doesn't show any ACL marker; guessing it's not on RHEL6.

rhel5 VM selinux off.

theillien · 01-30-2012, 10:05 AM

/etc/security perms on working system:

Code:

[msnyder@<servername1> ~]$ ll /etc/ |grep security
drwxr-xr-x.  6 root root   4096 Jan 17 14:22 security

And on offending system:

Code:

[msnyder@<servername2> ~]$ ll /etc/ |grep security
drwxr-xr-x.  6 root root   4096 Jan 17 19:09 security

/etc/security/opasswd perms on working system:

Code:

[msnyder@<servername1> ~]$ ll /etc/security/ |grep opasswd
-rw-------  1 root root  387 Jan 17 14:22 opasswd

And on offending system:

Code:

[msnyder@<servername2> ~]$ ll /etc/security/ |grep opasswd
-rw-------  1 root root  104 Oct 27 12:47 opasswd

Contents of /etc/pam.d/system-auth:

Code:

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_tally2.so deny=5 onerr=fail unlock_time=300
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_tally2.so
account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3 minlen=8 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 difok=3
password    sufficient    pam_unix.so md5 shadow remember=24 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'll take your suggestion of a different authentication module into consideration. However, immediate needs sidestep that issue.

Linux_Kidd · 01-30-2012, 11:52 AM

well, maybe a corrupt opasswd file? can you more that file and it looks normal like your other opasswd files on the other system? maybe rename it with .orig.bak and then touch opasswd (making sure chmod and chown are correct, etc). sounds to me like the file is corrupt...?

does that pam setup look the same as working system?

theillien · 01-30-2012, 12:05 PM

Moved opasswd to opasswd.old.

Touched opasswd.

chmod'd opasswd to 600.

Ensured ownership of root.root.

Reset user's passwd and chage'd to -d 0.

Logged in as user and was prompted to change password.

Same outcome: passwd: Authentication token manipulation error.

Using a password known to meet our complexity requirements.

Linux_Kidd · 01-30-2012, 07:25 PM

hmmm, can you post (sanitize where needed, etc)
pam_tally2 -u [username]
passwd -S [username]

can you as root do a passwd [username]
then su over to that user (or login as that user) and then change passwd again?

is this login via console, telnet, ssh, other ??

theillien · 03-15-2012, 03:19 PM

Finally getting back to this:

/usr/sbin/passwd lost its SUID bit. Once I realized this I added it back and the problem went away.