One of PAM’s most effective protections is password rotation for the accounts in its vault, which significantly decreases adversaries’ ability to compromise the credentials of these accounts and use them for malicious access. However, this protection cannot be applied to high-privileged service accounts. The reason is that these accounts access their target workstations and servers via execution of a script that contains their credentials for login, as well as the task that they should execute.

There is no way to automatically update the password in the script to sync with the new one that the PAM’s rotation generates, and in many cases the location of the script itself is not known, so this update cannot be performed manually either. Thus, rotating the passwords of these accounts in the PAM will invalidate the one in the script, the service account won’t succeed in logging in, and the task will never be executed on the target machine. If there are other processes that depend on the execution of this task, they won’t run as well.

This potential chain reaction of breaking processes withholds identity teams from onboarding service accounts to the PAM vault, leaving them exposed to compromise.

Service accounts with unmapped dependencies

PAM Challenge #2: You Can’t Rotate if it’s Going to Break