Active Directory – Standalone Managed Service Accounts and Group Managed Service Accounts

Managed Service Accounts (MSA) introduced in Server 2008 R2 helps reduce risk of system accounts running services being compromised.

Table of Contents

Managed Service Accounts and its benefits

Standalone managed service accounts (sMSAs) are managed domain accounts that we use to help secure one or more services that run on a server. They can’t be reused across multiple servers. sMSAs provide automatic password management, simplified service principal name (SPN) management, and the ability to delegate management to other administrators.

Windows Server 2012 introduced Group Managed Service Accounts (gMSAs) to over the limitation in sMSA as it can only be used on one server and not in cluster and NLB services.

Group managed service accounts (gMSAs) can run on a single server or on a server farm, such as systems behind a network load balancing or Internet Information Services (IIS) server. The Group in Group Managed Service Account stands for the ability to assign one gMSA to a group of computers.

Both sMSAs and gMSAs,

Set strong passwords – Use 240-byte, randomly generated complex passwords
- Minimizing the likelihood of a service getting compromised by brute force or dictionary attacks
Cycle password regularly – Windows automatically changes the password every 30 days
- Eliminating the need of scheduling password changes and minimizing downtime
Support simplified service principal name (SPN) management

Setup and Configure MSAs

Below I’ll go through steps on how to setup sMSAs and gMSAs in an AD environment.

Create the Key Distribution Services Root Key

Domain Controllers (DC) require a root key before we can start creating sMSA or gMSA accounts. A one-time operation has to be performed to create a KDS root key.

The DCs will wait up to 10 hours from time of creation to allow all DCs to converge their AD replication before allowing the creation of a sMSA or gMSA. The 10 hours is a safety measure to prevent password generation from occurring before all DCs in the environment are capable of answering sMSA/gMSA requests.

Run the following PowerShell command on the domain controller:

Add-KdsRootKey –EffectiveImmediately

For test environments with only one DC, to use the key immediately in the test environment, you can run this command:

Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

To make sure the KDS root key was successfully created and to successfully test it, use the following cmdlets,

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

Can also be validated with a 4004 event has been logged in the KdsSvc (Applications and Services Logs –> Microsoft-Windows-KdsSvc/Operational) event log,

objectClass difference between a sMSA and gMSA in AD,

Create and Install a standalone Managed Service Account (sMSA)

To create a new enabled sMSA account in AD, use the below cmdlet,

$msaName = Read-Host "Enter name of desired MSA name"
New-ADServiceAccount -Name "$msaName" -Enabled $True -RestrictToSingleComputer

To link the newly created sMSA to a computer/server.

Note: In my case I’m using the same PS session and I have cleared variables. Hence I’m reusing the ‘$msaName’ variable. The server/computer name in my scenario is SERVER-01. You’ll have to modify it accordingly.

$Server = Get-ADComputer -identity SERVER-01
Add-ADComputerServiceAccount -Identity $Server -ServiceAccount $msaName

sMSA and gMSA are created in the container CN=Managed Service Accounts by default

Use below cmdlet to get properties to the sMSA

Get-ADServiceAccount msaServer-01

To use MSA / gMSA on target servers or workstations, you first need to install the AD PS module. Run the below cmdlet in PS run as administrator:

Add-WindowsFeature RSAT-AD-PowerShell

On the target server where the service account needs to be installed and use the below cmdlets to install the account and test it,

$Account = Get-ADServiceAccount -Filter "Name -eq 'msaServer-01'"
Install-ADServiceAccount $Account

Test-AdServiceAccount msaServer-01

Create and Install a group Managed Service Account (gMSA)

As mentioned earlier in this post, gMSAs are only available to Windows Server 2012 or later versions.
Before getting started:

Ensure your forest schema is updated to Windows Server 2012
Make sure you have deployed a master root key for AD

Before creating the gMSA account, create a domain security group and add servers that will be allowed to use the password for this gMSA. I used the console to create a group but PS is another way to go.

To create a gMSA, use the command:

Note: The service account samAccountName attribute must not be longer than 15 characters.

New-ADServiceAccount -name gmsaSQLService1 -Enabled:$true -DNSHostName gmsaSQLService1.acloudguy.com -PrincipalsAllowedToRetrieveManagedPassword SQLServers –verbose

On the target server where the gMSA needs to be installed and use the below cmdlets to install the account and test it,

$Account = Get-ADServiceAccount -Filter "Name -eq 'gmsaSQLService1'"
Install-ADServiceAccount $Account

Test-AdServiceAccount gmsaSQLService1

To change a gMSA’s allowed servers, use the below cmdlet:

Set-ADServiceAccount -Identity gmsaSQLService1 -PrincipalsAllowedToRetrieveManagedPassword 'New-SQLServers' –verbose

Associate gMSA in application/service

In my scenario, I’m using the newly created gMSA in an SQL server configuration. Add a $ at end of the account which specifies the account is a ‘Service Account’. Don’t specify any password. Make sure to select the ‘Service Account’ object type.

Open SQL Server Configuration Manager
Select SQL Server Services, right-click the service and select Properties
Select the Log On tab
Click Yes when prompted to restart the service

When to use

Use sMSAs when there are one or more services deployed to a single server and gMSA can’t be used. Check with the application vendor to determine if sMSA is supported. If they can’t, you must test the application in a test environment. Although one sMSAs can be used for more than one service, it is recommended that each service have its own identity when it comes to auditing.

gMSAs should be the preferred type for on-premises services, as you can add servers to the AD group and makes it easier.

To run applications and services with gMSA, check vendor’s documentation to see if it is supported. Currently gMSA is supported in IIS, SQL Server, AD LDS, Exchange Server.

Issues you may encounter

sMSA can only be used on one computer/server. When you try to install it on a second server, you’ll get a warning prompt like in screenshot below,

‘Cannot install service account. Error Message: ‘{Access Denied}’ error when you install a gMSA to a server.

In my scenario, the server was not setup as ‘PrincipalsAllowedToRetrieveManagedPassword’. To determine which group is allowed to use the gMSA, use the below cmdlet:

Get-ADServiceAccount gmsaSQLService1 -properties * | Select Name, PrincipalsAllowedToRetrieveManagedPassword | fl

I added the SQL server to the ‘New-SQLServers’ AD group and run the cmdlets again to install the gMSA. I had to reboot the server for the membership to be updated.

Another similar issue you may face is the ‘The Service did not start due to a logon failure’. This is pretty much a follow-up of the previous error. Make sure the server object is in the group which can use the gMSA. And be sure to reboot the server.

Hope this post helped you get up and running with sMSA and gMSA in your environment.

Thank you for stopping by.✌