Is there any possibility the product cause account lockout on target Linux devices ?
Article ID: 189446
Updated On:
Products
Issue/Introduction
We experienced account lockout in a PAM managed Linux server.
Could PAM be the cause of the account lockout ?
Environment
PAM ANY version.
Possible example.
- OS security policy (Such as pam_tally2) is activated, which will force account lockout upon consectuive number of failed login.
- [Change Process] for PAM managed account password is set to another account. ("Use the following account to change password" method)
- The account is set to Verify its own password.
Cause
There is possibility that PAM is causing UNIX accounts to get locked.
For example, a daily password update job is defined in PAM update for the target account, while an actual logon with the account is not happening for a while.
When PAM updates the password, PAM makes a login attempt to the target device with new password first. This logic is valid for the case where an Admin manually updates the password, in which case most likely the new password is the correct one. A scheduled job makes the same call, but in this case the Verify first logic is bound to fail, because the new password is not set on the target server yet.
If the Change Process for the target account is set to another account, see screenshot in the Environment section in this document, that other account will log on to perform the password update and the failed login count for the managed target account will not be reset until a login with the target account outside of the scheduled job occurs. As long as the other account is able to set a new password successfully, PAM will regard the managed account as Verified without actually testing a logon of the account with the new password.
For details, please see the following knowledge article:
Why are some of my managed accounts showing hundreds of failed logins in the system ever since I am using PAM to rotate their passwords ?
https://knowledge.broadcom.com/external/article?articleId=127782
Resolution
Define Password Verify jobs for UNIX accounts that are configured to Verify their own password, but have it updated by another account. If possible, define them on the same days that the update jobs run. But make sure to run the Verify job AFTER the Update job. Also make sure that they are separated in time such that there is no overlap between any job that updates a given target account, and the job that verifies it.
If you don't run Update jobs daily, you can run the Verify jobs on other days. E.g. if you run a job every Saturday to update a set of target accounts, you can define a Verify job to run every Sunday.
Additional Information
This behavior is expected for Linux target accounts, however not expected for Windows target accounts. The Windows target connectors will follow up the password update with a logon attempt using the new password.
Feedback
