Configuring Managed Service Accounts in Active Directory

1K

In Active Directory, Managed Service Accounts (MSAs) are a special type of account used to run Windows services, background apps, and scheduled tasks. MSA account passwords are managed automatically by Active Directory. They are complex and randomly generated, and cannot be used for interactive sign-ins.

This article covers the following topics:

• basic types of managed accounts in AD
• generating Key Distribution Services Root Key
• creating MSA accounts
• configuring the service and task scheduler in Windows Server to run under a managed account

Types of Managed Service Accounts in Active Directory

Key Benefits of Managed Service Accounts

• Simplify the management of service accounts within the AD domain.
• Automated password management: Active Directory randomly generates complex, 240-byte passwords and changes them without any intervention from the administrator.
• Increased security: AD securely generates and maintains the managed password. Authorized machines retrieve the current password through the Netlogon service when required. By default, passwords are changed every 30 days. When applications require a password, they query the Active Directory, so you don’t even have to know the password.
• Uses Kerberos: these accounts cannot be locked, and are not subject to domain password policies.
• Multiple host support (gMSA) – allow a single service account to be used across multiple servers running the same service. This includes server farms, clusters, and load balancers.

Types of service account supported in Active Directory

The following types of service account are supported in Active Directory, depending on the domain functional level:

Service Account Types	Minimum Requirements	Features
sMSA (Standalone Managed Service Account)	At least Windows Server 2008 R2	Can only be used on a single server for IIS site/app isolation of individual services.
gMSA (Group Managed Service Account)	At least Windows Server 2012	Used to run services on multiple clusters or NLB servers, or on multiple member servers, simultaneously.
dMSA (Delegated Managed Service Account)	Requires at least one Windows Server 2025 domain controller	Authentication is strongly tied to the host device identity. This reduces the risk of credential theft and service account abuse.Authentication is handled via the device’s identity and the Local Security Authority, rather than by the service providing the password.

dMSA Migration Scenarios

Delegated Managed Service Accounts (dMSA), introduced in Windows Server 2025, are designed to simplify the migration from traditional service accounts to managed identities.

Unlike sMSA and gMSA, dMSA does not introduce a new AD domain functional level requirement. Instead, the feature requires at least one Windows Server 2025 domain controller in the domain.

Unlike gMSA, you can use dMSA in migration cases where existing services already run under standard domain user accounts. This helps you to reduce the operational overhead of password management and lowers the risk of credential theft.

Note. One of the primary use cases for dMSA in Windows Server 2025 is migrating existing services from traditional domain service accounts to managed identities with automated credential management.

Basic MSA implementation procedure

A basic MSA implementation procedure in AD might look like this:

• Create the KDS Root Key (only needed the first time)
• Create a gMSA in the Active Directory and specify the hosts that can use it.
• Install gMSA on the target Windows Server host
• Configure the service, task, or app on the server to use gMSA.

Creating Key Distribution Services (KDS) Root Key

The Key Distribution Service (KDS) on Active Directory domain controllers generates and manages passwords for gMSA accounts. This allows multiple Windows servers to use the same gMSA account, the password for which is only accessible to a specific list of domain computer accounts.

Prerequisites

• Active Directory PowerShell module
• Domain functional level Windows Server 2012/later (for gMSA)
• KDS Root Key
• Windows Server member machine
• Time sync working correctly

Before using MSA within a domain, a Key Distribution Services (KDS) Root Key must be generated. This is a one-time procedure for a domain.

Check if the KDS root key has already been created:

Get-KdsRootKey

If the command returns a key ID, you’re done. Otherwise, you need to create a KDS root key:

Add-KdsRootKey -EffectiveImmediately

Despite the parameter name, the KDS root key is not immediately usable across the domain. We recommend you to wait for normal AD replication to complete before creating production gMSAs. The KDS key will be created and ready to use within 10 hours of replication between the DCs.

You can use the following command in lab/isolated test environments:

Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Use the Active Directory Sites and Services console (Services > Group Key Distribution Service > Master Root Key), or the following command to check that the KDS root key exists:

Test-KdsRootKey -KeyId (Get-KdsRootKey).KeyId

Important. The KDS Root Key is a critical AD object used to generate gMSA passwords throughout the domain. You should not remove existing KDS Root Keys unless specifically instructed by Microsoft support or as part of a documented recovery procedure. The key is stored in AD and protected by normal AD backup and recovery processes. You need to ensure that Active Directory DCs are regularly backed up.

Creating gMSA Accounts in Active Directory

MSA accounts can be created in Active Directory using PowerShell. I will create a new Managed Service Account group called gmsa_corpHQ that can be used on three Windows Server hosts in the domain:

