Install and Configure a Group Managed Service Account with PowerShell

Managed Service Accounts (MSAs) were introduced in Windows Server 2008, and Group Managed Service Accounts (gMSAs) were introduced in Windows Server 2012.
Since then, a lot has been said about gMSAs (see the references section at the bottom).
So in this post, I’ll just summarize the flow and the PowerShell commands needed for each step in the process of creating and using gMSAs.

Before we really start, let’s set some variables we’ll use later on in our commands:

$gMSA_Name = 'gmsaWWW'
$gMSA_FQDN = ''
$gMSA_SPNs = 'http/www', 'http/'
$gMSA_HostNames = 'webServer01', 'webServer02', 'webServer03'

Step #1: Create the KDS Root Key (required only once per domain). This is used by the KDS service on DCs to generate passwords:

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

This is a workaround to the safety measure that makes us wait 10 hours (by default), to make sure all DCs have replicated and are able to respond to gMSA requests

Step #2: Get the principals (computer accounts) of the hosts that will use the gMSA:

$gMSA_HostsGroup = $gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ }

Or Create a group, and add the computer accounts to it:

$gMSA_HostsGroupName = "$($gMSA_Name)_HostsGroup"
$gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope Global -PassThru
$gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } | 
    ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }

Step #3: Create and Configure the gMSA

New-ADServiceAccount -Name $gMSA_Name -DNSHostName $gMSA_FQDN -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroup -ServicePrincipalNames $gMSA_SPNs

Set #4 (optional): If delegation is required:
Enable ‘Trust this user for delegation to any service’ (a.k.a. “Unconstrained Delegation”)

Set-ADServiceAccount -Identity $gMSA_Name -TrustedForDelegation $true

Note: To enable “Constrained Delegation“, you need to set it at creation time, using the -OtherAttributes parameter:

$myBackendSPNs = 'http/webBackend', 'http/'
New-ADServiceAccount -Name $gMSA_Name -DNSHostName $gMSA_FQDN -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroup -ServicePrincipalNames $gMSA_SPNs -OtherAttributes @{'msDS-AllowedToDelegateTo'=$myBackendSPNs}

Step #5: Then, on the Member servers that needs to use the gMSA:

$gMSA_Name = 'gmsaWWW'

(Optional) Install the gMSA:

Add-WindowsFeature -Name RSAT-AD-PowerShell 
Install-ADServiceAccount -Identity $gMSA_Name

This verifies that the computer is eligible to host the gMSA, retrieves the credentials and stores the account information on the local computer (using the NetAddServiceAccount function)

(Optional) Test the gMSA:

Test-ADServiceAccount -Identity $gMSA_Name

(Optional) Set the gMSA on an IIS ApplicationPool:

Import-Module WebAdministration
$pool = Get-Item IIS:AppPoolsDefaultAppPool
$pool.processModel.identityType = 3
$pool.processModel.userName = "$env:USERDOMAIN$gMSA_Name$"
$pool.processModel.password = ''
$pool | Set-Item

(Optional) Set the gMSA on a Windows Service:

$serviceName = 'myService'
$service = Get-WmiObject -Class Win32_Service -Filter "Name='$serviceName'"
$service.Change($null, $null, $null, $null, $null, $null, 
    "$env:USERDOMAIN$gMSA_Name$", $null, $null, $null, $null)

Note: If you use the UI (services.msc or IIS Manager) to set the LogOn credentials for the service or ApplicationPool Identity, don’t forget to add the $ (dollar sign) at the end of the gMSA name. As it represents the service account object, that inherits from the computer account object.