Configuring Group Managed Service Accounts (gMSA)

Static service-account passwords are one of those security debts that slowly eat an organization. They never expire, they never get rotated, they get reused across services, and they end up scattered through PowerShell scripts, scheduled task XML, and IIS application pool config — all of which are accessible to anyone with local administrator on the host. Group Managed Service Accounts (gMSA) close this gap: AD generates and rotates the password automatically (every 30 days by default), nothing on the host ever sees a credential, and the same gMSA can be installed on multiple computers for clustered or load-balanced services.

This walkthrough covers the full flow end to end — one-time KDS Root Key bootstrap for the domain, gMSA creation in AD, installation on the target host, verification, and then wiring the gMSA into a Windows service.

What you need before starting

• At least one Windows Server 2012 or later domain controller in the domain
• Active Directory PowerShell module (RSAT-AD-PowerShell) on the host where you create the gMSA
• A KDS Root Key in the domain — created once per domain, reused for every gMSA forever after
• Domain Admin rights (or delegated rights to create service accounts)
• Local Administrator rights on the target host where the service will actually run

Step 1 — Bootstrap the KDS Root Key

The Key Distribution Service (KDS) Root Key is the per-domain cryptographic root that AD uses to derive and rotate gMSA passwords. One per domain, ever. If you’ve already created gMSAs in this domain, the key exists; skip to Step 2.

Open an elevated PowerShell on a DC (or any host with the AD module) and run:

Add-KdsRootKey -EffectiveImmediately

The -EffectiveImmediately flag is a lab-only convenience that backdates the key’s effective time so it’s usable right now. In a multi-DC production domain, AD enforces a 10-hour propagation delay before the key is trusted across all DCs — the recommended pattern is to run Add-KdsRootKey without the flag at end-of-day on a Friday and have it ready for use on Monday. Skipping the wait by using -EffectiveImmediately in production can cause sporadic gMSA failures while replication catches up. For lab/test environments with one DC, the flag is fine.

Step 2 — Create the gMSA in AD

With the KDS Root Key in place, create the gMSA object with New-ADServiceAccount. The three parameters that matter:

• -Name — the AD object name (and the SamAccountName, with $ appended automatically)
• -DNSHostName — the FQDN the service is associated with; required even when the service isn’t exposed via DNS
• -PrincipalsAllowedToRetrieveManagedPassword — the computer accounts (or, better, AD security groups) allowed to fetch the password from AD. Computer accounts are referenced with a trailing $, which is how AD names computer SAMs.

New-ADServiceAccount -Name "gMSA_Name"
    -DNSHostName "hostname.domain.com"
    -PrincipalsAllowedToRetrieveManagedPassword "ComputerName$"

Strongly recommend: even for single-host gMSAs, create an AD security group, add the computer account to it, and pass the group name to -PrincipalsAllowedToRetrieveManagedPassword. The reason is operational — when you eventually need to add a second host (you will), it’s a one-line group membership change instead of editing the gMSA’s allowed-principals list and re-running setup. For clustered or load-balanced services this is the only sane way; the group becomes the boundary of who can run the service.

Step 3 — Install the gMSA on the target host

Creating the gMSA in AD doesn’t make any host able to use it. You also have to install it on each host that’s allowed to retrieve its password. Connect to the target host (the one running the service, not the DC), open elevated PowerShell, and run:

Install-ADServiceAccount -Identity "gMSA_Name"

This call:

1. Validates that the local computer’s account is in the gMSA’s allowed-principals list
2. Retrieves the current password from AD via Kerberos
3. Caches the necessary metadata locally so the Service Control Manager can fetch passwords on subsequent rotations

If the install fails with an access-denied error, the most likely cause is that the local computer account isn’t in the allowed-principals group/list. Add it in AD, reboot the host (so the new group membership lands in the computer’s Kerberos ticket), and retry.

Step 4 — Verify the install worked

One quick sanity check before wiring up the service:

Test-ADServiceAccount -Identity "gMSA_Name"

It returns True if everything is in order — the local host is authorized, the password retrieval works, the cached metadata is correct. If it returns False, the usual culprits are:

• The computer account isn’t in the allowed-principals group (re-check; reboot if you just added it)
• The KDS Root Key hasn’t finished propagating to all DCs in a multi-DC domain (give it the 10 hours, or check on which DC the key was created)
• Time skew — Kerberos requires the host clock within 5 minutes of the DCs

Step 5 — Configure the Windows service to use the gMSA

With the gMSA installed and tested, point the actual service at it. Open services.msc, find the service, right-click > Properties, switch to the Log On tab.

Pick This account and enter the account name in the form DOMAIN\gMSA_Name$. The trailing dollar sign is mandatory. It tells the Service Control Manager “this is a managed account, fetch the password from AD; don’t store one locally.” Leave the Password and Confirm Password fields completely empty — if you type anything in them, SCM tries to use the typed value as a static password and the configuration breaks.

Click OK. Restart the service. From this point on, AD owns the password — you never see it, never store it, and the 30-day rotation happens transparently with no service interruption.

Things that bite people in production

The mandatory dollar sign

The $ suffix in the service Log On account is not optional. It’s the marker that tells SCM “managed account — ask AD for the password.” Without it, SCM treats the entry as a regular user account, can’t resolve a password, and the service fails to start with a logon-failure event in the Security log. This is the single most common gMSA configuration mistake.

Password rotation is invisible — that’s the point

The default 30-day rotation requires zero operator intervention. SCM detects the password change at next service start, retrieves the new one from AD, and uses it. Don’t script around it, don’t monitor for it, don’t add “rotate gMSA password” to your runbook — AD already does it.

Group-based principals scale; per-computer principals don’t

If you used per-computer entries in -PrincipalsAllowedToRetrieveManagedPassword, every new host means re-running Set-ADServiceAccount -PrincipalsAllowedToRetrieveManagedPassword with the full updated list (the parameter replaces, not appends). Group-based principals avoid that whole class of operational mistakes — add the host to the group, run Install-ADServiceAccount locally, done.

gMSA vs. sMSA — pick gMSA

Standalone Managed Service Accounts (sMSA, Windows Server 2008 R2) were the previous generation: same auto-rotated password story, but each sMSA is bound to exactly one host. There’s no technical reason to use sMSAs for any new service account on Windows Server 2012 or later — gMSA covers single-host and multi-host equally well, and you don’t want to migrate later.

Don’t use the same gMSA for unrelated services

Each service should have its own gMSA. Sharing one gMSA across multiple unrelated services means a compromise of any one of them is a compromise of all of them — same identity, same access. The whole point of gMSA is to make per-service identities cheap; use that.

Where this fits

gMSAs are the right answer for any non-interactive workload that needs an AD identity: SQL Server services, IIS app pools, Task Scheduler tasks running scripts, Veeam / backup agents, monitoring agents (SCOM, Datadog), Exchange split-permissions service accounts. For deeper security hygiene around service accounts more broadly, see configuring advanced audit policies (so service-account logons are logged) and the Active Directory pathway for protected-users group, AdminSDHolder, and tier-0 isolation patterns that keep service identities from becoming privilege-escalation paths.