gMSA and the Case Against Standing Service Account Passwords

Every environment has them: the svc_sql, svc_backup, svc_iis accounts that run services, scheduled tasks, and app pools. Someone created them a decade ago, set a password, wrote it in a runbook, and moved on. That password has never rotated because rotating it means editing a service control-panel field on a dozen machines and praying nothing breaks. This is the single most durable privilege-escalation and lateral-movement vector in Windows environments — and it is entirely fixable.

Why standing service passwords are so dangerous

A service account with a static password fails on three security dimensions at once:

• Kerberoasting. Any authenticated domain user can request a service ticket for an account with an SPN, then crack the RC4/AES ticket offline. A service account with a human-set password like Summer2019! falls in seconds. No admin rights required to start.
• Credential reuse. The same svc_backup password is often configured on 40 machines. Pop one, dump LSASS, and you now authenticate as a highly-privileged identity across the entire fleet.
• Never rotates. Because rotation is operationally painful, these passwords survive employee departures, breaches, and audits. A password that leaked in 2021 is very likely still valid today.

The over-permissioning makes it worse. Service accounts are frequently dumped into Domain Admins "to make the install work," so a cracked ticket is not just lateral movement — it is domain compromise.

What gMSA actually changes

A Group Managed Service Account (gMSA) is a domain account whose password is generated and rotated by the domain controller itself — a 240-character random secret that changes every 30 days by default, and that no human ever sees or types. Member hosts authorized to use the account retrieve the current password from AD on demand via the Key Distribution Service.

This collapses the entire threat model:

• There is no password in a runbook, vault, or config file to leak.
• Kerberoasting is effectively dead against it — a 240-char random key is not crackable offline.
• Rotation is automatic and requires zero downtime; the KDS handles it transparently.
• Authorization is scoped to a specific security group of hosts, so a compromised web server cannot silently reuse the account elsewhere.

Provisioning one

Assuming the KDS root key already exists (create it once per forest), a gMSA takes three commands:

# One time per forest (allow 10h propagation, or -10h in a lab)
Add-KdsRootKey -EffectiveImmediately

# Group of hosts allowed to use the account
New-ADGroup -Name "gMSA_SQL_Hosts" -GroupScope Global
Add-ADGroupMember "gMSA_SQL_Hosts" -Members "SQL01$","SQL02$"

# The account itself
New-ADServiceAccount -Name "svc_sql_gmsa" `
  -DNSHostName "svc_sql_gmsa.corp.local" `
  -PrincipalsAllowedToRetrieveManagedPassword "gMSA_SQL_Hosts"

On each member host, install the account and point the service at it — note the trailing $ and the empty password:

Install-ADServiceAccount svc_sql_gmsa
# Service logon: CORP\svc_sql_gmsa$   (password field blank)

The migration reality

gMSA is not a drop-in for everything. It requires that the consuming service support running under a managed account — most Microsoft services (SQL Server, IIS app pools, scheduled tasks, ADFS) do; some third-party and cross-domain apps still do not. The pragmatic order of operations:

1. Inventory every account with an SPN or configured as a service/task logon.
2. Flag those with human-set, non-expiring passwords and excessive group membership.
3. Migrate the supported high-value ones (SQL, IIS, backup) to gMSA first.
4. For the accounts that genuinely cannot move, at minimum strip them out of privileged groups and enforce a long random password with a rotation schedule.

The goal is not "gMSA everywhere" on day one. It is "no service account with a crackable, never-rotating, over-privileged standing password." gMSA is the cleanest way to reach that, one service at a time.

How WinSentinel audits this

You cannot fix what you cannot see, and service-account sprawl is invisible until something enumerates it. WinSentinel runs the full account audit on every machine it inspects — free, on a single machine, with no limits — surfacing the exact conditions attackers look for:

• Services and scheduled tasks running under domain accounts rather than gMSA$, LocalService, or NetworkService.
• Accounts with SPNs set that are exposed to Kerberoasting, especially those with weak or non-expiring passwords.
• Service identities that are members of privileged groups they do not need.
• The same credential configured across multiple services — the reuse pattern that turns one compromise into fleet-wide movement.

For a single admin, that audit on your one workstation or server already tells you which accounts to fix. For organizations running many machines, WinSentinel Pro rolls those per-host findings up across the whole fleet from a central node — so you can see every host still running a service under a standing-password domain account, track your gMSA migration progress, and get drift alerts the moment a new bad service logon appears anywhere in the estate.

The takeaway

Static service-account passwords are the quietest high-severity risk in most Windows environments — they never trip an alert, never expire, and hand attackers a path from any authenticated user to domain admin. gMSA removes the password from human hands entirely. Start by finding the accounts that are doing it wrong; migrate the ones that can move; harden the rest. WinSentinel gives you the inventory to make that a plan instead of a guess.