Group managed service accounts (gMSAs) are domain accounts to help secure services. gMSAs can run on one server, or in a server farm, such as systems behind a network load balancing or Internet Information Services (IIS) server. After you configure your services to use a gMSA principal, account password management is handled by the Windows operating system (OS).
Benefits of gMSAs
gMSAs are an identity solution with greater security that help reduce administrative overhead:
Set strong passwords - 240-byte, randomly generated passwords: the complexity and length of gMSA passwords minimizes the likelihood of compromise by brute force or dictionary attacks
Cycle passwords regularly - password management goes to the Windows OS, which changes the password every 30 days. Service and domain administrators don't need to schedule password changes, or manage service outages.
Support deployment to server farms - deploy gMSAs to multiple servers to support load balanced solutions where multiple hosts run the same service
Support simplified service principal name (SPN) management - set up an SPN with PowerShell, when you create an account.
In addition, services that support automatic SPN registrations might do so against the gMSA, if the gMSA permissions are set correctly.
Using gMSAs
Use gMSAs as the account type for on-premises services unless a service, such as failover clustering, doesn't support it.
Important
Test your service with gMSAs before it goes to production. Set up a test environment to ensure the application uses the gMSA, then accesses resources. For more information, see Support for group managed service accounts.
If a service doesn't support gMSAs, you can use a standalone managed service account (sMSA). An sMSA has the same functionality, but is intended for deployment on a single server.
If you can't use a gMSA or sMSA supported by your service, configure the service to run as a standard user account. Service and domain administrators are required to observe strong password management processes to help keep the account secure.
Assess gMSA security posture
gMSAs are more secure than standard user accounts, which require ongoing password management. However, consider gMSA scope of access in relation to security posture. Potential security issues and mitigations for using gMSAs are shown in the following table:
Security issue
Mitigation
gMSA is a member of privileged groups
- Review your group memberships. Create a PowerShell script to enumerate group memberships. Filter the resultant CSV file by gMSA file names - Remove the gMSA from privileged groups - Grant the gMSA rights and permissions it requires to run its service. See your service vendor.
gMSA has read/write access to sensitive resources
- Audit access to sensitive resources - Archive audit logs to a SIEM, such as Azure Log Analytics or Microsoft Sentinel - Remove unnecessary resource permissions if there's an unnecessary access level
Find gMSAs
Managed Service Accounts container
To work effectively, gMSAs must be in the Managed Service Accounts container in Active Directory Users and Computers.
To find service MSAs not in the list, run the following commands:
Get-ADServiceAccount -Filter *
# This PowerShell cmdlet returns managed service accounts (gMSAs and sMSAs). Differentiate by examining the ObjectClass attribute on returned accounts.
# For gMSA accounts, ObjectClass = msDS-GroupManagedServiceAccount
# For sMSA accounts, ObjectClass = msDS-ManagedServiceAccount
# To filter results to only gMSAs:
Get-ADServiceAccount –Filter * | where-object {$_.ObjectClass -eq "msDS-GroupManagedServiceAccount"}
Manage gMSAs
To manage gMSAs, use the following Active Directory PowerShell cmdlets:
gMSAs are a secure service account type for on-premises. It's recommended you use gMSAs, if possible. In addition, consider moving your services to Azure and your service accounts to Microsoft Entra ID.
Protect your Active Directory environment by securing user accounts to least privilege and placing them in the Protected Users group. Learn how to limit authentication scope and remediate potentially insecure accounts.
Learn how to create a Microsoft Key Distribution Service (kdssvc.dll) root key on the domain controller using Windows PowerShell to generate group Managed Service Account passwords in Windows Server 2012 or later.