How to Set Up Windows Server 2016 Group Managed Service Accounts

Group Managed Service Accounts (gMSAs) extend the benefits of standalone Managed Service Accounts to multi-server environments. Introduced in Windows Server 2012, gMSAs are fully supported in Windows Server 2016 and allow multiple servers to share a single managed service account with automatic password rotation. This makes gMSAs ideal for clustered services, load-balanced web applications, IIS application pools, SQL Server instances in availability groups, and any scenario where a service runs across more than one host.

The key technology behind gMSAs is the Key Distribution Service (KDS), which runs on domain controllers and generates the managed passwords. The domain controller computes the gMSA password using a root key and provides it to authorized servers on demand. No administrator ever needs to know or set the password.

Step 1: Verify Prerequisites

gMSAs require a domain functional level of Windows Server 2012 or higher. Verify the domain functional level and ensure all domain controllers are running Windows Server 2012 or later:

Get-ADDomain | Select-Object DomainMode
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem

Also ensure the Active Directory module is available on your management host:

Import-Module ActiveDirectory

Step 2: Create the KDS Root Key

Before creating any gMSA, you must create a KDS root key on a domain controller. This key is used to generate the managed passwords. In production, the key has a 10-hour replication delay to ensure all domain controllers have it before the gMSA is used.

Add-KdsRootKey -EffectiveImmediately

In a lab or test environment, you can make the key effective immediately:

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Verify the root key was created:

Get-KdsRootKey

Step 3: Create a Security Group for the Authorized Servers

Create an Active Directory security group that contains all computer accounts permitted to retrieve the gMSA password. This is more manageable than listing individual computers:

New-ADGroup -Name "gMSA_WebFarm_Hosts" `
    -GroupScope Global `
    -GroupCategory Security `
    -Path "OU=Groups,DC=yourdomain,DC=com" `
    -Description "Computers authorized to use gMSA_WebFarm"

Add the server computer accounts to the group:

Add-ADGroupMember -Identity "gMSA_WebFarm_Hosts" `
    -Members "webserver01$", "webserver02$", "webserver03$"

Step 4: Create the Group Managed Service Account

Use New-ADServiceAccount to create the gMSA, specifying the security group as the principal allowed to retrieve the managed password:

New-ADServiceAccount -Name "gmsa_webfarm" `
    -DNSHostName "webfarm.yourdomain.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "gMSA_WebFarm_Hosts" `
    -KerberosEncryptionType AES128, AES256 `
    -Description "gMSA for web farm application pool"

Step 5: Install the gMSA on Each Target Server

On each server that will use the gMSA, install the account. Note that after adding a computer to the security group, you may need to restart the computer or refresh its Kerberos tickets for the group membership to take effect.

Install-ADServiceAccount -Identity "gmsa_webfarm"

Verify the installation succeeded on each server:

Test-ADServiceAccount -Identity "gmsa_webfarm"

Step 6: Configure Services to Use the gMSA

Configure the service or application pool to run under the gMSA. Enter the account name using the format DOMAINgmsa_webfarm$ with a blank password. For IIS application pools using PowerShell:

Import-Module WebAdministration
Set-ItemProperty "IIS:AppPoolsMyAppPool" -Name processModel -Value @{
    userName = "YOURDOMAINgmsa_webfarm$"
    password = ""
    identityType = 3
}

For a Windows service:

sc.exe config "MyServiceName" obj= "YOURDOMAINgmsa_webfarm$" password= ""

Step 7: Register SPNs if Required

If the service uses Kerberos authentication, register SPNs for the gMSA:

Set-ADServiceAccount -Identity "gmsa_webfarm" -ServicePrincipalNames @{
    Add = "HTTP/webfarm.yourdomain.com",
          "HTTP/webfarm"
}

Step 8: Verify the gMSA Password Retrieval

To confirm that the servers can retrieve the gMSA password from the domain controller, run the following on each host:

Invoke-Command -ComputerName webserver01, webserver02, webserver03 -ScriptBlock {
    Test-ADServiceAccount -Identity "gmsa_webfarm"
}

Step 9: Manage gMSA Lifecycle

To list all gMSAs in the domain and their authorized principals:

Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword |
Select-Object Name, Enabled, PrincipalsAllowedToRetrieveManagedPassword | Format-List

To add a new server to the authorized group after the gMSA is deployed:

Add-ADGroupMember -Identity "gMSA_WebFarm_Hosts" -Members "webserver04$"

Group Managed Service Accounts represent the gold standard for service account security in Windows Server 2016 environments. By eliminating manually managed passwords entirely and enabling shared credentials across server farms, gMSAs reduce administrative effort while improving security posture across your entire domain infrastructure.