Deploy a Group Managed Service Account (gMSA)

Admin

October 7, 2026

9 min read

A group Managed Service Account (gMSA) lets supported services use an identity whose password is managed by Active Directory. It can remove routine password rotation from service operations, but the account still needs least-privilege access and a defined set of authorized hosts.

Plan and test the change with the service owner. These examples use corp.example.com, an existing service-account OU, and a group named GG-gMSA-App01-Hosts; replace them with approved names in your environment. Run directory changes from a secured management host with the Active Directory PowerShell module and delegated permissions.

Check Forest, Module, and KDS Readiness

Prerequisites

gMSA support requires compatible AD DS functional levels and a KDS root key. Check for an existing root key before creating one. Microsoft notes that a newly created key needs time to replicate across DCs; do not create another key as a troubleshooting shortcut, and do not use the account until the key is available to all relevant DCs.

Import-Module ActiveDirectory
Get-ADForest | Select-Object ForestMode
Get-ADDomain | Select-Object DNSRoot, DomainMode
Get-KdsRootKey

Create or Review the Authorized Host Group

Access Control

Create a dedicated security group for the computer accounts that will run the service. Add only approved host computer accounts, then allow normal AD replication to distribute membership before installing the gMSA on those hosts. Do not authorize a broad group such as Domain Computers.

New-ADGroup -Name 'GG-gMSA-App01-Hosts' `
  -SamAccountName 'GG-gMSA-App01-Hosts' `
  -GroupScope Global -GroupCategory Security `
  -Path 'OU=Groups,DC=corp,DC=example,DC=com'

Add-ADGroupMember -Identity 'GG-gMSA-App01-Hosts' -Members 'APP01$'
Get-ADGroupMember 'GG-gMSA-App01-Hosts'

Create the Service Account Object

Provision

Use a name that identifies the workload, and set the password retrieval principals to the restricted group. Before running the creation command, confirm the name is unused across the forest and the target OU is approved for service accounts.

New-ADServiceAccount -Name 'gmsaApp01' `
  -DNSHostName 'gmsaApp01.corp.example.com' `
  -PrincipalsAllowedToRetrieveManagedPassword 'GG-gMSA-App01-Hosts' `
  -Path 'OU=Service Accounts,DC=corp,DC=example,DC=com'

Get-ADServiceAccount 'gmsaApp01' -Properties PrincipalsAllowedToRetrieveManagedPassword |
  Select-Object Name, DNSHostName, PrincipalsAllowedToRetrieveManagedPassword

Validate Password Retrieval Before Migration

Host Validation

On APP01, with the Active Directory module installed, install the gMSA and test that the host can retrieve its managed password. A failed test usually means to check group membership replication, KDS readiness, DNS, and the host’s secure channel before proceeding.

Install-ADServiceAccount -Identity 'gmsaApp01'
Test-ADServiceAccount -Identity 'gmsaApp01'

Migrate One Workload and Verify

Migrate

Coordinate a maintenance window with the service owner. Configure one supported Windows service, IIS application pool, or scheduled task to use CORP\gmsaApp01$ according to that workload’s documented gMSA procedure. Do not enter or store a password for the account. Grant only the file, database, log-on, and network rights the workload needs.

Service identity: CORP\gmsaApp01$
Password: managed by Active Directory; do not enter or store one
Migration: one workload on APP01 during the approved window
Rollback: previous identity retained for the agreed validation period