BeyondTrust Password Safe managed accounts won't rotate or check out

TL;DR — When a BeyondTrust Password Safe managed account will not rotate or check out, the most common causes are simple: the target host is unreachable on the expected management port, the managed account is disabled/locked/expired on the target, or the platform cannot complete the password change because policy complexity or dependency health blocks it. Start with a direct network test from the Password Safe side to the target, then verify the account state on the target, then review the exact failure text in the job/audit logs. Reading time: ~6 min

The scenario

It is 3:40 PM on a Tuesday and a deploy is waiting on a database credential checkout from BeyondTrust Password Safe. The request sits in a failed state, your app team says the managed account has worked for months, and the DBA is asking whether someone rotated the password manually. You try a forced rotation and that fails too. Now you need to prove whether the break is on the Password Safe side, the network path, or the target system before the maintenance window closes.

Symptoms

• Checkout request fails in the UI with messages shaped like:

Checkout failed
Unable to retrieve credentials for managed account.

• Forced rotation job fails with messages shaped like:

Password change failed
Access denied

Connection timed out

The user name or password is incorrect

Account is locked out

• Audit/job history shows repeated retries with no success, often clustered after a firewall change, password policy change, or manual admin action on the target.
• The target system logs one of these around the same time:

sshd[21451]: Failed password for svc_app from 10.20.30.40 port 53422 ssh2

pam_unix(passwd:chauthtok): password change failed: Authentication token manipulation error

Event ID 4625: An account failed to log on.
Status: 0xC000006A
Sub Status: 0xC0000234

Event ID 4740: A user account was locked out.

• Network tests from the Password Safe appliance/worker to the target fail or hang.
• Checkout succeeds for other accounts on the same platform, but one system or one account consistently fails.

Likely causes

Step-by-step diagnosis

1. Check basic reachability from the Password Safe side to the target.

nc -vz db01.internal.example.com 22

Typical failure shapes:

nc: connect to db01.internal.example.com port 22 (tcp) failed: Connection refused

nc: connect to db01.internal.example.com port 22 (tcp) failed: Operation timed out

If you get timeout/refused, this is your problem. Jump to Fixes → Network path to target blocked or wrong port/protocol.

1. Verify DNS resolution from the same network context.

nslookup db01.internal.example.com

Bad output shape:

** server can't find db01.internal.example.com: NXDOMAIN

Or it resolves to the wrong IP/subnet after a migration. If DNS is wrong or inconsistent, jump to Fixes → Password Safe dependency/service issue or worker cannot reach target/DNS.

1. Test the managed account directly against the target using the currently known credential if you have break-glass access, or ask the system owner to test locally.

ssh svc_app@db01.internal.example.com

Or on Windows target validation from an admin shell:

Test-NetConnection db01.internal.example.com -Port 5985

If SSH/WinRM logon fails with Permission denied, Account locked out, or equivalent security event IDs, jump to Fixes → Managed account on target is locked, disabled, expired, or password changed manually.

1. Trigger one forced rotation and immediately watch target-side auth logs.

sudo journalctl -f -u sshd

Or for Linux auth logs:

sudo tail -f /var/log/secure

Or Debian/Ubuntu:

sudo tail -f /var/log/auth.log

If you see complexity/history errors during the change attempt, this is your problem. Jump to Fixes → Target password policy rejects the generated password.

1. Check whether the account can change its own password or whether the required privilege path still exists.

sudo -l -U svc_app

If expected rights are missing, or the target was hardened and removed password-change capability, jump to Fixes → Account lacks rights to change its own password or required elevation path broke.

1. Check time sync and dependency health on the target and the Password Safe-side host/worker.

timedatectl status

Bad output shape:

System clock synchronized: no
NTP service: inactive

If auth depends on AD/LDAP/Kerberos and clocks are skewed, or DNS is flapping, jump to Fixes → Time skew / TLS / directory dependency issue affecting authentication.

1. If all of the above are clean, review the exact failure text in the Password Safe job/audit history and correlate the timestamp with target logs. The useful split is simple: no connection attempt seen on target means network/DNS/worker path; connection attempt seen but denied means account state/policy/rights.

Fixes

Network path to target blocked or wrong port/protocol

Open the management path from the Password Safe appliance/worker subnet to the target on the actual protocol/port used for password management.

For Linux targets over SSH:

nc -vz db01.internal.example.com 22

For Windows targets over WinRM:

Test-NetConnection db01.internal.example.com -Port 5985
Test-NetConnection db01.internal.example.com -Port 5986

If a firewall change caused the break, add an allow rule in your firewall/security group dashboard for source PasswordSafe-subnet to destination target-subnet on the needed port. If the service is listening on a nonstandard port, update the managed system configuration in BeyondTrust to match the real port.

Verify it worked:

nc -vz db01.internal.example.com 22

Expected:

Connection to db01.internal.example.com 22 port [tcp/ssh] succeeded!

Managed account on target is locked, disabled, expired, or password changed manually

On Linux, inspect and unlock/reset the account:

sudo passwd -S svc_app
sudo passwd -u svc_app
sudo chage -l svc_app

