how to reset passwords for shared service accounts safely
Rotates passwords on shared service accounts without breaking the services that use them. Covers inventory, coordinated rotation, and vault storage. Use when a shared service password must change (leak, staff departure, schedule). Not for human user passwords.
TL;DR
Inventory everywhere the password is used before touching it, generate the new password in the vault, update every consumer in a maintenance window, then rotate. Never change a shared service password without the full consumer list; the outage comes from the copy you forgot.
The error
(Scheduled rotation or suspected compromise of a shared service account password.)Steps
- Find every consumer: check the vault entry's usage notes, search config repos for the username, and ask the owning team. Expected: a complete consumer list. Assume the list is incomplete until verified.
- Schedule a maintenance window and notify the service owners. Expected: window agreed. Rotations go wrong; do them when someone can watch.
- Generate the new password in the privileged vault (32+ random characters). Expected: new value stored, old value retained in history.
- Update consumers one by one: app configs, scheduled tasks, services, scripts. Restart or reload each. Expected: each consumer authenticates with the new password.
- Verify the service works end to end, then mark the old password as rotated in the vault. Expected: no lingering use of the old value. Monitor logs for auth failures for 24 hours.
When to use
- Scheduled password rotation for service accounts
- Staff departure or suspected credential leak
When not to use
- Human user passwords (different flow)
- gMSA or managed identities (no human-known password to rotate)
Compatibility
- Any AD or local service account; privileged vault (CyberArk, HashiCorp Vault, 1Password)
Variants
Unknown consumers
Rotate in a lab first, or set the new password alongside the old temporarily if the system allows dual credentials.
Vendor-managed service
Coordinate with the vendor; some require their own rotation procedure.
Why it happens
Shared service passwords are copied into configs, scripts, and runbooks. Rotation breaks every copy at once, so the work is inventory, not the password change itself.
Edge cases
- Hardcoded passwords in compiled apps: may require a redeploy, not just a config change.
- Move to gMSA or managed identities afterward to eliminate the next rotation.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_TFcjF9CJl03xaXqZG02xIw
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.