Password Safe Credential Rotation: — Policies, Propagation Actions & SSH Keys

① Password policies — length, complexity & the four rotation triggers

Every rotation starts with a question: what should the new secret look like? The answer is a password policy. You build one at Configuration > Privileged Access Management Policies > Password Policies > Create New Password Policy. The form gives you Minimum Length and Maximum Length (anywhere from 4 to 255 characters), four character classes — Uppercase, Lowercase, Numeric and Non-Alphanumeric — each with a permit/deny toggle and a minimum count, plus a First Character Value dropdown and an Allow use for Secrets Safe checkbox.

Here is the part the form will not warn you about: the policy must respect the platform. Old Cisco gear truncates long passwords, some databases choke on certain symbols, and several platforms reject a special character in the first position — that is exactly what First Character Value exists for. Meera at Infosys learned this when her 32-character everything-policy met a network device that silently truncated at 25: the device stored the first 25 characters, the vault stored all 32, and every login after that rotation failed. One policy per platform family is the grown-up pattern.

Now, when does a change fire? Four triggers, four different screens. (1) Scheduled: with Enable Automatic Password Management on, the account rotates at its ChangeTime — default 23:30 UTC — at a frequency of first (first day of month), last (last day) or xdays (every X days). (2) On release: Change Password After Release re-keys the secret the moment a checkout is returned — anything a human saw is treated as burned. (3) Manual / API: an on-demand change from the Managed Accounts grid, or POST ManagedAccounts/{id}/Credentials/Change from a script. (4) Mismatch reset: Reset Password on Mismatch — with the giant caveat that mismatch is only detected when a password test runs. All four land in the same place: the Password Change Agent queue.

The four triggers — tap to lock them in

Each card front is the trigger; the back is where it lives and the gotcha.

POST https://bi.icicilab.in/BeyondTrust/api/public/v3/ManagedAccounts/482/Credentials/Change
Authorization: PS-Auth key=PS_API_KEY_128CHARS; runas=icici\rahul.verma;
Content-Type: application/json

{ "Queue": true }

HTTP/1.1 204 No Content
→ change queued for the Password Change Agent
→ Managed Accounts grid: Last Change Date updates once the agent completes
→ a failed attempt lands in the retry queue (see ②)

② Anatomy of one rotation — connect, change, verify, commit

One rotation is four moves. Generate: the vault builds a candidate secret from the password policy — held in memory, not yet committed. Connect: the functional account signs in to the target — think of the society watchman who holds the master key used to change every flat’s lock, but never lives in any flat. Change + verify: the new secret is set on the target, then Password Safe authenticates with it to prove the target really took it. Commit: only now does the vault store the new secret and stamp the account’s Last Change Date.

That commit-after-verify ordering is the design decision worth repeating in interviews: a failed rotation cannot strand you. If the change or verify step fails, the vault keeps the last known-good secret and the job sits in the Password Change Agent’s retry queue — tuned at Configuration > Privileged Access Management Agents > Password Change Agent via Retry failed changes after (minutes), Maximum retries, and Unlimited Retries. The flip side: with Unlimited Retries, a misconfigured account fails forever, silently. The failed queue is a dashboard you must watch, not a bin you ignore.

$h = @{ Authorization = 'PS-Auth key=PS_API_KEY_128CHARS; runas=icici\svc_psapi; pwd=[S3cure#Pass];' }
$base = 'https://bi.icicilab.in/BeyondTrust/api/public/v3'
Invoke-RestMethod "$base/Auth/SignAppin" -Method Post -Headers $h -SessionVariable ps
Invoke-RestMethod "$base/ManagedAccounts/482/Credentials/Test" -Method Post -WebSession $ps

UserName : svc_psapi          ← SignAppIn 200, session held in $ps
Success
-------
   True                       ← vault password matches the target
(False = mismatch — run the triage ladder in Fig 5)

Last piece: drift detection. Check Password plus the Password Test Agent periodically prove the vaulted secret still works. When a test fails and Reset Password on Mismatch is on, Password Safe re-asserts control by rotating. But understand the timing: like the milkman who only discovers the gate lock changed on his next delivery, mismatch is found at the next test, not at the moment of drift. A real community thread exists precisely because an admin expected reset-on-mismatch to be real-time. It is not.

③ Propagation actions — the 2 AM breakage insurance

A human checks a password out of the vault. A service account’s password is different: it is burned into places that never ask the vault — a Windows service’s Log On As entry, a scheduled task’s stored credential, an IIS application pool identity, a COM+ application. Rotate the account and every one of those copies is instantly wrong. They do not fail at 23:30 when you rotate; they fail at the next restart, recycle or task run — which is why this class of outage so reliably detonates at 2 AM, when nightly jobs wake up.

