Automatic Password Rotation fails
Article ID: 6404
Updated On:
Products
Issue/Introduction
In some appliances where several unix servers have their root password managed and there is password rotation, some fail verification randomly. Nevertheless, even if password rotation fails, it is still possible to access those machines.
Environment
PAM 2.x
PAM 3.x
Cause
When PAM sends the passwd command to the server being managed, it responds with 2 lines:
passwd: Changing password for root
New Password:
In most unix servers, the password change involves sending first the current password, then then new password, twice. In this case the first line received should match the Password Entry Prompt instead of the Password Change Prompt.
So, while PAM thinks the target server is asking it to send the new password, in reality the first entry received is informative and the first time the new password is sent should be next, whereas PAM thinks it is sending the confirmation password. This leaves the target server waiting for the confirmation password, which never arrives and the process fails.
Resolution
Go to the target application/Script Processor:
1) Modify the Target Application Script processor:
Modify the Password Change Prompt to: "(?si).*? new password:*?" or
Modify the Password Confirmation Prompt to: “(?si)(.*?re.*password.*:.*)”
Confirm by login externally to the device what is the Password Entry Prompt prefix and modify it to:
“(?si)(.*?password.*:.*?)”.
If you don't modify the Password Entry Prompt, you may still have issues.
AND/OR
2) Update the script processor timeout from the default value (5 seconds) to a higher value (actual value to be determined)
Additional Information
Analyze the information within the Catalina log, which will provide information on the server change password.
To obtain more information in Tomcat, go to Config > Diagnostic
Set Tomcat log level to INFO or FINEST , reproduce the issue and download the Tomcat logs.
Set back the log level to the previous level.
Feedback
