Group Managed Service Account (gMSA) is a managed domain account that provides automatic password management, service principal name (SPN) management, and the ability to delegate the management to other administrators over multiple servers.
Service accounts in Active Directory are used to identify and authenticate a service. A service account is a user account that is created to provide service ability to access local and network resources on the windows server operating system.
In large networks, to manage a lot of service accounts, Group Managed Service Accounts (gMSA), and standalone Managed Service Account (sMSA) accounts are used.
Using a group managed service account (gMSA), services or service administrators do not need to manage passwords,gMSA has their password managed by Active Directory.
gMSA provides a single identity solution for services running on the Windows operating system.
Group Managed Service Account (gMSA) is used for services, scheduled tasks, or IIS application pools.
In this article, I will explain group managed service account requirements and how to create a group managed service account (gMSA) using PowerShell.
Group Managed Service Account (gMSA) Requirement
Group Managed service accounts are not applicable to Windows Operating Systems prior to Windows Server 2012.
gMSA Requirements
- Windows Server 2012, Windows Server 2016, Windows Server 2019, Windows Server 2022
- Active Directory must be present
- PowerShell Active Directory module
- Domain controller in the domain must be running Window Server 2012 or later OS
Create Group Managed Service Account (gMSA) using PowerShell
To create a group-managed service account, the domain controller requires a root key to generate gMSA passwords.
Domain controllers wait for 10 hours from the time of creation to allow all DC to converge their AD replication.
Create KDS root key using Add-kdsRootKey Immediately
To create KDS (Key Distribution Service) root key immediately in the Domain controller, run the below command in PowerShell
Add-KdsRootKey -EffectiveImmediately
In the above Add-KdsRootKey cmdlet create the KDS root key immediately in the domain controller.
Using EffectiveImmediately
will add kds root key to target DC immediately, however other domain controller will not able to use it until replication is successful.
Create KDS root key using Add-kdsRootKey in Test Environment
To create KDS (key distribution service) root key immediately in a test environment only on DC, specify the start time in the past to avoid waiting for AD replication.
Run below command to create KDS root key with immediate effectiveness as below
Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))
In the above command, Add-kdsRootKey uses the EffectiveTime parameter to specify the past time ( 10 hours before time using get-date).
To confirm, if the kds root key was successfully created or not, run the below command in PowerShell
Get-kdsRootKey
The output of the above command to create kds root key and get created kds root key as below
Create Managed Service Account in Active Directory
Now as we have kds root key created above, we can now create group managed service account using New-ADServiceAccount
cmdlet as below
New-ADServiceAccount -Name "Engg-Service2" -DNSHostName "ENGG-Service2.SHELLPRO.LOCAL" -Enabled $True
In the above PowerShell script,
The New-ADServiceAccount cmdlet uses the Name
parameter to specify the service account name.
–DNSHostName
specifies the DNS hostname of the service account.
Above command create enabled managed service account as Engg-Service2
If you try to run Test-ADServiceAccount cmdlet to test managed service account created above (Engg-Service2), it will print a warning message as below
Test-ADServiceAccount -Identity "Engg-Service2"
The output of the above command shows a warning message below
To avoid the above warning message, we need to specify computer which computer can request and access passwords using Set-ADServiceAccount
cmdlet as below
Set-ADServiceAccount -Identity ENGG-Service2 -PrincipalsAllowedToRetrieveManagedPassword ENGG-PRO$
In the above PowerShell script, the Set-ADServiceAccount cmdlet set ENGG-PRO computer to retrieve managed password for managed service account specified using the Identity
parameter.
After we set computer name for the managed service account, run Test-ADServiceAccount
the cmdlet to test managed service account as below
Test-ADServiceAccount -Identity "Engg-Service2"
Above Test-ADServiceAccount test managed service account and return true.
Cool Tip: How to use the search-adaccount cmdlet in PowerShell!
Conclusion
I hope the above article on group managed service account (gMSA) requirement, creating the kds root key, and creating a group managed service account (gMSA) is helpful.
New-ADServiceAccount, Set-ADServiceAccount, Get-ADServiceAccount, and Test-ADServiceAccount cmdlets are used to manage service accounts in the active directory.
You can find more topics about PowerShell Active Directory commands and PowerShell basics on the ShellGeek home page.