The Indian-household version: you changed your flat’s main-door lock but forgot that the maid, the milkman and your neighbour all hold duplicate keys. Tomorrow morning, three people rattle the door with dead keys. On Windows the rattling is worse than annoyance: each dependent retries its old password, the domain controller counts every failure, and at the lockout threshold AD locks the account — at which point even the NEW, correct password stops working. The rotation did not break production; the forgotten copies did, and then the lockout took out everything including the vault’s own secret.

Password Safe ships nine built-in propagation actions: Update Services, Update and Restart Services, Update Scheduled Tasks, Update IIS Application Pools, Update and Restart IIS Application Pools, Update Windows Auto Logon, Update COM+ Applications, Update DCOM Applications and Update SCOM RunAs Identities. You attach them per managed account: open the account’s Advanced Details > Propagation Actions pane and click Assign Propagation Action, choosing both the action and a Propagation Set — Latest Discovery Data (every system where discovery found this account in use) or a Managed System-Based Smart Rule. The action then runs on each system in the set after every successful rotation. Plumbing requirements: the functional account needs ADMIN$ share access, targets need .NET Framework 4.7.2+, and the network path must allow TCP 445 and UDP 137/138/139.

When the dependent is not one of the nine built-ins — say your app reads a password from a config file — build a custom action at Configuration > Privileged Access Management > Propagation Actions > + Create Propagation Action. You choose a script type (PowerShell, Windows Command or Unix Shell), give the full script path, and pass parameters with substitution variables: %u account name, %p password, %h host, %i IP, %j system name, %k system IP. One sharp edge from the docs: %p must be enclosed in quotes when passed on a command line — generated passwords contain characters your shell will happily mangle.

# Script type : Unix Shell
# Full path   : /opt/bt/update-app-conf.sh
# Parameters  : %u "%p" %h        ← %p MUST be quoted

#!/bin/sh
# $1=account  $2=new password  $3=host
sed -i "s|^db_pass=.*|db_pass=$2|" /etc/payapp/app.conf
systemctl restart payapp
echo "payapp.conf updated for $1 on $3"

payapp.conf updated for svc_pay on 192.168.40.17
● payapp.service — active (running) since 23:31:42 UTC
exit 0 → propagation recorded as success against the rotation

④ SSH keys, DSS rotation & monitoring rotation health

On Linux estates, the privileged credential is often not a password at all — it is an SSH key. Password Safe’s docs and API still call this DSS authentication, and the policy engine lives at Configuration > Privileged Access Management Policies > SSH Key Policies. A policy sets the Key Type (RSA or DSA), the bit size (default 2048), and optionally Encryption Enabled — which protects the private key with a passphrase generated from a password policy you pick. The built-in default policy is RSA 2048 with an auto-managed passphrase. Supported platforms: Linux, AIX, HP-iLO, HP-UX, DRAC, macOS, Solaris, Juniper and RACF; uploads are accepted in OpenSSH format including Ed25519 — though policy-driven generation offers RSA/DSA, so pick RSA and skip DSA (modern OpenSSH disables it).

Rotation mechanics differ from passwords in one beautiful way. Enable Auto-Managed SSH Key on the account and key rotation rides the same schedule as password changing — same ChangeTime, same triggers. At rotation, Password Safe generates a fresh keypair, and on the target it removes the old public key from authorized_keys and appends the new one. Think of the bank updating your signature card in their register: the new signature goes in, the old one is struck off, and yesterday’s forged copy is worthless. The private key plus passphrase live only in the vault — nothing secret sits on the target. And for redundancy, the account can fail over to a managed password if key auth ever breaks.

sudo grep -c '^ssh-rsa' /home/svc_deploy/.ssh/authorized_keys
sudo tail -1 /home/svc_deploy/.ssh/authorized_keys | cut -c1-44
ssh -i ~/old_svc_deploy_key svc_deploy@192.168.40.17 hostname

1                                  ← exactly one managed key: old entry removed
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDk9w2q
svc_deploy@192.168.40.17: Permission denied (publickey).
                                   ↑ the captured/old key is now worthless

Now zoom out: rotation is a machine, and machines need gauges. Three you should watch weekly. (1) The failed-change queue: the Password Change Agent retries on its schedule, but with Unlimited Retries a broken account fails forever without a human ever noticing — review failures in the console and get them into your SIEM or ticket queue. (2) Password age: the Managed Accounts grid shows Last Change Date; accounts whose age exceeds their frequency are stuck — that is your earliest signal of a dead functional account or a directory problem. (3) Test results: scheduled Password Test Agent runs catching mismatches tell you about out-of-band changes before a 2 AM incident does. BeyondInsight’s Analytics & Reporting menu carries the account activity reporting you will hang these reviews on.