PAM rejected by account configuration[10]:

[Jeff Lightner_1]

Today we converted our remaining HP-UX 11.x servers to trusted so we can use password aging etc...

This had no problems I couldn't address on any of my other 11.11 or 11.0 servers until the last one (an 11.0 server). On that one I did the conversion and it said it was successful. However on attempting to open a new window to verify all was OK it gave me access denied for root.

From the root window I still had open I changed the password then changed it back to the original and got it working. Later another user had the same issue. On attempting to change the password to the one they gave me it said it already had that password so I again changed it to a new one then changed it back.

The messages I see in syslog are:
Jul 12 11:31:21 rback sshd[25600]: PAM rejected by account configuration[10]: Ge
t new authentication token
Jul 12 11:31:21 rback sshd[25600]: Failed password for root from 10.80.6.17 port
1380 ssh2

For the other user:
Jul 12 11:41:55 rback sshd[26979]: PAM rejected by account configuration[10]: Ge
t new authentication token
Jul 12 11:41:55 rback sshd[26979]: Failed password for sagent from 10.40.6.83 po
rt 1728 ssh2

On doing a Google I see a similar issue on a Solaris forum that talks about IIRC and 3.3 but doesn't give any real detail.

Anyone have any ideas what would cause this? Is there a way I can proactively enable the accounts without knowing the individual passwords?

[Pete Randall · Accepted solution]

Jeff,

How did you convert? Did you use SAM or command line. If command line, all the passwords get expired until modprpw -v is run. See this thread, particularly the last few answers:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=976830


Pete

[Jeff Lightner_1]

Thanks. Happened to have a user with the issue just as you posted so was able to test the modprpw -v against that user and it resolved the issue.

Ran a script to do all users:

for USER in `awk -F: '{print $1}' /etc/passwd`
do echo Updating $USER
/usr/lbin/modprpw -v $USER
sleep 1
done

Hopefully that will prevent more calls. Oddly enough I did find at least one user that did NOT experience the problem. In answer to your question I did the convert via SAM. As mentioned I had done this on other servers including another 11.0 without issue. Perhaps there is a difference in patching that made SAM act like the command line on this particular server.

I had looked at the /tcb/files/auth/*/* files for the users in questions but didn't see any information indicating they were locked.

[Jeff Lightner_1]

Figured out what was different. On my other servers I'd run a script that was disabling the timeouts for existing users and neglected to run that on this server.

The script by the way is being run because we are turning on aging etc... for NEW users so we can implement individual accounts with sudo access to global accounts. We don't want to do aging on existing accounts until we're done at which point will set the global accounts to something like "*" so that users can't login directly to those accounts.

[Jeff Lightner_1]

Closing