Service Account Password Rotation

Why the one credential that should rotate most, rotates least

A service account is the identity an application uses to authenticate — to the directory, to a database, to another service. It has no person behind it, no phone, and nobody to notice when something is wrong. It often holds broad rights, because narrowing them once meant risking an integration. And its password is frequently the oldest secret in the environment.

That is the reverse of what you would want, and it happens for a reason that has nothing to do with laziness.

The same password is in more than one place. It was typed into the application’s configuration at install. Then into a second server when the service scaled out. Then into a scheduled task, a connection string, a backup job, a monitoring check. Nobody kept the list.

Rotating it means changing every copy at once. Miss one and that service fails — maybe immediately, maybe at 2am when the batch job runs. So rotation becomes a coordinated outage with a rollback plan, scheduled for a quiet weekend that keeps getting quieter.

A person’s password expires. A service account’s password is a decision nobody wants to be responsible for making twice.

Microsoft’s group managed service accounts solve exactly this where they fit — the directory rotates the password itself. But they only cover applications that can use them, which leaves the appliance, the third-party product, the in-house system and the cross-domain integration on a password entered at install and untouched since.

You cannot rotate what nobody has listed

Rotation projects usually start in the wrong place: with a list somebody wrote from memory.

Worth knowing why that list is always incomplete. Active Directory has no attribute that marks an account as a service account. It isn’t an object type — it’s a usage pattern. Managed service accounts are the exception and can be identified directly; everything else has to be recognised by the shape it leaves in the directory.

Mirket looks for that shape: accounts that carry a service principal name, that have delegation configured, whose password has not changed in years, whose expiry was switched off, that sit where service accounts are kept — set against the signals that mark a human, like a manager, a mailbox or an HR identifier.

• What comes back is a list to review Not a verdict. Each candidate arrives with the reasons it was flagged, so the person reviewing decides from the evidence rather than from a score. Miscategorising a person's account costs more than the automation saves.
• Where an account is used, when it can be told A service principal name says which service is offered on which machine, so some accounts can be tied to the servers they serve. Where that link can't be established, the result says so rather than guessing.

Some things stay out of reach of a directory-based look: credentials embedded in configuration files, accounts local to individual servers, and the databases that keep their own. Those are found by other means and are worth scoping separately — but the directory-side list is where most estates find more than they expected.

Rotation, and the honest edge of it

Once an account is under management, its password changes on a schedule you set per account — an interval and a time — rather than when somebody is brave enough to run it.

• Rotate without touching the application Where the application authenticates through Mirket's LDAP Proxy, the real password lives behind the proxy rather than in a configuration file. It can change without the application seeing anything change.
• Rotate and scope together A rotated credential that can still read the whole directory is a smaller problem, not a solved one. The same account can be limited to the source it should bind from and the branch it should read.
• The awkward ones, through your own agent Not every system takes a password change the same way. Mirket exposes an API you can build a small agent against, in PowerShell, Python or whatever the team already writes. It collects the credential and the context it needs from the platform and applies the change on the target — so an unusual system becomes a short piece of code rather than a product request.
• Scheduled, not remembered Rotation running on its own is the difference between a policy and an intention. Nobody has to learn the new password, because nobody was holding the old one.

It is worth being straight about coverage. No directory-based approach finds every machine identity in an estate, and not every system can have its password changed the same way. What the platform aims at is the large, reachable middle — the accounts the directory knows about — and an API to extend past it where your environment needs something specific.

Why the password stays frozen

Find the ones that have never rotated

One read-only query, from data your directory already holds. An account with a service principal name is authenticating as a service, and PasswordLastSet is the day someone last touched its secret.

Get-ADUser -Filter {ServicePrincipalName -like '*' -and Enabled -eq $true} `
  -Properties ServicePrincipalName, PasswordLastSet, PasswordNeverExpires, LastLogonDate |
  Sort-Object PasswordLastSet |
  Select-Object SamAccountName, PasswordLastSet, PasswordNeverExpires, LastLogonDate

Read the top of that list against today’s date. Where PasswordNeverExpires is set, somebody turned expiry off deliberately — because letting the password lapse would have taken the service down with it.

The number that ends the debate. Take the oldest PasswordLastSet on a privileged service account and count the years. That is how long one leaked configuration file, backup or memory dump has been enough to authenticate as that account.

This query only sees accounts with a service principal name, which is a useful start rather than the whole population — the point of discovery is everything this misses.

Where this sits next to the rest

Rotation answers how old is the secret. It sits alongside two neighbours, and they are not the same question.

LDAP Service Account Security changes what the application is holding in the first place — a virtual credential with no directory account behind it — so that a captured configuration file yields nothing reusable. That is the trust-model answer; rotation is the hygiene one, and they work best together.

Privileged Password Vaulting covers the accounts a person uses, where the question is who has seen the password rather than how long it has been the same.

What changes

Related

Solutions — LDAP Service Account Security · Privileged Password Vaulting · Privileged Account Discovery

Products — NHI LDAP Proxy · Privileged Access Management

Industries — Manufacturing · Finance