How to Group Managed Service Accounts (gMSA)

Note: The article focuses on Group Managed Service Accounts, but many aspects also apply to the older (Standalone) Managed Service Accounts.

Brief Guide to Creating and Using gMSA

The article is not very long, but if you're only looking for basic practical steps, they are listed in this section. If you're interested in more details, you can find them later in the article.

Creating a gMSA Account in Active Directory

New-ADServiceAccount -Name MSA-service1 -DNSHostName service1.company.local -PrincipalsAllowedToRetrieveManagedPassword server1$ `
-KerberosEncryptionType AES128, AES256

Installing gMSA on a Server with Admin Rights

# if you need to install the AD PowerShell module
Install-WindowsFeature RSAT-AD-PowerShell -IncludeAllSubFeature
# testing the use of gMSA on the server before installation
Test-ADServiceAccount -Identity MSA-service1
# installing the account on the server
Install-ADServiceAccount -Identity MSA-service1

Configuring gMSA for a Scheduled Task

An example of using a gMSA for a Scheduled Task where we change the account for an existing task.

$Principal = New-ScheduledTaskPrincipal -UserID company\MSA-service1$ -LogonType Password -RunLevel Highest
Set-ScheduledTask -TaskName "My Script" -Principal $Principal 

Service Accounts

Applications and services often need an identity to authenticate with other resources (e.g., connecting to the network as a specific user). For this, service accounts are used. To simplify management and improve security, we can utilize Managed Service Accounts. The application or service must support this type of account.

In practice, we often use various scripts that we schedule to run regularly as Scheduled Tasks. Many of them cannot run under the SYSTEM account because they require special permissions. Therefore, we need to create a service account under which they will run. Ideally, each task should have its own account. This situation can be simplified and made more secure using Managed Service Accounts. A similar situation applies to certain special services that require permissions on the network.

Official Documentation

• Group Managed Service Accounts Overview
• Secure group managed service accounts
• Create a group managed service account (gMSA) in Microsoft Entra Domain Services

Managed Service Accounts (MSA)

• Supported since Windows Server 2008 R2.

Standalone Managed Service Accounts (sMSA), originally just Managed Service Accounts (MSA), are domain-managed accounts that provide automatic password management. They simplify SPN management and allow delegated management to other administrators. There's no need to manually create login credentials or change passwords. The account can be used on only one server (it is tied to a specific machine).

Group Managed Service Accounts (gMSA)

• Supported since Windows Server 2012. The Active Directory (AD) domain and forest functional level must be at least Windows Server 2012.

Group Managed Service Accounts (gMSA) provide the same functionality as MSA but extend usage to multiple servers. In load-balanced solutions, or more generally in server farm services, all instances of the service must use the same account (principal). gMSA handles password synchronization between service instances. Failover clusters do not support gMSA, but services running on them may support it.

Group Managed Service Accounts are the successor to (Standalone) Managed Service Accounts. Microsoft recommends primarily using gMSA. If they don't work (are not supported), then try sMSA. If neither is successful, then use a standard (service) user account.

Note: Windows Server 2025 introduces a new feature called Delegated Managed Service Account (dMSA), which addresses some security shortcomings of gMSA.

Main Features of gMSA

• Strong Passwords - Uses randomly generated complex passwords, 240 bytes long
• Regular Password Changes - Password management is handled by Windows OS, with passwords changing every 30 days (or as configured)
• Supports Server Farms - Can be used on multiple servers running the same service
• Cannot perform interactive logon
• Uses Kerberos; accounts cannot be locked and are not subject to password policies

Note: If I understand some comments correctly, the difference between gMSA and sMSA lies in password management. sMSA uses the same method as a password change on a computer account.

Managed Service Accounts Can Be Used For

• Windows Service
• Scheduled Task
• IIS Application Pool (App Pool)
• Applications that support MSA (e.g., Veeam Backup & Replication)

More Details on Managed Service Accounts

• MSA has the object class msDS-ManagedServiceAccount
• gMSA has the object class msDS-GroupManagedServiceAccount
• Accounts are created by default in the container CN=Managed Service Accounts, DC=<domain>, DC=<tld>; Microsoft recommends keeping them there
• Created and managed only via PowerShell
• Active Directory Users and Computers allows only viewing (Advanced Features must be enabled)
• Uses Microsoft Key Distribution Service (kdssvc.dll) on the domain controller (DC)
  • Enables secure retrieval of the latest or specific key ID for the AD account
  • Keys are regularly changed
  • The domain controller calculates the password based on the key
  • Member computers can retrieve the password from the DC

Deploying Group Managed Service Accounts

General Steps for Account Configuration

• (Only needed the first time) Create the KDS Root Key
• Create gMSA in AD, specifying the servers that can use it
• Install gMSA on the server
• Configure the service/task/application on the server to use gMSA
• Verify that the service/task/application works under the gMSA identity

Note: If you want to use the account on multiple computers, it's best to create a Security Group and add the computer accounts that can retrieve the gMSA account password to it.

Creating the KDS Root Key

• Create the Key Distribution Services KDS Root Key

To allow the domain controller (DC) to generate gMSA passwords, the Key Distribution Services (KDS) requires a Root Key. For proper functioning, it must be replicated to all DCs. Typically, you can create a gMSA account 10 hours after creating the key (to ensure replication).

Checking if KDS Root Key Exists

We can use the MMC Snap-In Active Directory Sites and Services. The keys are located under Services - Group Key Distribution Service - Master Root Keys.

Alternatively, we can use the PowerShell cmdlet to list the existing keys:

Get-KdsRootKey

Generating a New KDS Root Key

We can generate a new KDS Root Key using the PowerShell cmdlet. The Key Distribution Service must be running.

Add-KdsRootKey -EffectiveImmediately

Deleting a KDS Root Key

The PowerShell cmdlet documentation for KDS does not include a cmdlet for deleting a KDS Root Key. However, if we use Active Directory Sites and Services, we can easily delete the keys (like other objects).

Creating and Managing Managed Service Accounts

To create an account, use the PowerShell cmdlet New-ADServiceAccount. For additional operations, use Get-ADServiceAccount, Set-ADServiceAccount, Test-ADServiceAccount, or Remove-ADServiceAccount.

Creating Standalone Managed Service Accounts (sMSA)

New-ADServiceAccount -Name Service-sMSA -RestrictToSingleComputer
Add-ADComputerServiceAccount -Identity server -ServiceAccount Service-sMSA

Creating Group Managed Service Accounts (gMSA)

New-ADServiceAccount -Name Service-gMSA -DNSHostName service.company.local -PrincipalsAllowedToRetrieveManagedPassword server$ `
 -KerberosEncryptionType AES128, AES256

