How to Configure Group Managed Service Accounts (gMSA) on Windows Server 2012 R2

Group Managed Service Accounts (gMSAs) extend the concept of Managed Service Accounts to support multiple hosts simultaneously. Where standard MSAs are limited to a single computer, gMSAs can be used across an entire server farm, NLB cluster, or any group of servers. This makes gMSAs ideal for IIS application pools, scheduled tasks, and services running on multiple hosts in a high-availability configuration. Like standard MSAs, gMSAs feature automatic password rotation managed by Active Directory, but the password is computed using a Microsoft Key Distribution Service (KDS) root key and can be retrieved by any authorised host computer. Windows Server 2012 R2 fully supports gMSAs and is the recommended service account type for all multi-host scenarios.

Prerequisites

gMSAs have the following requirements:

The domain must have at least one domain controller running Windows Server 2012. The KDS root key must be created and propagated before gMSAs can be issued. Service host computers must run Windows Server 2012, Windows Server 2012 R2, Windows 8, or later. Domain Admin rights are required to create gMSAs and the KDS root key. The ActiveDirectory module must be imported.

Import-Module ActiveDirectory

Step 1 — Create the KDS Root Key

The Key Distribution Service (KDS) root key is the cryptographic seed used by domain controllers to compute gMSA passwords. Only one KDS root key is typically needed per forest. The key requires a 10-hour propagation period before gMSAs can use it in production — this ensures all DCs have the key before any host requests a gMSA password.

# Create the KDS root key with the 10-hour propagation delay (production)
Add-KdsRootKey -EffectiveImmediately
# Note: The above uses -EffectiveImmediately but still has internal logic
# For true immediate use (lab/testing only):
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

# Verify the KDS root key was created
Get-KdsRootKey

In a production environment, always use the default propagation period and wait 10 hours before creating gMSAs that will be actively used.

Step 2 — Create a Security Group for gMSA Hosts

Create a security group containing all computer accounts that are permitted to retrieve the gMSA’s password. This is the authorisation mechanism for gMSA access:

# Create a group for the web farm computers
New-ADGroup -Name "gMSA-WebFarm-Hosts" `
    -GroupScope DomainLocal `
    -GroupCategory Security `
    -Path "OU=Groups,OU=Contoso,DC=contoso,DC=com" `
    -Description "Computers authorised to use gMSA for web farm"

