Configuring AD Group Managed Service Accounts (gMSA)

Overview

A standalone Managed Service Account (sMSA) is a managed domain account that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrators. This type of managed service account (MSA) was introduced in Windows Server 2008 R2 and Windows 7.

The group Managed Service Account (gMSA) provides the same functionality within the domain and also extends that functionality over multiple servers. When you connect to a service hosted on a server farm, such as a Network Load Balanced solution, the authentication protocols supporting mutual authentication require all instances of the services to use the same principal. When you use a gMSA as a service principal, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password.

The Microsoft Key Distribution Service (kdssvc.dll) lets you securely obtain the latest key or a specific key with a key identifier for an Active Directory account. The Key Distribution Service shares a secret that’s used to create keys for the account. These keys periodically change. For a gMSA, the domain controller computes the password on the key that the Key Distribution Services provides, along with other attributes of the gMSA. Member hosts can obtain the current and preceding password values by contacting a domain controller.

Note: Failover clusters don’t support gMSAs. However, services that run on top of the Cluster service can use a gMSA or a sMSA if they’re a Windows service, an app pool, a scheduled task, or natively support gMSA or sMSA.

Requirements

If you are faced with the following error in Windows PowerShell, it means that you need to Create the Key Distribution Services KDS Root Key.

New-ADServiceAccount : Key does not exist

Domain Admins or Enterprise Admins group membership, or equivalent, is the minimum required to complete this procedure.

Create the Key Distribution Services KDS Root Key

Domain Controllers (DC) require a root key to begin generating gMSA passwords. 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. Waiting up to 10 hours is a safety measure to prevent password generation from occurring before all DCs in the environment are capable of answering gMSA requests. Trying to use a gMSA too soon might fail when the gMSA host attempts to retrieve the password, as the key may not have been replicated to all domain controllers. gMSA password retrieval failures can also occur when using DCs with limited replication schedules or if there’s 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.

On a Windows Server 2012 or later domain controller, run the Windows PowerShell from the Taskbar.
At the command prompt for the Windows PowerShell Active Directory module, type the following commands, and then press ENTER:Add-KdsRootKey -EffectiveImmediately

Note: The parameter –EffectiveImmediately will add a root key to the target DC which will be used by the KDS service immediately. However, other domain controllers will not be able to use the root key until replication is successful.

You should see a Guid as output. For example:

KDS root keys are stored in Active Directory in container CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,CN=Configuration,DC=<forest name>;

INFO: They have an attribute msKds-DomainID that links to the computer account of the Domain Controller that created the object. When this domain controller is demoted and removed from the domain, the value will refer to the tombstone of the computer account. You can ignore the broken value as it is only used to help the administrator track the object when it’s freshly created. You may also change the attribute value and point it to the computer object of another domain controller in your forest.

Creating a new gMSA

Here is the command I am running for this experiment. You will need to update the values to reflect your environment.

New-ADServiceAccount WriteDescSVC -DNSHostName WriteDescSVC.example.com ` -PrincipalsAllowedToRetrieveManagedPassword SCCM$ ` -KerberosEncryptionType AES128, AES256 ` -ServicePrincipalNames http/SCCM.example.com/example.com, ` http/SCCM.example.com/example, ` http/SCCM/example.com, ` http/SCCM/example -Verbose

Now you should have it under CN=Managed Service Accounts,DC=yourDomain,DC=com.

Note: The password change interval (default is 30 days) can be changed using the -ManagedPasswordIntervalInDays -parameter. Changin this interval after creation is not supported, you will need to recreate the gMSA.

Configuring Kerberos delegation

To configure delegation for these special accounts, you need to set the correct attributes manually. There are two attributes that you need to modify for these accounts:

userAccountControl defines the type of delegation
msDS-AllowedToDelegateTo defines where the SPNs for delegation will be added

The more secure and convenient way is by using PowerShell commands to update those attributes. You don’t need to calculate final userAccountControl values when using PowerShell. Here are the commands to enable different types of delegation:

Do not trust this computer for delegationPowerShellCopySet-ADAccountControl -Identity TestgMSA$ -TrustedForDelegation $false -TrustedToAuthForDelegation $false Set-ADServiceAccount -Identity TestgMSA$ -Clear 'msDS-AllowedToDelegateTo'
Unconstrained Delegation/Trust This Computer for Delegation to any servicePowerShellCopySet-ADAccountControl -Identity TestgMSA$ -TrustedForDelegation $true -TrustedToAuthForDelegation $false Set-ADServiceAccount -Identity TestgMSA$ -Clear 'msDS-AllowedToDelegateTo'
Kerberos Constrained Delegation/Trust this computer for delegation to specified services only (Use Kerberos Only)PowerShellCopySet-ADAccountControl -Identity TestgMSA$ -TrustedForDelegation $false -TrustedToAuthForDelegation $false Update the Backend Service SPNs in msDS-AllowedToDelegateTo attribute.
Kerberos Constrained Delegation with Protocol Transition/Trust this computer for delegation to specified services only (Use Any Authentication Protocol)PowerShellCopySet-ADAccountControl -Identity TestgMSA$ -TrustedForDelegation $false -TrustedToAuthForDelegation $true Update the Backend Service SPNs in msDS-AllowedToDelegateTo attribute.

By default the userAccountControl will be as in the image and the msDS-AllowedToDelegateTo will be empty.