If the password was changed manually and Password Safe is out of sync, reset it to a known temporary value, update/reconcile the credential in Password Safe, then trigger a rotation.

On Windows, from an elevated PowerShell session:

Get-LocalUser -Name svc_app | Select-Object Name,Enabled,PasswordExpires
Unlock-ADAccount -Identity svc_app

If the account is domain-backed, also check lockout and expiry in AD.

⚠️ Resetting a service account password can break applications immediately. Confirm dependency owners and maintenance timing before changing it.

Verify it worked:

ssh svc_app@db01.internal.example.com

or confirm the next checkout/rotation succeeds without a lockout event.

Target password policy rejects the generated password

This usually appears after a policy hardening change on the target: longer minimum length, banned characters, password history, or a PAM module enforcing custom rules.

On Linux, reproduce locally as root to see the exact policy failure:

sudo passwd svc_app

Watch logs:

sudo tail -f /var/log/secure

Typical failure:

BAD PASSWORD: is too simple
pam_pwquality(passwd:chauthtok): BAD PASSWORD: The password fails the dictionary check

Adjust the password generation policy used for that managed account/system in BeyondTrust so it matches target requirements, then rerun rotation. If the target forbids specific special characters, remove them from the allowed set for that account policy rather than weakening global policy.

Verify it worked:

sudo passwd -S svc_app

Then run a forced rotation and confirm no BAD PASSWORD or history errors appear in target logs.

Password Safe dependency/service issue or worker cannot reach target/DNS

If DNS is wrong, fix the A/AAAA record in your provider dashboard or internal DNS zone, then flush caches on the relevant resolver/worker if needed.

Linux cache flush examples:

sudo resolvectl flush-caches
sudo systemctl restart systemd-resolved

Check resolution again:

getent hosts db01.internal.example.com

If the issue is a worker/service host that lost network access after patching or subnet changes, restore routing and verify outbound connectivity from that host to the target.

If you front internal APIs or proxies involved in management traffic, a redirect or TLS break can show up clearly with curl -I:

curl -I https://internal-proxy.example.com/

Misconfigured output shape:

HTTP/1.1 301 Moved Permanently
Location: http://internal-proxy.example.com/

That downgrade/redirect can break clients expecting HTTPS-only.

Verify it worked:

nslookup db01.internal.example.com
nc -vz db01.internal.example.com 22

Account lacks rights to change its own password or required elevation path broke

If the target uses self-service password change, verify the account can change its password. If it relies on an elevated helper path, verify that path still exists.

Linux checks:

sudo -l -U svc_app
grep -E 'pam_pwquality|pam_unix' /etc/pam.d/*

If a hardening change removed required sudoers entries or PAM behavior changed, restore the previous working rule with least privilege. Example sudoers edit via visudo if your process requires a helper command:

svc_app ALL=(root) NOPASSWD: /usr/bin/passwd svc_app

Only add the exact command required; do not grant broad shell access.

Verify it worked:

sudo -l -U svc_app

Then trigger one forced rotation and confirm the target logs show a successful password update.

Time skew / TLS / directory dependency issue affecting authentication

For domain-backed accounts, clock drift can break Kerberos/LDAP-backed authentication even when passwords are correct.

Linux:

timedatectl status
sudo systemctl restart systemd-timesyncd

Windows:

w32tm /query /status
w32tm /resync

If TLS trust to a directory or proxy changed, inspect certificate validity from the affected host:

openssl s_client -connect dc01.internal.example.com:636 -servername dc01.internal.example.com </dev/null | openssl x509 -noout -dates -subject -issuer

Fix NTP, renew the certificate, or restore the trusted CA chain on the affected host.

Verify it worked:

timedatectl status

Expected:

System clock synchronized: yes

Prevention

• Add a scheduled synthetic rotation test for one nonproduction managed account per platform and alert on failure. Store the exact failure text and target hostname in the alert payload.

# Example wrapper called by cron/CI that triggers a test workflow and pages on non-zero exit
./run-passwordsafe-synthetic-rotation.sh || curl -X POST https://alert-webhook.example.com/pam -d 'rotation synthetic failed'

• Monitor management ports from the Password Safe network segment, not from a random monitoring VM. A green check from the wrong subnet is noise.

nc -vz db01.internal.example.com 22
Test-NetConnection db01.internal.example.com -Port 5985

• Pin and document per-target password policy constraints. If one legacy system rejects % or enforces max length, encode that in the account-specific generation policy instead of relying on tribal knowledge.

{"target":"legacy-db01","minLength":20,"disallow":"%#","historyAware":true}

• Alert on target-side lockouts for managed accounts so you catch manual password changes or retry storms before checkout demand spikes.

# Linux example: watch auth log for the managed account
journalctl -u sshd -g 'svc_app' -f

• Put DNS and time-sync checks into post-change validation whenever subnets, firewalls, or directory services change.

nslookup db01.internal.example.com
getent hosts db01.internal.example.com
timedatectl status

• Keep a break-glass validation path: one documented admin on the target who can answer three questions fast during incidents — can the host be reached, is the account locked, and what exact auth log line appears during a forced rotation attempt.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.