Group Managed Service Accounts (gMSA): How to Replace Service Account Passwords with Automatic Key Management

The Key Distribution Service (KDS) root key must exist in the domain before any gMSA can be created. This is a one-time operation per domain.

Check if a KDS root key already exists:

Get-KdsRootKey
# Returns the key ID and creation time if one exists
# If empty output, no key exists yet

Create the KDS root key:

# For production (key becomes effective after 10-hour replication delay)
Add-KdsRootKey -EffectiveImmediately
# Note: 'EffectiveImmediately' actually means effective in 10 hours per AD replication rules
# For lab/test environments only (effective immediately, bypasses replication delay):
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

The key replicates to all DCs automatically. Wait for replication before creating gMSAs:

# Force AD replication if needed
repadmin /syncall /AdeP
# Then verify the key is available on all DCs
Get-KdsRootKey

The KDS root key is stored as a CN=Master Root Keys object under the Group Policy container. It does not need to be renewed -- one key per domain is sufficient for all gMSAs.

Each gMSA is created for a specific purpose (one gMSA per service or application is recommended). The host authorization list controls which machines can retrieve the password.

Create a security group for authorized hosts:

New-ADGroup -Name 'gMSA-WebApp-Hosts' `
    -GroupScope Global `
    -GroupCategory Security `
    -Path 'OU=Service Account Groups,DC=domain,DC=com'
# Add authorized hosts to the group
Add-ADGroupMember -Identity 'gMSA-WebApp-Hosts' `
    -Members 'WEBSERVER01$', 'WEBSERVER02$', 'WEBSERVER03$'

Create the gMSA:

New-ADServiceAccount `
    -Name 'svc-webapp' `
    -DNSHostName 'svc-webapp.domain.com' `
    -PrincipalsAllowedToRetrieveManagedPassword 'gMSA-WebApp-Hosts' `
    -KerberosEncryptionType AES128,AES256 `
    -Path 'OU=Service Accounts,DC=domain,DC=com' `
    -Description 'gMSA for WebApp service on WEBSERVER01-03'

Install the gMSA on the authorized host:

# Run on WEBSERVER01 (must be a member of gMSA-WebApp-Hosts group)
# Reboot may be required for new group membership to take effect
Install-ADServiceAccount -Identity 'svc-webapp'
# Verify it works
Test-ADServiceAccount -Identity 'svc-webapp'
# Should return: True

Windows service configuration:

# Set service to run as gMSA (note the trailing $ -- gMSA accounts always end with $)
Sc.exe config "MyServiceName" obj= "DOMAIN\svc-webapp$"
# Or via PowerShell
Set-Service -Name 'MyServiceName' -Credential ([System.Management.Automation.PSCredential]::new('DOMAIN\svc-webapp$', [System.Security.SecureString]::new()))
# Or via GUI: Services > Properties > Log On > This account: DOMAIN\svc-webapp$ (no password required)

Leave the password fields blank in the GUI -- gMSA accounts do not use a password field. The service account uses Kerberos to retrieve the password from AD.

IIS Application Pool configuration:

import-module WebAdministration
Set-ItemProperty IIS:\AppPools\MyAppPool -Name processModel.userName -Value 'DOMAIN\svc-webapp$'
Set-ItemProperty IIS:\AppPools\MyAppPool -Name processModel.password -Value ''
Set-ItemProperty IIS:\AppPools\MyAppPool -Name processModel.identityType -Value 3
# identityType 3 = SpecificUser

Restart the service/application pool after configuration:

Restart-Service 'MyServiceName'
# Or for IIS: iisreset /restart

Grant local permissions if needed:

# gMSA needs local permissions just like a standard service account
# For example, if the service needs 'Log on as a service' right:
# Computer Configuration > Windows Settings > Security Settings >
# Local Policies > User Rights Assignment > Log on as a service
# Add: DOMAIN\svc-webapp$

Migration is the hard part. Legacy service accounts often have undocumented dependencies -- scheduled tasks, COM+ applications, custom application configs.

Discovery step -- find all uses of a legacy service account:

# Find scheduled tasks using the account
Get-ScheduledTask | Where-Object { $_.Principal.UserId -like '*svc-old-account*' }
# Find Windows services
Get-WmiObject Win32_Service | Where-Object { $_.StartName -like '*svc-old-account*' } | Select-Object Name, StartName, SystemName
# Find IIS app pools (run on each web server)
import-module WebAdministration
Get-WebConfiguration system.applicationHost/applicationPools/add | Where-Object { $_.processModel.userName -like '*svc-old-account*' }

Permission migration: The gMSA needs the same permissions as the legacy account:

# Get current permissions of old account on a specific path
(Get-Acl 'C:\AppData').Access | Where-Object { $_.IdentityReference -like '*svc-old-account*' }
# Grant same permissions to gMSA
$acl = Get-Acl 'C:\AppData'
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule('DOMAIN\svc-webapp$', 'ReadAndExecute', 'ContainerInherit,ObjectInherit', 'None', 'Allow')
$acl.AddAccessRule($rule)
Set-Acl 'C:\AppData' $acl

SQL Server logins for service accounts:

-- Create login for gMSA in SQL Server
CREATE LOGIN [DOMAIN\svc-webapp$] FROM WINDOWS;
ALTER SERVER ROLE sysadmin ADD MEMBER [DOMAIN\svc-webapp$];
-- Or grant specific database permissions
USE MyDatabase;
CREATE USER [DOMAIN\svc-webapp$] FOR LOGIN [DOMAIN\svc-webapp$];