Applies To:
- GroupID 9 and above
What is a Group Managed Service Account (gMSA)?
Group Managed Service accounts are perfect identity solutions for services running on multiple hosts. Password management requires no administration overhead as password management is handled automatically using Windows Server 2012 and later versions across multiple hosts. It also supports offline hosts that are not connected to the network for a period of time, and when they go back online, the password is synchronized on the service running on them, so that the service can start successfully.
| Note: | You can configure and administer group managed service accounts on Windows Server 2012 and later but you can still have other domain controllers running earlier versions of Windows Server operating system. |
Behind gMSAs is the new Microsoft Key Distribution Service that runs on every Server 2012 domain controller. It ensures that the password of the single service account that's used by different service instances in a web farm is kept in sync between those different instances.
To use gMSAs, your AD schema must be updated to Windows Server 2012 and one or more Server 2012 domain controllers need to be running the Microsoft Key Distribution Service. When you extend your schema for Windows Server 2012, a new object class is added for gMSAs – msDSGroupManagedServiceAccount.
It is derived from the computer class, with five new/additional attributes:
- msDS-GroupMSAMembership – governs which computers (groups of computers) are allowed to retrieve the password and make use of the gMSA.
- msDS-ManagedPassword – a binary blob containing (among other things) the current password, previous password and password change interval.
- msDS-ManagedPasswordInterval – configured at account creation (can’t be changed later), it determines how often (number of days) the password must be changed.
- msDS-ManagedPasswordID – key identifier used by Key Distribution Service (KDS) to generate the current password.
- msDS-ManagedPasswordPreviousID – key identifier from the previous password.
Following are important points to consider when configuring group managed service accounts:
- Managed service accounts can work across domain boundaries as long as the required domain trusts exist.
- A managed service account can be placed in a security group.
- Managed service accounts can be stored anywhere in Active Directory; nevertheless, there is also a specific container (Managed Service Accounts) for them.
- Passwords are automatically created for managed service accounts and are refreshed every 30 days.
Steps to configure gMSA with GroupID:
To configure a gMSA with GroupID, follow these steps:
- Create the KDS root key (has to be done once per forest)
- Create and configure a gMSA
- Configure the gMSA on GroupID 9 hosts
1. Create the KDS Root Key
This is used by the KDS service on DCs (along with other information) to generate passwords. It is required only once per forest.
On a Windows Server 2012 Domain Controller, open PowerShell with administrative privileges and run the following cmdlet:
| Add-KDSRootKey -EffectiveImmediately |
EffectiveImmediately doesn’t means that this service will be functional immediately in your production environment; you have to wait up to 10 hours. This is a safety measure to make sure all DCs have replicated and are able to respond to gMSA requests. There is a trick to bypass this safety measure, but should only be used in a lab environment.
2. Create and Configure a gMSA
First, identify or create a security group and add the computer objects of all GroupID 9 hosts that will be allowed to use the gMSA.
While you could grant individual computer objects the ability to use the gMSA, creating a security group to hold these computer objects will give you more administrative flexibility. The only downside to using a group is that, computers/hosts will need to be re-booted after being added/removed from the group to reflect membership changes. Next, you must use PowerShell (with the Server 2012 AD cmdlets) to create the gMSA. For creation, you must specify a name (SamAccountName) and dnsname. You’ll also want to specify the group allowed to use the gMSA and potentially SPNs for the account.
| New-ADServiceAccount -name <ServiceAccountName> -DNSHostName <fqdn> -PrincipalsAllowedToRetrieveManagedPassword <group> -ServicePrincipalNames <SPN1,SPN2,…> |
In my case, I’ll only specify the Name, DNSHostName, and PrincipalsAllowedToRetreiveManagedPassword:
If you get a “key does not exist” error, you forgot to do step 1 (Create the KDS Root Key) or you have not waited for 10 hours. You will notice a new gMSA object in your domain’s Managed Service Accounts OU.
3. Configure the gMSA on the GroupID host
Enable the Active Directory module for Windows PowerShell on the GroupID 9 host machine. To do this, run the following command from GroupID 9 PowerShell:
| Get-WindowsFeature AD-Domain-Services |
| Install-WindowsFeature AD-Domain-Services |
Restart the GroupID machine. Now install the gMSA by running the following command from the PowerShell command prompt:
| Install-AdServiceAccount <gMSA> |
Test your gMSA account by running the following command:
| Test-AdServiceAccount <gMSA> |
You’ll notice the test-ADServiceAccount returns “True”, indicating that the gMSA is installed on the GroupID machine. Provide Active Directory and Exchange permissions to the gMSA. You can view our KB article, Service account for Active Directory and Exchange for more details. Add gMSA as a local administrator on the GroupID 9 machine. Next, run the GroupID Configuration Tool to run GroupID services under gMSA. To do so:
- Launch the GroupID Configuration Tool from the Windows Start screen or from GroupID Management Console (Configurations node > Configure GroupID).
- Click Next until you reach the Service Account Settings page. Add your gMSA for ‘App pool’ and ‘Windows Services’. Make sure to keep the Password field empty. By default, the GroupIDSSuser account is used for scheduled jobs, which is a local account.
Note: If Key Distribution Service (KDS) is not configured in the environment, a warning will be displayed that you cannot use a Group Managed Service Account. -
Click Configure.
- The next step is to add the gMSA in identity store settings. You can create a new identity store or modify your regular service account with gMSA in identity store properties. Make sure to add ‘$’ at the end of the gMSA.