# Add the server computer accounts to the group
Add-ADGroupMember -Identity "gMSA-WebFarm-Hosts" `
    -Members @("WEB01$","WEB02$","WEB03$","WEB04$")

# If adding computer accounts, you can query and add them
Get-ADComputer -Filter {Name -like "WEB*"} |
    ForEach-Object { Add-ADGroupMember -Identity "gMSA-WebFarm-Hosts" -Members $_ }

After adding new computers to the group, the computer must be rebooted (or klist purge run) so that Kerberos tickets are refreshed to include the new group membership. This is required before the gMSA password can be retrieved by the newly-added host.

Step 3 — Create the gMSA

Create the gMSA and specify which computers are authorised to retrieve its password using PrincipalsAllowedToRetrieveManagedPassword:

# Create the gMSA
New-ADServiceAccount `
    -Name "gmsa-webfarm" `
    -DNSHostName "webfarm.contoso.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "gMSA-WebFarm-Hosts" `
    -Description "gMSA for IIS web farm - WEB01 through WEB04" `
    -ServicePrincipalNames @("HTTP/webfarm.contoso.com","HTTP/webfarm")

# Verify the gMSA was created
Get-ADServiceAccount -Identity "gmsa-webfarm" -Properties * |
    Select-Object Name, DNSHostName, PrincipalsAllowedToRetrieveManagedPassword,
    ServicePrincipalNames, PasswordLastSet

Step 4 — Install the gMSA on Each Host

On each web server in the farm, install the gMSA to allow the local system to retrieve and cache the managed password. This step also verifies that the computer is authorised to use the account:

# Install on each host (run on each server or via remoting)
$webServers = @("WEB01","WEB02","WEB03","WEB04")
foreach ($server in $webServers) {
    Invoke-Command -ComputerName $server -ScriptBlock {
        Import-Module ActiveDirectory
        Install-ADServiceAccount -Identity "gmsa-webfarm"
        $result = Test-ADServiceAccount -Identity "gmsa-webfarm"
        Write-Host "$env:COMPUTERNAME - Test result: $result"
    }
}

Step 5 — Configure IIS Application Pool to Use gMSA

Configure an IIS application pool to run under the gMSA identity. The password field is always left blank — IIS retrieves the password automatically from AD:

# Configure IIS application pool on all web servers
$webServers = @("WEB01","WEB02","WEB03","WEB04")
foreach ($server in $webServers) {
    Invoke-Command -ComputerName $server -ScriptBlock {
        Import-Module WebAdministration
        
        # Set the application pool identity to gMSA
        $pool = Get-Item "IIS:AppPoolsDefaultAppPool"
        $pool.processModel.userName = "CONTOSOgmsa-webfarm$"
        $pool.processModel.password = ""
        $pool.processModel.identityType = 3  # SpecificUser
        $pool | Set-Item
        
        # Restart the application pool
        Restart-WebAppPool -Name "DefaultAppPool"
        Write-Host "$env:COMPUTERNAME - App pool configured"
    }
}

Step 6 — Configure Windows Services to Use gMSA

# Configure a Windows service to use the gMSA
Invoke-Command -ComputerName "WEB01" -ScriptBlock {
    sc.exe config "MyService" obj= "CONTOSOgmsa-webfarm$" password= ""
    Restart-Service "MyService"
}

Adding New Hosts to an Existing gMSA

When scaling out a farm, add new servers to the authorised principals group and install the gMSA on the new hosts:

# Add new web servers to the group
Add-ADGroupMember -Identity "gMSA-WebFarm-Hosts" -Members @("WEB05$","WEB06$")

# Install on new hosts (after group membership propagates via Kerberos ticket refresh)
$newServers = @("WEB05","WEB06")
foreach ($server in $newServers) {
    Invoke-Command -ComputerName $server -ScriptBlock {
        Import-Module ActiveDirectory
        Install-ADServiceAccount -Identity "gmsa-webfarm"
        Test-ADServiceAccount -Identity "gmsa-webfarm"
    }
}

Managing gMSA SPNs

# Add additional SPNs to the gMSA
Set-ADServiceAccount -Identity "gmsa-webfarm" -ServicePrincipalNames @{
    Add = "HTTP/www.contoso.com","HTTP/intranet.contoso.com"
}

# List all SPNs
Get-ADServiceAccount -Identity "gmsa-webfarm" -Properties ServicePrincipalNames |
    Select-Object -ExpandProperty ServicePrincipalNames

Auditing gMSAs

# List all gMSAs in the domain
Get-ADServiceAccount -Filter {ObjectClass -eq "msDS-GroupManagedServiceAccount"} `
    -Properties PrincipalsAllowedToRetrieveManagedPassword, ServicePrincipalNames,
    PasswordLastSet, DNSHostName |
    Select-Object Name, DNSHostName, PasswordLastSet,
    @{N="AuthorisedGroup";E={$_.PrincipalsAllowedToRetrieveManagedPassword -join ";"}} |
    Format-Table -AutoSize

Summary

Group Managed Service Accounts on Windows Server 2012 R2 represent the gold standard for service account management in multi-server scenarios. They combine the operational simplicity of automatic password rotation with the flexibility to work across an entire server farm. The configuration process involves creating a KDS root key, creating a security group of authorised host computers, creating the gMSA pointing to that group, and installing the account on each host. Services and IIS application pools use the gMSA with a blank password entry — the system handles credential retrieval automatically. gMSAs should be the default choice for any new service account in a Windows Server 2012 R2 or later environment.