• Name - The name of the account being created, up to 15 characters (limited by samAccountName), which restricts the possibility of a descriptive name like MSA-servername-service-name.
• DNSHostName - The DNS name of the service (FQDN). This is a required parameter, but it only matters for services using Kerberos (there is no clear explanation of its significance and usage, and multiple accounts can share the same DNSHostName).
• PrincipalsAllowedToRetrieveManagedPassword - Specifies the computer(s) that can use the gMSA. You can specify computer names (with $ at the end, representing sAMAccountName) separated by commas, or a security group containing their accounts.
• KerberosEncryptionType - Defines the allowed encryption types for Kerberos (RC4 should not be used today, see Kerberos RC4 Deactivation).
• ServicePrincipalNames - Specifies the SPN for the account if we want to define them manually.
• ManagedPasswordIntervalInDays - If you want the password to change after a different number of days than the default 30, this can only be set during creation.
• Description - You can provide a description for the account.

Changing gMSA Settings

Set-ADServiceAccount -Identity Service-gMSA -PrincipalsAllowedToRetrieveManagedPassword server1$,server2$

Listing and Retrieving Information on Managed Service Accounts

Get-ADServiceAccount -Filter *
Get-ADServiceAccount Service-gMSA -Properties * | Select-Object *

Deleting a Managed Service Account

Remove-ADServiceAccount -Identity Service-gMSA

Testing a Managed Service Account

On a computer that is authorized to use the gMSA, you can test its functionality (authentication). The account does not need to be installed on the computer (although some articles suggest otherwise).

Test-ADServiceAccount -Identity Service-gMSA

If the sMSA account is not assigned to any computer, you will receive the following error:

WARNING: The Managed Service Account Service-sMSA is not linked with any computer object in the directory.

If you run the test on a computer different from the one assigned to the account, you will get an error:

