Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a box being upgraded from CentOS 5 to CentOS 6. On the original server, all users have MD5 passwords. The upgraded server is now using SHA-512 passwords.

Users who have changed their password and have a SHA-512 password in /etc/shadow since the upgrade are able to use crontab successfully, but users who have not changed their password and still have an old MD5 password cannot use crontab. The error message they receive is:

Authentication service cannot retrieve authentication info
You (_username_) are not allowed to access to (crontab) because of pam configuration.

I've looked at /etc/pam.d/system-auth (you can too) but I'm not exactly sure what to tweak to permit access to crontab for users who have not yet changed their passwords.

I'm well aware that I can force everyone to change their passwords with chage -d 0, and users who change their password will regain access to crontab (and whatever else might be broken) but I have a few users where I need to edit their crontab before their next login, and using crontab -e -u _username_ as root also fails with exactly the same error as above.

Strangely, this issue didn't show up on my dev box; I've run into this on the staging box just prior to deployment. Users on the dev box with old MD5 passwords can access crontab just fine, and the /etc/pam.d/system-auth is identical. The dev and staging boxes are supposed to be identical, aside from their IP addresses. I suspect I've missed something really obvious and stupid...

So my question is, how can I enable access to crontab for users who haven't yet changed their passwords and been SHA-512 hashed? Or, how can I work around this issue?

share|improve this question
add comment

1 Answer

up vote 7 down vote accepted

I managed to fix this moments after posting the question.

It turns out that the /etc/shadow entries for the affected MD5 password users had somehow had the field after the hashed password duplicated, causing PAM to be unable to interpret the line. In other words, a bad cut and paste job.

I haven't had enough coffee...

share|improve this answer
    
There's a tool called vipw that should prevent this kind of mistake. vipw -s edits the shadow file. –  Ladadadada Jul 17 '12 at 6:15
    
Unfortunately vipw (which I was using) doesn't prevent my wireless mouse from going nuts due to interference, low battery, or whatever was causing it to misbehave... –  Michael Hampton Jul 20 '12 at 5:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.