Set up Group Managed Service Accounts (gMSA) vs. Standalone Managed Service Accounts (sMSA)

Today we want to set up and pay attention to Group Managed Service Accounts (gMSA) who was introduced in Windows Server 2012 and Windows 8.

gMSA’s are specific user accounts in Active Directory and extends the successor Standalone Managed Service Accounts (sMSA).

A great documentation with technical background and details about sMSA you will find below.

Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting
https://docs.microsoft.com/en-us/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting

Since Windows Server 2012, the Windows PowerShell cmdlets default to managing the group Managed Service Accounts instead of the server Managed Service Accounts.

Force to create a Standalone Managed Service Account (sMSA) in Windows Server 2012 and later.

The New-ADServiceAccount cmdlet creates a new Active Directory managed service account. By default, the cmdlet creates a group managed service account. To create a standalone managed service account which is linked to a specific computer, use the RestrictToSingleComputer parameter.

https://docs.microsoft.com/en-us/powershell/module/addsadministration/new-adserviceaccount?view=win10-ps#description

The Group in Group Managed Service Account (gMSA) stands for the ability to assign one gMSA to a group of computers. The sMSA instead is tied to a single computer.

Create the Key Distribution Services KDS Root Key

First we have to create a KDS Root Key!

Domain Controllers (DC) require a root key to begin generating gMSA passwords.

https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key

The domain controllers will wait up to 10 hours from time of creation to allow all domain controllers to converge their AD replication before allowing the creation of a gMSA. The 10 hours is a safety measure to prevent password generation from occurring before all DCs in the environment are capable of answering gMSA requests. If you try to use a gMSA too soon the key might not have been replicated to all domain controllers and therefore password retrieval might fail when the gMSA host attempts to retrieve the password. gMSA password retrieval failures can also occur when using DCs with limited replication schedules or if there is a replication issue.

Note
Deleting and recreating the root key may lead to issues where the old key continues to be used after deletion due to caching of the key. The Key Distribution Service (KDC) should be restarted on all domain controllers if the root key is recreated.

To check if a KDS Root Key already exists use the following cmdlet

Get-KdsRootKey

In my lab environment already one exists.

In a new environment if no key already exists you can create one with the following cmdlet

Add-KdsRootKey -EffectiveImmediately

Create and configure gMSA

We can now create our first gMSA account with the PowerShell on a domain controller.

New-ADServiceAccount -Name <name> -DNSHostName <FQDN for the Service Account created> -PrincipalsAllowedToRetrieveManagedPassword <Group of servers that can use a group managed service account> -ManagedPasswordIntervalInDays <Specifies the number of days for the password change interval>

New-ADServiceAccount -Name svcSQL-MSA -DNSHostName svcSQL-MSA.braintesting.de -PrincipalsAllowedToDelegateToAccount “gMSA” -ManagedPasswordIntervalInDays 30

In order to run the command above successfully, we first need to create a security group in which we insert all computers the gMSA will be later assigned to and therefore are able to retrieve the managed password.

The following article refers to standalone Managed Service Accounts (sMSA’s), but the inheritance from the object class is nearly the same except the msDS-ManagedServiceAccount object class is changed into msDS-GroupManagedServiceAccount.

https://docs.microsoft.com/en-us/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting#how-managed-service-accounts-work

The object is a user and a computer at the same time, just like a computer account. But it does not have an object class of person like a computer account typically would; instead it has msDS-GroupManagedServiceAccount. gMSA’s inherit from a parent object class of “Computer”, but they are also users. 

Meanwhile since Windows Server 2012 it also inherits from the object class person, you will it below at creating a sMSA.

From now on we can assign the gMSA to our SQL Server, but if not already done, after adding the server to the security group as mentioned above, we need to restart the server in order that his group membership will be refereshed.

To assign the gMSA, run the following cmdlet on the server you want to use the account, in my case my SQL Server.

Install-AdServiceAccount -Identitiy svcSQL-MSA
Test-AdServiceAccount svcSQL-MSA

Associate the new gMSA with your service

Start services.msc
Edit your service properties.
On the Log On tab, set This Account to the domainname$ of your gMSA
Remove all information from Password and Confirm password – they should not contain any data

Also you can search for the gMSA in your Active Directory, you don’t need to suffix the account with $, it will append automatically.

Create a standalone Managed Service Account (sMSA)

As mentioned above, since Windows Server 2012, the PowerShell cmdlet New-ADServiceAccount, creates by default a group managed service account (gMSA).

With the parameter RestrictToSingleComputer we can force the creation of a standalone managed service account (sMSA) as follows.

New-ADServiceAccount -Name svcSQL-sMSA -RestrictToSingleComputer -Enabled $true

You can see under Type in the Active Directory Users and Computers console, that now our sMSA is inherited from the object class msDS-ManagedServiceAccount instead above for gMSA’s from msDS-GroupManagedServiceAccount.

But as you can see both managed service account types, sMSA’s and gMSA’s will inherited from the computer and user object class. So they will be a user and computer object at the same time, just like a computer account.

sMSA

gMSA

Standalone Managed Service Accounts (sMSA’s)

Managed Service Accounts: Understanding, Implementing, Best Practices, and Troubleshooting
https://docs.microsoft.com/en-us/archive/blogs/askds/managed-service-accounts-understanding-implementing-best-practices-and-troubleshooting

Parameter for creating managed service accounts

New-ADServiceAccount

https://docs.microsoft.com/en-us/powershell/module/addsadministration/new-adserviceaccount?view=win10-ps#description

To create a group managed service account which can only be used in client roles, use the RestrictToOutboundAuthenticationOnly parameter.
This creates a group managed service account that can be used for outbound connections only and any attempts to connect to services using this account will fail because the account does not have enough information for authentication. 

The Path parameter specifies the container or organizational unit (OU) for the new managed service account object. When you do not specify the Path parameter, the cmdlet creates an object in the default managed service accounts container for managed service account objects in the domain.

Troubleshoot

If you receive an error message stating that Cannot install service account. An unspecified error has occurre, Mostly the reason is that the computer account is missing in the PrincipalsAllowedToRetrieveManagedPassword parameter.

You can check this with the following cmdlets

Get-ADServiceAccount svcSQL-MSA -Properties * | fl

Get-ADServiceAccount svcSQL-MSA -Properties msDS-GroupMsaMembership | Select -Expand msDS-GroupMsaMembership | Select -Expand Access | Select -Expand IdentityReference

To Update the principals in the PrincipalsAllowedToRetrieveManagedPassword parameter run the following cmdlet

Get-ADServiceAccount svcSQL-MSA | Set-ADServiceAccount -PrincipalsAllowedToRetrieveManagedPassword ‘gMSA’, ‘SQL$’

For the principals, I use here my security group and the hostname of my SQL Server optional and is not necessary. Only to show that you can use both principal types. In case of the hostname you must add the suffix $, otherwise you will get an error that the object cannot be found.

Compatibility with user accounts ending with the dollar sign ($)
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/compatibility-user-accounts-end-dollar-sign

Starting in Windows 7/2008R2, there are potential compatibility issues with using domain user accounts ending with the dollar sign ($) as a service account. Managed service accounts are identified by ending in a dollar sign ($). The system may evaluate the account as a managed service account and block the change.

Links

Group Managed Service Accounts Overview
https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview

Getting Started with Group Managed Service Accounts
https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts

Create the Key Distribution Services KDS Root Key
https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key

What’s New for Managed Service Accounts
https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/what-s-new-for-managed-service-accounts

Compatibility with user accounts ending with the dollar sign ($)
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/compatibility-user-accounts-end-dollar-sign