Group Managed Service Accounts (gMSA)

What Is a gMSA?

A group Managed Service Account is a special type of Active Directory account built to run Windows services, scheduled tasks, and IIS application pools without a human ever managing its password. Instead of an administrator setting a password and rotating it manually every few months, the domain controller computes it, and any host authorised to use the account retrieves it directly from AD.

Think of a gMSA as a service identity that Active Directory owns outright. Nobody writes its password down, nobody puts it in a script, and nobody has to remember to change it before it expires — the domain controller and the Microsoft Key Distribution Service (kdssvc.dll) handle the entire lifecycle.

gMSAs were introduced in Windows Server 2012 as the successor to the standalone Managed Service Account (sMSA) introduced in Windows Server 2008 R2. The key difference is scope: an sMSA is tied to a single computer and cannot be shared, while a gMSA can be used by any number of domain-joined servers at once — which is exactly what a load-balanced web farm or a clustered application needs.

gMSA vs sMSA vs a Regular Service Account

Windows supports several ways to give a service an identity, and each has a different password-management story.

The last row is what makes gMSAs the practical default for anything running on more than one server: web farms behind a load balancer, clustered scheduled tasks, and multi-node application services all need every instance to authenticate as the exact same principal, and only a gMSA manages that centrally.

Why Active Directory Cares

A gMSA’s password is a 240-byte random value, changed automatically — by default every 30 days — and derived from a secret shared across all domain controllers by the Key Distribution Service. The domain controller computes the password using that shared secret plus the gMSA’s own attributes; member hosts retrieve the current and previous values over LDAP by reading the msDS-ManagedPassword attribute, which only accounts listed in PrincipalsAllowedToRetrieveManagedPassword can read.

Kerberos authentication requires every instance of a load-balanced service to present the same principal with the same key, which is exactly what breaks when service accounts are managed by hand and drift out of sync between servers. A gMSA removes that failure mode entirely, because there is only ever one password in play, generated centrally and retrieved on demand — never copied into a script or a config file.

Prerequisites and the KDS Root Key

Before the first gMSA can be created anywhere in the forest, a KDS root key has to exist. This is the forest-wide secret the Key Distribution Service uses to derive every gMSA’s password, and it only needs to be created once per forest — creating a second one breaks existing gMSAs the next time their password rotates.

# Create the KDS root key (production / multi-DC environments)
# Domain controllers wait up to 10 hours for this to replicate before
# gMSA creation is permitted, so run this well ahead of when you need it
Add-KdsRootKey -EffectiveImmediately

# Single-DC lab or test environment only — backdates the key so it is
# usable immediately instead of waiting out the 10-hour replication window
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Creating, Installing, and Using a gMSA

The workflow is the same regardless of the service: create the account in AD, authorise the hosts that may retrieve its password, install it locally on each host, then point the service at it.

# Create the gMSA, authorising a security group to retrieve its password
New-ADServiceAccount -Name svc-webfarm -DNSHostName svc-webfarm.corp.example.com `
  -PrincipalsAllowedToRetrieveManagedPassword "WebFarmHosts"

# Add a member server's computer account to that security group
Add-ADPrincipalGroupMembership -Identity "WEB01$" -MemberOf "WebFarmHosts"

# On each member host, install the gMSA locally (requires the AD module)
Install-ADServiceAccount -Identity svc-webfarm

# Confirm this host can actually retrieve the gMSA's password
Test-ADServiceAccount -Identity svc-webfarm

# Review the full set of gMSA properties
Get-ADServiceAccount -Identity svc-webfarm | Select-Object *

# Rename the account's display name without recreating it
Set-ADServiceAccount -Identity svc-webfarm -DisplayName "Web Farm Service Account"

# Remove a gMSA entirely once it is no longer needed
Uninstall-ADServiceAccount -Identity svc-webfarm

Test-ADServiceAccount returning True is the confirmation that a given host can actually retrieve the gMSA’s password over LDAP — run it on every new member host before pointing a service at the account, not after something fails to start.

Once Install-ADServiceAccount and Test-ADServiceAccount both succeed on a host, the service itself needs to be pointed at the gMSA. In services.msc, open the service’s properties, go to the Log On tab, and enter the account as DOMAIN\gMSAName$ — leave both password fields blank, since the account does not have a password an administrator can type in. The same change from the command line uses sc.exe config:

# Point an existing Windows service at the gMSA (note the trailing $)
sc.exe config MyWebService obj= "CORP\svc-webfarm$"

IIS application pools and Scheduled Tasks accept the same DOMAIN\gMSAName$ identity format in their respective identity/run-as fields — no password prompt, because the Service Control Manager recognises the trailing $ and retrieves the current password from AD itself.

Version and Requirement Boundaries

Troubleshooting Cheat Sheet

Final Thoughts

A gMSA replaces a recurring manual chore — rotating a shared service password across every server that uses it — with something Active Directory just handles. The password is never typed, never stored in a script, and never goes stale because someone forgot to change it before an expiry deadline.

For anything running on more than one server that needs a consistent Kerberos identity — a web farm, a clustered scheduled task, a multi-node service — a gMSA should be the default choice over a hand-managed service account. The setup cost is one KDS root key per forest and a security group per gMSA; the payoff is a password rotation problem that stops being an administrator’s problem at all.