WARNING: Test failed for Managed Service Account Service-gMSA. If standalone Managed Service Account, the account is linked to 
another computer object in the Active Directory. If group Managed Service Account, either this computer does not have permission 
to use the group MSA or this computer does not support all the Kerberos encryption types required for the gMSA. See the MSA 
operational log for more information.

Installing a Managed Service Account on a Server

To use an MSA account on the server, you need to install/cache it (in practice, the account may work without installation, but there could be issues with password changes). Use the PowerShell cmdlet Install-ADServiceAccount and Uninstall-ADServiceAccount.

If the server does not have the Remote Server Administration Tools for AD DS (only the Active Directory module for Windows PowerShell is required), you must install them first (either the PowerShell module or the entire AD DS Tools).

Install-WindowsFeature RSAT-AD-PowerShell -IncludeAllSubFeature
Install-WindowsFeature RSAT-ADDS -IncludeAllSubFeature

Installing an MSA

The installation is performed locally on the computer. The cmdlet checks if the computer can host the given account (if something fails, it returns a general error; you can use the Test cmdlet). It makes the necessary local modifications so that the password can be managed.

Install-ADServiceAccount -Identity Service-gMSA

Uninstalling a Managed Service Account

Uninstall-ADServiceAccount Service-gMSA

Adding the Account to a Group

To ensure that a service/task runs correctly, the MSA account often needs certain permissions. These permissions can be set on the file system, by adding it to Active Directory domain groups, or by adding it to a local group. The latter can be done locally on the server, either through the GUI or PowerShell.

Add-LocalGroupMember -Group "Administrators" -Member Service-gMSA$

Using Managed Service Accounts

The MSA account name is specified with a dollar sign at the end, just like for a computer account. This is its sAMAccountName (NetBIOS name instead of FQDN). For example, Service-gMSA$. You may sometimes need to include the domain, like COMPANY\Service-gMSA$ (NetBIOS Logon Name).

Running a Command as an MSA Account

When you want to test (or troubleshoot) a script or application that will run under an MSA account (e.g., in a scheduled task), it helps to use RunAs. This would involve running, for example, a command prompt (cmd.exe) or PowerShell under another account to see outputs, errors, and behavior. However, this doesn't work for MSA accounts. Instead, you can use PsExec.

PsExec64.exe -i -u company\Service-gMSA$ -p ~ cmd.exe

MSA for Windows Service

The account needs Log on as a service permissions. If it is in the local Administrators group, it already has these rights. Otherwise, you can use Group Policy or Local Security Policy (secpol.msc). Add the account to the Log on as a service policy. This setting is found under [Computer Configuration/Windows Settings/]Security Settings/Local Policies/User Rights Assignment.

In the service properties on the Log On tab, select This account and find/enter the account. Leave the Password field blank.

MSA for Scheduled Task

The account needs Log on as a batch job permissions, which can be set similarly to the previous point.

The Task Scheduler GUI does not support specifying MSA as an account for running a task (nor does it offer it). Therefore, you must use PowerShell. You can create the entire task using PowerShell or create it first in Task Scheduler and then modify the account for running it.

$Principal = New-ScheduledTaskPrincipal -UserID "company\Service-gMSA$" -LogonType Password -RunLevel Highest
Set-ScheduledTask -TaskName "CDR" -TaskPath "\SCSM\" -Principal $Principal

You can then view the task in Task Scheduler, but it cannot be edited (saving shows an unknown account error).

Note: Permission issues can be complex. It seems that, in certain situations, the account also needs Log on as a service permissions for the task to run. If it does not have them, the event Event ID 101 Task Start Failed will be logged with an error Error Value: 2147943785.

Send-MailMessage and net_io_connectionclosed Error

I encountered a problem where a PowerShell script running in a scheduled task tries to send an email without authentication. It works under a standard user, but fails under Managed Service Accounts, with the Send-MailMessage cmdlet returning the error:

Send-MailMessage : Unable to read data from the transport connection: net_io_connectionclosed.

After some time, I found a functional solution in a discussion. You need to explicitly specify anonymous sending.

$cred = New-Object PSCredential -ArgumentList "NT AUTHORITY\ANONYMOUS LOGON",(ConvertTo-SecureString -AsPlainText -Force -String "anon")
Send-MailMessage  -Credential $cred