This was only tested with our afs pam module in Red Hat Linux release 6.9.2 (Winston Beta 3) I installed 6.9.2 and did not use shadow or md5 encryption for passwords. Our afs pam module works in a way that we only add it to the auth component of pam right before pam_unix or pam_pwdb as sufficient. With pam_pwdb.so, pam would/will authenticate users through our afs pam module just fine. However, the pam_unix.so module now included in 6.9.2 will not authenticate users in the account component. It gives an error: Red Hat Linux release 6.9.2 (Winston Beta 3) Kernel 2.2.16-8 on an i586 login: ejburcka AFS Password: User account has expired Now, local users can still login fine...but the remote ones cannot. But, if I add a line like "ejburcka:!!:9281:0:99999:7:::" in /etc/shadow (which didn't even exist) I am authenticated just fine. This means that external users cannot login without either shadow passwords enable or a shadow password file with expiration information. This seems like a bug, but I apologize if it was intentional. It definitely acts different than pam_pwdb does. If I replace pam_unix.so with pam_pwdb.so in the account component, all works fine. Thanks for looking at this. -Erik
Run "getent passwd ejburcka". Does your user information have an "x" in the encrypted password field? This is a special character which specifically means "see the shadow file". If the pam_unix module sees this and can't read the user's information, you get an error from the account management function. If you're using Kerberos, this field is theoretically supposed to be "*K*" to signal that fact, though the pam_krb5 module (and I assume the pam_afs module also) does not enforce this.
Thanks for looking into that. This brings me to the question, why does this not work the same way for pam_pwdb? When I replace the pam_unix with pam_pwdb in system-auth, I get passed just fine. Is one of them doing the wrong thing or are they intentionally designed different? Thanks, Erik
You could say either that pam_pwdb was incorrect for not checking that, or that pam_unix is being unnecessarily paranoid. I actually can't decide whether pam_unix should or shouldn't be doing this check. On the one hand, it's different. On the other, it's probably correct. Is this in fact what is causing the behavior you're seeing?
Yes...recreated many times on a couple of machines. Either pwdb isn't *secure* enough or pam_unix is just more secure. But I can definitely get passed by one module(pwdb) where the other(unix) continually fails authorization. This is why I thought it was a bug somewhere...or intentionally made different? It seems to be a valid check...but not one I have seen before (and one that is going to cause me to edit a 1000+ line passwd file.)
How about this awk invocation? awk -F: 'BEGIN{OFS=":"}{$2="*K*" ; print}' /etc/passwd
no biggie...I actually did "sed s/:x:/:*K*:/g passwd "....gotta love regex....The problem I was thinking was more moving this out to all our machines...we seem to have a growing number of linux machines around here ;-) (thankfully) Whats your thoughts on this difference? Should we ask Cristian Gafton? Or is this something we can just drop and accept as just a difference? Thanks, Erik
Yes, please bounce this one off of Christian. I'm really not sure whether or not disabling this behavior is desirable.
The pam-0.72-24 package will add a "broken_shadow" option to the pam_unix account module which will force pam_unix to ignore errors reading user shadow information.
I have hit a similar issue syncing a passwd file set between a mixed RH 6.2 and 7.1 series .. this update did not resolve the issue at the 7.1 host ... testing