Overview

The below process is run only once, before starting to use gMSAs.

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.

1. On a Windows Server 2012 or later domain controller, run the Windows PowerShell from the Taskbar.

2. 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>;

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 delegation

  PowerShellCopy

  Set-ADAccountControl -Identity TestgMSA$ -TrustedForDelegation $false -TrustedToAuthForDelegation $false Set-ADServiceAccount -Identity TestgMSA$ -Clear 'msDS-AllowedToDelegateTo'

• Unconstrained Delegation/Trust This Computer for Delegation to any service

  PowerShellCopy

  Set-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)

  PowerShellCopy

  Set-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)

  PowerShellCopy

  Set-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.

Remember to test before if the application you want to use the gMSA for supports this type of account.

Removing a gMSA

You can remove it by simply right clicking and deleting the gMSA.

To remove the cache from the servers the running the following PowerShell command:

Uninstall-ADServiceAccount <ADServiceAccount>

Configuring a Scheduled Task

We can use PowerShell for this. Below is an example that you can adapt to your own requirements:

$action = New-ScheduledTaskAction -Execute "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -Argument "-File 'D:\Utils\Powershell\Stale_Objects\Disable_move_comps.ps1'"

$action = New-ScheduledTaskAction -Execute "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -Argument "-File 'D:\Utils\Powershell\Stale_Objects\Save_comps_to_file.ps1'"
$trigger = New-ScheduledTaskTrigger -At '2:10am' -Weekly -DaysOfWeek Saturday
$principal = New-ScheduledTaskPrincipal -UserID "Travix\Disable&MoveSVC$" -LogonType Password -RunLevel Highest

# Uncheck if you want to modify an existing task. Comment the Register-ScheduledTask command next.
#Set-ScheduledTask -TaskName "EPICS - Stale Computer Objects" –Action $action –Trigger $trigger –Principal $principal 

# Comment if you don't want to create a new one but use instead an existing task.
Register-ScheduledTask -TaskName "EPICS - Stale Computer Objects List" -Description '08-04-2024 Marius: Migrated from BEGCP1ADC01. https://travix.atlassian.net/browse/EPICS-687' –Action $action –Trigger $trigger –Principal $principal

If you are using the GUI to configure the task, the first time you create it if you set the gMSA and don’t set a password it will let you create it. However, if you try to edit it, it might ask you to input the password and won’t let you bypass that anymore, therefore, make sure you create it right from the beginning.

References

Group Managed Service Accounts Overview

Get started with Group Managed Service Accounts

Create the Key Distribution Services KDS Root Key