Introduction
A Group Managed Service Account (gMSA) can be used for services running on multiple servers such as a server farm. ADFS, IIS and systems behind a Network Load Balance (NLB) are good examples of these. You can also use a gMSA to run services on a single server.
The main benefit from an identity perspective is that there is no password to manage for this account. The gMSA is configured on the servers and Windows handles the password management of the account.
This makes the solution easier to manage since there is no user interaction required to cycle the password on a regular basis. This would normally involve changing the password in Active Directory and then updating the individual services with the new password to ensure continuation of services.
This also eliminates service accounts with static passwords that are set upon creation, and then never cycled again, which I find is the norm with many customers to date. The reason for this is the effort involved in updating the password on multiple systems without causing downtime. Another common finding is that accounts were created long ago and current support staff are not sure on which systems the account are used. You won’t have the same experience when using a gMSA since the gMSA is configured to run on specific systems, which can be easily reviewed and updated during the account lifecycle.
The gMSA cannot be used to log on to any computers in the domain. This ensure the service account is only used for it’s intended purpose of running a service.
Key Distribution Services KDS Root Key
Domain Controllers require a root key to generate the password for gMSA accounts. I am not going into technical details on the root key, please refer to the references at the end of this article for more detailed information if required.
The root key only needs to be created once, thus if there are already gMSA accounts in the domain, then there is no need to create the root key. I will show you how to determine if the root key exists.
To determine if the root key exists I run Get-KdsRootKey in my forest root domain and child domain using Windows PowerShell. I have a 2 domain forest configuration. You will not see any output from the command when the root key does not exist:
I will now create the KDS Root Key by running Add-KdsRootKey -EffectiveImmediately on my root domain using Windows PowerShell:
The output result is a Guid value which indicates command completed successfully. Now when I run Get-KdsRootKey I will see the root key values in the output:
The KDS Root Key can also be viewed using the Active Directory Sites and Services Console. In the console, select View then select Show Services Node:
You will find the root key under the Master Root Keys node:
It is important to note that the root key will only be visible in the root domain of the forest, not in any of the child domains. You also cannot create a root key in a child domain. In the below example I used Windows PowerShell to view the root key in my child domain and the output did not display the root key. I also tried creating a root key while logged onto the child domain and received an error message:
You will need to wait 10 hours before new gMSA accounts can be created. This is a safety measure to ensure all Domain Controllers converge their replication before allowing the creation of a gMSA. This prevents password generation before all Domain Controllers are capable of answering the password requests.
Create a Group Managed Service Account (gMSA)
The root key is available in my root domain and I have waited the required 10 hours. I will now be able to create a gMSA in the root domain and in the child domain.
When creating the gMSA you need to specify the computer accounts that will be allowed to make use of the gMSA. The gMSA will not work on any computers that are not specified in the PrincipalsAllowedToRetrieveManagedPassword attribute. You can specify the computer accounts using a comma separated list, or you can specify a security group, and then add the computer accounts to the security group instead. I will demonstrate both.
To create a new gMSA in my root domain and specify the computer names I will run the following command:
New-ADServiceAccount -Name gmsa-Test01 -DNSHostName gmsa-Test01.thelabx.co.za -PrincipalsAllowedToRetrieveManagedPassword S01SRV0001$, S01SRV0002$
The gMSA account was created and can be seen in the Managed Service Accounts container:
Let’s view some of the properties for the gMSA account using Windows PowerShell. The command I use is as follows:
Get-ADServiceAccount gmsa-test01 -Properties * | FL DNSHostName,KerberosEncryptionType,ManagedPasswordIntervalInDays,Name,PrincipalsAllowedToRetrieveManagedPassword,SamAccountName
The PrincipalsAllowedToRetrieveManagedPassword attribute contains the distinguishedName values for the computer accounts that we specified during creation. The computer names specified has to be valid computer objects. The creation will fail if non-existing computer names are specified.
Take note of the default values for following attributes which we did not specify during creation:
- KerberosEncryptionType
- ManagedPasswordIntervalInDays
- SamAccountName
The default value for KerberosEncryptionType is RC4, AES128 and AES256. This can be updated after the account is created. You may want to specify the account to use only the highest level of encryption.
The default value for ManagedPasswordIntervalInDays is 30 days. This can only be specified when you create the account and cannot be modified later. This value determines the password change interval. Ensure you specify the required value during creation should you wish to use a custom password age for the account.
The SamAccountName attribute defaults to the Name attribute that we specified during creation. This can also be updated later or you can specify the SamAccountName value that you want to use when creating the account. Also take note of the $ (dollar) sign at the end of the name, similar to computer objects. This is the account name that you will use when you configure the services to use the gMSA.
Let’s create another gMSA and specify some additional parameters. I will also specify a security group for the PrincipalsAllowedToRetrieveManagedPassword attribute instead of computer accounts.
New-ADServiceAccount -Name gmsa-Test02 -DNSHostName gmsa-Test02.thelabx.co.za –KerberosEncryptionType AES256 –ManagedPasswordIntervalInDays 60 –SamAccountName testacc02 -PrincipalsAllowedToRetrieveManagedPassword G-gMSA-TestAccount
Let’s view some of the properties for the second gMSA account using Windows PowerShell. I use the same command that I used to view the properties of the first account, ensuring I specify the SamAccountName to display the correct account:
Get-ADServiceAccount testacc02 -Properties * | FL DNSHostName,KerberosEncryptionType,ManagedPasswordIntervalInDays,Name,PrincipalsAllowedToRetrieveManagedPassword,SamAccountName
We can now see that the account was created with the appropriate values that we specified during creation and is no longer using the default values as with the first account. The Name and SamAccountName values are not the same since the SamAccountName value matches what we specified during creation.
The PrincipalsAllowedToRetrieveManagedPassword attribute now contains the distinguishedName of the security group that we specified. Now I can add or remove computer accounts to the security group, instead of updating the gMSA account directly. Protect and audit the security group for membership changes to prevent unauthorized computers being allowed to use the gMSA.
Update gMSA attributes
As indicated, some attributes can be updated after the gMSA is created. I will now update the first gMSA account by modifying the computers that can use the gMSA and also updating the KerberosEncryptionType value. I will also change the SamAccountName and add two ServicePrincipalNames (SPN’s) to demonstrate how this is done, because some services like SQL requires SPN’s to be defined.
The update command will look as follows:
Set-ADServiceAccount gmsa-test01 -SamAccountName gmsa-newname -KerberosEncryptionType AES128 -PrincipalsAllowedToRetrieveManagedPassword S01SRV0003$ -ServicePrincipalNames @{Add=”MSSQLSvc/ITFarm1.contoso.com:1433″, “MSSQLSvc/ITFarm1.contoso.com:INST01”}
Take note that the format of the data provided for -ServicePrincipalNames is different when using the Set-ADServiceAccount compared to using the New-ADServiceAccount
Use comma seperate list when using New-ADServiceAccount for example: -ServicePrincipalNames value1, value2, value3, value4
Use the following syntax with the Set-ADServiceAccount command:
-ServicePrincipalNames @{Add=value1,value2,…}
-ServicePrincipalNames @{Remove=value3,value4,…}
-ServicePrincipalNames @{Replace=value1,value2,…}
-ServicePrincipalNames $null
When viewing the properties we should now see these new values assigned to the gMSA. Run the command again using the new SamAccountName value assigned to the gMSA and also include the ServicePrincipalNames property
Get-ADServiceAccount gmsa-newname -Properties * | FL DNSHostName,KerberosEncryptionType,ManagedPasswordIntervalInDays,Name,PrincipalsAllowedToRetrieveManagedPassword,SamAccountName,ServicePrincipalNames
The attributes have been updated successfully except that the PrincipalsAllowedToRetrieveManagedPassword value now only contains a single server. The previous value which contained two servers was replaced so now instead of having 3 servers in the list, we end up with the 1 server that we specified with the Set-ADServiceAccount command.
We can fix this by specifying the full list of servers:
Set-ADServiceAccount gmsa-newname$ -PrincipalsAllowedToRetrieveManagedPassword S01SRV0001$, S01SRV0002$, S01SRV0003$
Cross-domain usage
I haven’t found any detailed documents in regards to cross-domain usage of a gMSA account and have not been able to test in different scenarious.
I have however successfully deployed Azure ATP in my 2 domain forest. I created the gMSA in the root domain and configured Azure ATP to use this account to connect to Active Directory. The Azure ATP service started successfully on the child domain Domain Controller. The child domain Domain Controller is using the root domain gMSA to read objects in the child domain. Read the post here.
Closing thoughts
Opting to use gMSA instead of a normal service account wherever possible eliminates the need to manage the passwords for these accounts. You will no longer have service accounts with static passwords that are not changed on a regular basis.
The accounts cannot be used to log onto any servers and can only run services as intended. The PrincipalsAllowedToRetrieveManagedPassword attribute on the account will provide a clear indication of where the service account is intended to be used, no guesswork required. Now it will be an easy task to clean up unused accounts.
A gMSA can be used with Scheduled Tasks, so go ahead and run your maintenance tasks with a gMSA. The password will automatically change and there is no need to update the password on the individual tasks.
Azure AD Connect, On Demand Assessments, Azure Advanced Threat Protection (Azure ATP), SQL, IIS, System Centre Operations Manager 2019 UR1 (SCOM 2019 UR1) and ADFS supports Group Managed Service Accounts.
References
Group Managed Service Accounts Overview
Create the Key Distribution Services KDS Root Key
One thought on “Create a Group Managed Service Account (gMSA)”