Microsoft 365


Active Directory


Windows Server


MVP Panel Talk: Do You Need to Backup Microsoft 365?


Windows Server 2012

How to Use Group Managed Service Accounts in Windows Server 2012

Russell Smith


Building on functionality provided by Managed Service Accounts (MSA) in Windows Server 2008 R2, Group Managed Service Accounts (gMSA) can be used across multiple servers. In this Ask an Admin, I’ll show you how to use gMSAs.

Using Group Managed Service Accounts (gMSA) in Windows Server 2012

Windows Server 2008 R2 MSAs are domain accounts intended for use when configuring Windows services, and unlike standard user accounts, they provide automatic password management and simplified SPN management. MSAs are better suited to Windows services than standard user accounts because the automatic password refresh reduces the risk associated with manually changing service account passwords and reduces administrative overhead. MSAs can only be associated with one server, and they can’t be used by IIS application pools or Microsoft SQL Server.

Windows Server 2012 introduces gMSAs, which add support for use across multiple devices, the above mentioned applications, scheduled tasks, and clustered or load-balanced services. They are created using PowerShell but can be viewed in the Active Directory Administrative Center. By default, gMSAs have domain user privileges. An administrator with access to a server on which a gMSA is installed could use the account for purposes other than was was originally intended, so make sure you follow security best practices and implement the principal of least privilege.

Setup a Group Managed Service Account

Group Managed Service accounts can only be used on servers running Windows Server 2012 (or later), and there must be at least one Windows Server 2012 (or later) domain controller in your Active Directory domain. The service you intend to configure must also be compatible with gMSAs.

The first step is to configure the Key Distribution Service, which gMSAs rely on for password management. When you create the root key in a lab environment, add (Get-Date).AddHours(-10) directly after the –EffectiveTime switch to make sure the key is replicated across all domain controllers straight away. In a production environment, (Get-Date).AddHours(-10) should be omitted.

Log on to your domain controller with a domain administrator account:

  • Open a PowerShell console using the blue icon on the desktop taskbar, or from the Start screen.
  • In the PowerShell console, type Add-KDSRootKey –EffectiveTime to enable the KDS Root Key for gMSAs.

In this example, I’m going to create a gMSA for Microsoft SQL Server.

  • Type the following to create a gMSA for SQL Server: New-ADServiceAccount –name SQLsrv –DNSHostName –Enabled $true –PrincipalsAllowedToRetrieveManagedPassword “domain controllers” 

Make sure that the DNS name in the command corresponds with the DNS name for your server. Usually you would specify a group created for the purposes of managing a group of servers. In my lab, SQL is being installed on a domain controller, so I can use the existing Domain Controllers group in AD. It’s best practice to specify a group using the –PrincipalsAllowedToRetrieveManagedPassword parameter, but it is possible to specify individual hosts instead.

Install a gMSA on a Host Server

Before you can use the gMSA, you need to install it on the server where the service will run. If the server is not a domain controller, the PowerShell module for Active Directory will need to be installed before you can run the install-adserviceaccount and test-adserviceaccount cmdlets. See my Ask the Admin article, “How to Install the Active Directory PowerShell Module on a Member Server” for instructions.

  • On the server where you want to configure a new service, log on as a domain administrator.
  • Open a PowerShell console using the blue icon on the desktop taskbar, or from the Start screen.
  • In the PowerShell console, type install-adserviceaccount SQLsrv, replacing SQLsrv with the name of your gMSA, and press Enter.
  • To test that installation was successful, type test-adserviceaccount SQLsrv, again replacing SQLsrv with the name of your gMSA, and press Enter. PowerShell should return True in the console window.

The gMSA created in the above steps is good to go. When specifying the account in the service configuration, you should add $ to the end of the service name to identify it as a gMSA, and leave the password field blank.

Group Managed Service Accounts (gMSA) in Windows Server 2012

Another useful switch that can be used with the New-ADServiceAccount cmdlet is –ServicePrincipalNames, which allows you to specify one or more SPNs for the gMSA if required.

Article saved!

Access saved content from your profile page. View Saved