Users cannot use crontab after password security upgrade

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?

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...

I had this issue too and it turned out that /etc/shadow did not have an entry for that user. Using pwck added the user and the problem was solved.