Configuring Group Managed Service Accounts (gMSA)

Overview

Group Managed Service Accounts (gMSA) are a type of Active Directory account designed specifically to run Windows services, IIS application pools, scheduled tasks, and other background processes. Unlike standard user accounts used as service accounts, gMSAs have their passwords managed and automatically rotated by Active Directory – eliminating the operational burden of manual password changes and the security risk of static, never-expiring service account passwords.

gMSAs were introduced in Windows Server 2012. They extend the original Managed Service Account (MSA) feature by supporting use across multiple servers simultaneously – a single gMSA can be installed on any number of computers in the domain, making them suitable for clustered services and load-balanced environments.

Prerequisites

• At least one Windows Server 2012 or later Domain Controller in the domain
• The Active Directory module for Windows PowerShell installed (part of RSAT)
• A KDS Root Key created in Active Directory (one-time setup per domain)
• Domain Admin or delegated permissions to create service accounts
• Local Administrator rights on the target computer where the service will run

Step 1 – Create the KDS Root Key

The Key Distribution Service (KDS) Root Key is a domain-wide cryptographic key that Active Directory uses to generate and rotate gMSA passwords. This is a one-time setup per domain – once created, it is used for all gMSAs in that domain. You do not need to repeat this step when creating additional gMSAs.

Open PowerShell as Administrator and run:

Add-KdsRootKey -EffectiveImmediately

The -EffectiveImmediately parameter sets the key’s effective date to the past so it is immediately usable. In production environments, Active Directory normally requires a 10-hour propagation window before the key is trusted across all domain controllers. The -EffectiveImmediately flag bypasses this for lab and test environments – in a production multi-DC domain, allow the full 10-hour window instead by omitting the flag and running Add-KdsRootKey without it the night before you plan to create gMSAs.

Step 2 – Create the Group Managed Service Account

With the KDS Root Key in place, create the gMSA using New-ADServiceAccount. The key parameters are:

• -Name – the name of the gMSA object in Active Directory
• -DNSHostName – the fully qualified DNS hostname the service will be associated with
• -PrincipalsAllowedToRetrieveManagedPassword – specifies which computer accounts (or security groups) are allowed to retrieve the gMSA password. Use the computer name with a trailing $ to reference the computer account.

New-ADServiceAccount -Name "gMSA_Name" 
    -DNSHostName "hostname.domain.com" 
    -PrincipalsAllowedToRetrieveManagedPassword "ComputerName$"

To allow multiple computers to use the same gMSA, create a security group, add all target computer accounts to the group, and specify the group name in -PrincipalsAllowedToRetrieveManagedPassword instead of individual computer names. This is the recommended pattern for clustered or load-balanced services.

Step 3 – Install the Service Account on the Target Computer

After creating the gMSA in Active Directory, you must install it on each computer that will use it. Run this command on the target computer (not the DC) from an elevated PowerShell session:

Install-ADServiceAccount -Identity "gMSA_Name"

This command verifies that the local computer is in the allowed principals list and registers the gMSA locally. If the computer account is not in the allowed principals list, this command will fail with an access denied error – go back to Active Directory and add the computer account to PrincipalsAllowedToRetrieveManagedPassword.

Step 4 – Verify the Installation

Confirm the gMSA is correctly installed and that the local computer can retrieve the managed password:

Test-ADServiceAccount -Identity "gMSA_Name"

A return value of True confirms successful installation and that the computer can retrieve the gMSA password from Active Directory. A return of False indicates a problem – check the computer account membership in the allowed principals group and ensure the KDS Root Key has propagated to all domain controllers.

Step 5 – Configure the Service to Use the gMSA

With the gMSA installed and verified, configure the Windows service to log on with this account. Open Services.msc (Start → Run → services.msc), locate the service you want to configure, and open its properties. Navigate to the Log On tab.

Select This account and enter the gMSA in the format DOMAIN\gMSA_Name$ – the trailing dollar sign ($) is required and identifies this as a managed service account rather than a standard user account. Leave both the Password and Confirm Password fields completely blank. Active Directory manages the password automatically; entering anything in those fields will cause the configuration to fail.

Click OK, then restart the service to apply the change. The service will now log on using the gMSA, and Active Directory will rotate its password automatically on the default 30-day schedule without any administrative action required.

Important Considerations

The Trailing Dollar Sign

The $ suffix at the end of the account name in Services.msc is not optional. It signals to the Windows Service Control Manager that this is a managed service account and that it should retrieve the password from Active Directory rather than using a stored credential. Omitting the $ causes the service configuration to fail with a logon failure error.

Password Rotation

Active Directory rotates the gMSA password every 30 days by default. This rotation is transparent to the service – the Service Control Manager automatically retrieves the new password from Active Directory when the service starts after a rotation event. There is no downtime or manual intervention required during password rotation.

Multiple Servers

To deploy the same gMSA to multiple servers (for example, in a web farm or a Windows Server Failover Cluster), create an Active Directory security group, add all relevant computer accounts to that group, and specify the group in -PrincipalsAllowedToRetrieveManagedPassword when creating the gMSA. Then run Install-ADServiceAccount on each server individually. Each server in the group can retrieve the password independently.

gMSA vs. sMSA

Standalone Managed Service Accounts (sMSA, introduced in Windows Server 2008 R2) are limited to a single computer – they cannot be shared. gMSAs remove this restriction and are the recommended account type for any new service account deployments. There is no technical reason to use sMSAs for new deployments on Windows Server 2012 or later.