Creating gMSA Objects in Active Directory
Welcome!
Welcome to our blog! I have been working on an automation project that will utilize gMSA objects in Active Directory, also referred to as Group Managed Service Accounts. This post will be a short one and it outlines some quick and easy steps to get a gMSA created, assigned and tested. To perform these steps, you need to have a domain administrator account within Active Directory.
What is a gMSA and Why is it important?
One of the most powerful tools I’ve encountered in Active Directory is the Group Managed Service Account, or gMSA. If you’re managing a network with multiple services and applications, understanding gMSAs can make your life significantly easier.
So, what exactly is a gMSA? In simple terms, a gMSA is a type of service account in Active Directory that provides automatic password management and simplified service principal name (SPN) management for multiple servers. Unlike traditional service accounts, which require manual password updates and management, gMSAs automatically update their passwords regularly, eliminating a common security risk and administrative burden.
Why is this important? Well, in any organization, security is a top priority, and managing service account passwords manually is not only cumbersome but also prone to errors. With gMSAs, passwords are changed automatically without service interruption, ensuring that your accounts are always secure without the need for manual intervention. This significantly reduces the risk of password-related security breaches and simplifies compliance with security policies. Moreover, gMSAs are particularly useful in environments where services run across multiple servers. They allow you to assign a single service account to multiple servers, streamlining administration and improving efficiency. For example, if you have a web application that runs on a server farm, you can use a gMSA to manage the service account for all the servers in the farm, rather than creating and managing separate accounts for each server.
By leveraging gMSAs, You can ensure that my network services are not only more secure but also easier to manage. This helps me focus on more strategic tasks, knowing that the routine but critical task of password management is handled automatically. Whether you’re running a small network or a large enterprise environment, gMSAs are a vital tool in your Active Directory toolkit.
Steps to Create a Group Managed Service Account
To create our account, it is required to have a Key Distribution Services (KDS) Root Key in Active Directory. I also recommend having an Active Directory group created that will grant permissions to this gMSA, ideally a unique group per gMSA. Members of this group will be allowed to utilize the gMSA, anyone with administrative rights to servers added to the group or gMSA directly will be able to run operations as the gMSA. Be sure to give the gMSA the least amount of privilege needed.
Check Your KDS Root Key
First, check to see if you have a key created by opening PowerShell as administrator on a machine with the ActiveDirectory PowerShell module installed and run the Get-KDSRootKey command. If not results are returned, you do not have a KDS Root Key created. Example is below.
#Check for an existing KDS Root Key
Get-KDSRootKey
#Example Output/Response:
AttributeOfWrongFormat :
KeyValue : {243, 166, 110, 211...}
EffectiveTime : 7/16/2024 6:07:17 PM
CreationTime : 7/16/2024 8:07:17 AM
IsFormatValid : True
DomainController : CN=DBTLAB02-DC01,OU=Domain Controllers,DC=dbtlab02,DC=com
ServerConfiguration : Microsoft.KeyDistributionService.Cmdlets.KdsServerConfiguration
KeyId : bb8ca585-8dd4-7ddb-01fd-896a0450f21e
VersionNumber : 1
If needed, create the KDS Root Key with the below PowerShell command. Note that there is a time specified in this command. This command makes the key active in 10 hours. This is to ensure that Active Directory has enough time to replicate this throughout your entire environment, before the key becomes active. If you are in a test/lab environment, you can likely lower this time limit.
#Create KDS Root Key
Add-KdsRootKey -EffectiveTime ((get-date).AddHours(10))
Create the Group Managed Service Account
Once the KDS Root Key is created and active, you can create your Group Managed Service Account with the below command. There are several parameters used in this command.
*Note the gMSA needs to be granted the Logon as a Service and Logon as a Batch Job permissions to the machine(s) you plan to use the account on. This can be done via Group Policy or Local Security Policy. The path in the policies to do this is Computer –> Policies –> Windows Settings –> Security Settings –> Local Policies –> User Rights Assignment
Parameter Name | Parameter Value and Function |
-Name | This is the name of the gMSA you are creating. This of this as the username or samaccountname |
-DNSHostName | This is a DNS hostname of the user object you are creating, not of a computer or application |
-PrincipalsAllowedToRetrieveManagedPassword | This is the full DN of a group or computer object that is allowed to use the gMSA. |
New-ADServiceAccount -Name ExampleGMSA -DNSHostName examplegmsa.yourdomain.com -PrincipalsAllowedToRetrieveManagedPassword "CN=GRP_gMSA_Example,CN=Users,DC=example,DC=com"
Install and Test the Group Managed Service Account
Now that the gMSA has been created, you can Install the gMSA on your target system and test it. Perform these steps from an elevated PowerShell prompt on the machine that needs to use the gMSA.
#Install the gMSA
Install-ADServiceAccount -Identity ExampleGMSA
#Test the gMSA
Test-ADServiceAccount -Identity ExampleGMSA
That’s All Folks
Thanks for taking a couple of minutes of your day to read! I hope you have found this useful. Have a great day and week ahead!
Check out additional blog posts at our Blog