The service account passwords
nobody dares to change.
Every estate has them: the account the backup job uses, the LDAP bind, the database role in four config files. Rotating one means changing it at the source and everywhere it is consumed, in the same minute. ManageLM does both — through the agents already on your servers.
On this page
The part that isn't the password
Generating a strong password takes a line of code. That has never been the hard part. The hard part is that one service account password lives in six places at once — the account itself, a config file on three web servers, a connection pooler nobody remembers, a vault entry, a cron job — and they all have to change together or the service goes down.
Which is why, in most companies, these accounts are simply never rotated. The policy says every 90 days; the reality is a password set in 2019 by someone who has since left, written on a card in a drawer because changing it is a project.
ManageLM treats a credential as one object with a source and a set of consumers. You describe both once. From then on a rotation changes the account, delivers the new value everywhere it is used, restarts what needs restarting, and records what happened — on a schedule, without anyone reading the value.
What it rotates
Operating system accounts
Linux accounts — including LDAP, SSSD and NIS accounts the host resolves — and local Windows accounts. On a Windows domain controller the same credential rotates the domain account, with no bind account and no certificate involved.
Directories
LDAP and Active Directory accounts, through a connector reached by one of your agents. Standards-based directories take the RFC 3062 password-modify operation, so your own password policy — history, complexity, minimum age — keeps applying.
Databases
PostgreSQL roles, MySQL and MariaDB users, and MS SQL Server logins. The connection is made from an agent that can already see the server, so a database on a private network stays on a private network.
Microsoft Entra
Application client secrets and cloud-only user passwords, over Microsoft Graph. A new application secret is added before the old one is withdrawn, so nothing authenticating with it drops.
SSH keys
Machine-to-machine keypairs. ManageLM generates the pair, authorises the public half on the accounts the key may reach, and places the private half where the job that uses it will look — the account's own .ssh, written the way ssh-keygen would.
Whatever the account really is
An account is not always where the vendor assumed. A directory running on your own infrastructure, a database with no route from the internet, a domain controller in a branch office — the agent is already inside each of them, so the shape of your estate stops being an obstacle.
Where the new value goes
Changing the account is half the job. Each credential carries a list of targets — everywhere the value is consumed — and every rotation delivers to all of them before it is called a success:
| Target | What it does |
|---|---|
| File on a server | A file holding the value and nothing else, so a script can read it with $(cat …). You choose the owner, group and mode; it may live under /etc, and the agent keeps its contents out of the host's change history. |
| A value inside an existing config | Point a pattern at the password in a config your service already reads, and only that value is replaced — the rest of the file comes out byte for byte identical, keeping its own permissions. |
| A vault | HashiCorp Vault or OpenBao, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager, CyberArk Conjur, Doppler, 1Password Connect, Akeyless — each written the way that vault expects, so the secret reads back through the vendor's own tooling. |
| An authorized key | For SSH credentials: the accounts the key may reach. The entry is managed inside a ManageLM-owned block, leaving the keys your team put there alone. |
A file target can also name services to restart once the value has landed. A restart, not a reload — a process that opened its database connection at startup is still holding the old password, and re-reading its configuration will not change that.
Why the agents change this
Most rotation tools need a network path to everything they touch: a route to the domain controller, a firewall rule to the database, a bastion, a service account with rights broad enough to reach it all. That is why so many of these projects stall — the tool is fine, the network is the problem.
ManageLM does not need one. The agents are already installed, already connected outbound, already trusted on their own hosts. A directory write happens on a machine that can see the directory. A database password changes from a host that already talks to that database. A domain account is reset by the agent running on the domain controller itself.
Nothing new has to be exposed. No inbound port, no VPN for the rotation tool, no hypervisor or DC published to the internet. The same agents that report your inventory and monitor your services deliver the credentials — which also means every server you have already onboarded is already in scope.
Finding the accounts you forgot
The honest obstacle to a rotation policy is not the rotation. It is that nobody has a list of the service accounts, and building one by hand across a few hundred servers is a quarter of work.
Because the agents are intelligent, you can simply ask. From Claude — or any MCP client connected to ManageLM — questions like these are answered by the agents inspecting their own hosts:
- “Which accounts run services on our web servers, and which of them have passwords in config files?”
- “Find every host where the
svc_backupaccount appears in a cron job, a unit file or a connection string.” - “List the database roles our applications connect with, and which server each connects from.”
- “Which of these credentials has not been rotated in the last 90 days?”
The inventory that a rotation programme normally starts with becomes a conversation, and what it produces is directly actionable: each account it names can be turned into a managed credential with its targets attached.
What auditors ask for
Password and secret rotation appears in almost every framework a company is measured against — ISO 27001, SOC 2, PCI DSS, NIS2, DORA, and internal policy that predates all of them. The questions are consistently the same four, and each has a direct answer here:
| The requirement | How it is met |
|---|---|
| Credentials are changed on a defined interval | Each credential carries its own schedule in days. The sweep rotates what is due, retries what failed, and stops after a bounded number of attempts rather than burning a fresh password every cycle. |
| Rotation is evidenced | Every attempt is recorded — when it ran, what triggered it, how many targets took the value, and what failed if anything did. Never the value itself. |
| Nobody needs to know the secret | The value is generated, set and delivered without being displayed, exported or stored. There is no “reveal” button, because there is nothing to reveal — the plaintext lives only in memory, for as long as it takes to deliver it. |
| Access to the function is controlled | Credential management is its own permission, off by default, separate from the rest of the platform — and every change is written to the audit log with who made it. |
Rotation also stops being the annual scramble. Once a credential and its targets are described, the 90-day requirement is a number in a field, and the evidence for the audit is a page you already have.
When something goes wrong
A rotation that half-happens is worse than one that never ran, so the failure behaviour is deliberate rather than incidental:
It will not start if a host is unreachable. A password has no overlap window — changing the account while a consumer cannot be updated is exactly the outage everyone fears. If any host in the picture is offline, the rotation is postponed, not attempted.
Keys and app secrets overlap. Where two values can be valid at once — SSH keys, Entra application secrets — the new one is put in place, delivered, and only then is the old one withdrawn. Existing access keeps working at every step.
A partial delivery is reported, loudly. If the account changed but one target refused, the rotation is marked failed and says which one — because the difference between “done” and “done except the pooler” is an outage at 3am.
Recovery is a fresh value, not a rollback. ManageLM never knew the old password, and restoring it would not help. If some targets took the new value and others did not, only the ones that missed it are retried — the rest keep the value they have, and their services are not restarted a second time. If that does not settle it, the whole rotation is retried with a fresh value, automatically, up to a limit.
Pairs with SSH & Sudo Access. One maps who can reach your servers as a person; this one manages what your machines authenticate with. Between them, an account with a password nobody has changed since 2019 stops being something you find out about during an audit.
Rotate the account you have been avoiding.
Describe it once — the account, and everywhere it is used. ManageLM changes it on schedule from then on.