Last Update: Sep 24, 2024 | Published: Jan 28, 2014
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.
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.
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:
In this example, I’m going to create a gMSA for Microsoft SQL Server.
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.
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.
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.
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.