If someone changed the password on endpoint then how to sync the password between CA PAM and endpoint?
Is there any way we can automate it? Like as soon as any user changes the password on the endpoint, CA PAM will identity it and verify the credentials by its own ?
For windows endpoints, we can have domain account to do it. May I please know the documentation link to implement it. And how to perform with Linux endpoint. There is no AD bridging in our infra. So, we cannot have one reconcile account to manage all the endpoints. Do we need to make the reconcile account for every endpoints?
Yes it is possible to reconcile accounts that have been changed locally.
You will need to setup the following:
You asked about Windows domain accounts. It doesn't matter which type of account you use, you will just need to have a matching account that has the permissions to change the password of the target account. For example a domain admin may or may not have permissions to change local account passwords (this will depend on the setup), but a local admin should be able to change them if the domain admin is not.
Scheduled Jobs Documentation:
Schedule Target Account Activities - CA Privileged Access Manager - 3.0.2 - CA Technologies Documentation
Hope this helps, please let me know if you have any further questions about this.
CA Technologies - North America
Thanks Christian for the detailed explanation. I shall try on QA.
Just some more queries. So, do you mean that I have to have one reconcile account for every endpoint, which is (obviously) capable of changing the password.
I do have to check if domain admin has permission to change the password of local admin accounts on windows endpoints. If yes, then our task would be easier for Windows endpoints. But for Linux endpoints, do I need to have separate accounts for each endpoint?
Also, please let me know when does the automatic verification of accounts happens? Like, I have the password view policy set, and just for testing, I have set the policy to change the password on view. And password change is happening fine. Now, when I check the account in PAM, I can see that it is not verified. When I manually verify it, it got verified.
Q: So, do you mean that I have to have one reconcile account for every endpoint, which is (obviously) capable of changing the password.
A: The best way to put this is that you would need one reconcile account for every "authentication source". Sources like AD would only need one account to use across all connected endpoints, while sources like local authentication on Linux would require one account per endpoint since they are not linked.
Q: But for Linux endpoints, do I need to have separate accounts for each endpoint?
A: In general for Linux endpoints you would likely need an individual account for each endpoint. It is possible however that if you use other software, like CA Unix Authentication Broker, that your Linux servers could be set up to use a centralized authentication method in which case you could use a shared admin.
Q: Also, please let me know when does the automatic verification of accounts happens?
A: There are a few times when the account status may be verified:
Statement: I have set the policy to change the password on view. And password change is happening fine. Now, when I check the account in PAM, I can see that it is not verified. When I manually verify it, it got verified.
Response: The account should have been verified when the password was changed. You could look into what happened yourself by increasing the Tomcat log level to 'config', reproducing this issue and then viewing the recent entries in the Tomcat log. This should explain what happened during the credential rotation & will show errors if there were any. If you keep seeing this and are unable to figure out what is going on on your own, I would suggest opening a support case to have this looked into.
Just to elaborate a bit on the last part: The UNIX target connector has a script processor that connects to a target device and runs a script, which basically is a sequence of commands and processes responses, to perform either password verification or update. There are two default scripts, one for password verification, and one for password update. When you see an account unverified after a password update, but it later verifies ok, then in all likelihood the attempt to update the password failed. Because it didn't change, and PAM didn't update its own password store, a subsequent verification will work. As Christian stated, the tomcat (catalina.out) log at level INFO or CONFIG most likely will show where the problem is. At those log levels you will see the commands that the script processor tries to execute, and the response to the commands from the server. In many cases such problems are caused by an incorrect target account configuration, specifically the "Privilege Elevation” setting. E.g. a root account will not need to provide its current password when running the "passwd” command, but a non-root user does. This is controlled by the "This account is a root account” flag in the target account configuration. It has to be right for the password update to work. As Christian said, if you can't resolve the problem using these settings after review of the tomcat logs, please open a support case.
Hi Nikunj. The expectation is that once an account is vaulted in PAM that the passwords will be changed only by PAM. You may want to change those accounts so that those users no longer have the ability to change the passwords, which would cause PAM to become out of sync with that server. In this case, you would need to implement a controlling account as Christian suggests. The use of a controlling account to change the passwords of other accounts has another advantage. The number of accounts needing the intervention to which you refer is reduced, as the controlling account does not need to know the current password. As long as the controlling account itself remains in sync you will be able to put the controlled accounts back in sync if someone changed the password on the target server itself.
The short answer is that you will need at least one controlling account for each Target Server for which you wish to vault passwords. This method of configuring vaulted accounts is recommended, as it simplifies your ability to keep all your accounts in sync.
Yes, that is what I wanted to confirm that account must be present on the endpoint.
Thanks all for you detailed explanation.