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 ?
Article ID: 127782
Updated On:
Products
CA Privileged Access Manager - Cloakware Password Authority (PA)
CA Privileged Access Manager (PAM)
Issue/Introduction
For a PAM managed account, the password change logic flow starts with PAM trying to log in to the target server with the new password. This is a step which should of course fail, and when it does so, PAM will indeed log in with the old password or through the account specified to change the password at the target server and change the old password to the new one. This behaviour may cause unexpected results in some situations.
In my system there is a generic account, pwmanager which carries the password change for the target accounts of the systems managed by PAM. I also have password rotation jobs in place which rather frequently change the passwords for these target accounts. As of lately I am observing situations where certain accounts are showing high counts of failed logins in the target system logs. Why is so and how can I mitigate it ?
In my system there is a generic account, pwmanager which carries the password change for the target accounts of the systems managed by PAM. I also have password rotation jobs in place which rather frequently change the passwords for these target accounts. As of lately I am observing situations where certain accounts are showing high counts of failed logins in the target system logs. Why is so and how can I mitigate it ?
Environment
CA PAM all versions
Resolution
The first step in the password change process involves logging in as the target account in the target system using the new password which we want to use, as indicated in the introduction.
This operation will cause the failed login count parameter to increase by one for the corresponding account.
The next step in the password change process, if the account is able to change its password, will be for it to log in into the system with the existing password and carry out the password change. This process will reset the failed login count to zero.
However, if the password change is being carried out by a generic account, the failed login count for the target account whose password is being changed will not be reset to zero as a result of the password change process, since in this second stage of the process it will not be itself, but the generic account that will be logging in to the target system. This will leave the failed login count to 1 at the end of the process.
If, following a password rotation job of this kind, someone logs in with the target account having had its password changed, the failed login count will be reset back to zero.
However, let's imagine now a situation when one target account stays unused over an extended period of time and the password rotation job has run several times: each run of the job will make the failed login count for that target account increase by 1. Many OS have a limit of failed login counts after which the OS effectively disables the account. After this it will be impossible to log in or to even change the password for that account until it is unblocked, and any attempt at changing its password or logging in will make the failed login count increase further.
If you are in this type of situation, an easy workaround is to run a password verification job for your target accounts on a regular basis: the verification process will log into the system with each account's existing password and it will therefore reset the failed login counts to zero for all accounts.
This operation will cause the failed login count parameter to increase by one for the corresponding account.
The next step in the password change process, if the account is able to change its password, will be for it to log in into the system with the existing password and carry out the password change. This process will reset the failed login count to zero.
However, if the password change is being carried out by a generic account, the failed login count for the target account whose password is being changed will not be reset to zero as a result of the password change process, since in this second stage of the process it will not be itself, but the generic account that will be logging in to the target system. This will leave the failed login count to 1 at the end of the process.
If, following a password rotation job of this kind, someone logs in with the target account having had its password changed, the failed login count will be reset back to zero.
However, let's imagine now a situation when one target account stays unused over an extended period of time and the password rotation job has run several times: each run of the job will make the failed login count for that target account increase by 1. Many OS have a limit of failed login counts after which the OS effectively disables the account. After this it will be impossible to log in or to even change the password for that account until it is unblocked, and any attempt at changing its password or logging in will make the failed login count increase further.
If you are in this type of situation, an easy workaround is to run a password verification job for your target accounts on a regular basis: the verification process will log into the system with each account's existing password and it will therefore reset the failed login counts to zero for all accounts.
Feedback
Yes
No
Powered by