$gMSA = 'gmsa_corpHQ'

$gMSA_Hosts = 'srv01$', 'srv02$', 'srv03$'

Next, let’s create a new security group, and add the target server accounts to it:

$gMSA_Group=New-ADGroup -Name "$($gMSA)_Group" -GroupScope Global -PassThru

$gMSA_Hosts | ForEach-Object { Add-ADGroupMember -Identity $gMSA_Group -Members $_ }

The new gMSA account can now be created:

New-ADServiceAccount -Name $gMSA -DNSHostName "$($gMSA).$($env:USERDNSDOMAIN)" -PrincipalsAllowedToRetrieveManagedPassword $gMSA_Group

This command will create a new gMSA account and grant members of the gmsa_corpHQ_Group access to the account’s password in AD.

In multi-domain AD forests, you can also use gMSA accounts in more complex enterprise scenarios involving servers located in different domains. In large AD environments, you should review the latest Microsoft guidance for gMSA deployment (including requirements for domain and forest functional levels, KDS Root Key configuration, Kerberos, and SPN management).

By default, MSAs are created in the Managed Service Accounts container (to show them, you need to enable the Advanced Features option in the ADUC console).

The screenshot below shows that a new msDSGroupManagedServiceAccount object has been successfully created.

List all managed service accounts in AD:

Get-ADServiceAccount -Filter *

Auditing Servers Allowed to Retrieve gMSA Passwords

You should regularly review which servers are allowed to retrieve gMSA passwords. You need to remove decommissioned hosts and check that only authorized computers remain in the approved access list.

In order to view the principals assigned to a specific gMSA account, run the command:

Get-ADServiceAccount gmsa_corpHQ `
-Properties PrincipalsAllowedToRetrieveManagedPassword |
Select-Object -ExpandProperty PrincipalsAllowedToRetrieveManagedPassword

If a security group is used, review its current members using command:

Get-ADGroupMember gmsa_corpHQ_Group

In order to audit all gMSA accounts in the domain, use the following command:

Get-ADServiceAccount -Filter * `
-Properties PrincipalsAllowedToRetrieveManagedPassword |
Select-Object Name, PrincipalsAllowedToRetrieveManagedPassword

Note. You should review these permissions regularly as part of security audits and remove obsolete computer accounts from the approved host list.

How to Install Managed Service Account on Windows Server

The next step is to install the MSA account on the server on which it will be used (this requires the RSAT-AD-PowerShell module to be installed):

# If the AD PowerShell module is not installed
Install-WindowsFeature RSAT-AD-PowerShell

Install-ADServiceAccount -Identity gmsa_corpHQ

Note that some Kerberos-enabled apps may require SPN registration when using gMSA accounts.

In order to check if a gMSA already has any Service Principal Names (SPNs) registered, run the command:

Get-ADServiceAccount gmsa_corpHQ -Properties ServicePrincipalNames |
Select-Object -ExpandProperty ServicePrincipalNames

Some apps (such as SQL Server, IIS, or custom Kerberos-enabled services) may require additional SPNs to be registered manually. You should refer to the app’s documentation before modifying SPNs.

Retrieve MSA account credentials from AD

Check that the account has been installed and can retrieve its credentials from AD:

Test-ADServiceAccount gmsa_corpHQ

In case you get True in output, then the account can retrieve credentials.

If you see False in the output, you should verify the following:

• host is in PrincipalsAllowedToRetrieveManagedPassword
• AD replication completed
• KDS root key exists
• account is installed locally

Configure the target Windows services

Next, configure the target Windows services to run under an MSA account:

1. Open the Services Management snap-in (services.msc)
2. Open the target service’s properties and go to the Log on the tab.
3. Select the This account option and enter the MSA account in the format DOMAIN\gmsa_corpHQ$ (the $ sign at the end is required). Leave the password blank

   

4. Restart the service and it should now be running using the gMSA account.

The specification of MSA is not supported by the Task Scheduler GUI, so the task must be created manually. Use the following PowerShell script to configure the Task Scheduler job to run under the gMSA account (first, grant the account Log on as a batch job permissions). Note that if the scheduled task already exists, you can reconfigure it to run under a gMSA account:

$Principal = New-ScheduledTaskPrincipal -UserID "THEITBROS\gmsa_corpHQ$" -LogonType Password -RunLevel Highest

Set-ScheduledTask -TaskName "MSA_TASK1" -Principal $Principal

The Password logon type is required even though no password is specified for a gMSA.

To remove an MSA account from the host:

Uninstall-ADServiceAccount gmsa_corpHQ

Therefore, managed service accounts simplify and enhance the security of using service accounts to run services in Active Directory.