Microsoft Defender for Identity: Group Managed Service Account Setup

Recently I set up Microsoft Defender for Identity (formerly known as Azure ATP) with a requirement to use a group managed service account (gMSA). I wrote a blog about a year ago that detailed the setup for Defender for Identity, but I used a regular user account for the setup. That blog can be found here: Enable Azure ATP – (windowsmanagementexperts.com) 

This blog will focus on the steps necessary to configure this with a gMSA. During the setup, I encountered a few oddities that are not addressed directly in the Microsoft documentation. This blog is meant to compliment my previous blog.

For information about gMSA’s can be found here: https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview.

Gotcha #1: Configure Environment for gMSA

There is a prerequisite to creating a gMSA in your domain – you must have a KDS Root Key. This is used to securely retrieve the account password for gMSA. The KDS root key is only used for gMSA’s, so there is no harm in creating one in your environment if one does not already exist.

To check if you already have a KDS root key, follow these steps.

1. Launch Active Directory Sites and Services.
2. In the toolbar, select View and enable Show Services Node.

3. Expand Services, then Group Key Distribution Service, then Master Root Keys.

If this is blank (like the screenshot), you need to create a KDS Root Key. If you have a KDS root key listed here, you can skip to the next section.

To create the KDS root key, follow these steps. You will need to be a domain admin. I would also recommend running these steps from a domain controller.

1. Open Powershell as an administrator.
2. Run this command:

add-kdsrootkey -effectiveimmediately

This will create the KDS root key, and you will receive output from the PowerShell window with the key guid. You can verify that the key has been created by going back to Active Directory Sites and Services and refreshing the Master Root Keys window.

NOTE: This key, even though you specified the effectiveimmediately parameter, cannot actually be used for 10 hours. This is a built-in safeguard to make sure that the key is replicated to all domain controllers before use.

You can create the key in a way that it is valid immediately by running this command:

add-kdsrootkey -effectivetime ((get-date).addhours(-10))

Be careful with this command. If you only have one domain controller, or only a few on fast links, this will work fine. If you have geographically dispersed domain controllers that sometimes take time to replicate, do not use effectivetime. I would also go so far as to say to be absolutely sure, do not use effectivetime in any production environment.

Create gMSA

Now that our environment is ready, we need to create the gMSA. This is a fairly straightforward process and can be performed from any computer with the Active Directory Powershell module.

1. Launch PowerShell.
2. Run this command, substituting your gMSA account name and DNS hostname. The DNS hostname should be in the FQDN format.

new-adserviceaccount -name gMSA_DefenderId -dnshostname gMSA_DefenderId.contoso.local

This created the account, now we need to add the domain controllers to be able to read the password of the account. This can be done in two ways. First, you can create a group and add the computer objects for your domain controllers to it. You can use that group to assign access to the group. Replace identity with the name of your gMSA and principalsallowedtoretrievemanagedpassword with the name of your group.

set-adserviceaccount -identity gMSA_DefenderId -principalsallowedtoretrievemanagedpassword gMSA_DefenderId_access

The second way, and the way I prefer, is to add computer objects directly to the gMSA. This can be cumbersome in larger environments, but I believe it’s more secure, as you’re guaranteeing that only domain admins or users who have delegated control of gMSAs too can modify this property. Replace identity with the name of your gMSA and principalsallowedtoretrievemanagedpassword with the computer names of your domain controllers (followed by the dollar sign).

set-adserviceaccount -identity gMSA_DefenderId -principalsallowedtoretrievemanagedpassword dc01$,dc02$

To check the principals, run this command and look at the attribute:

get-adserviceaccount -identity gMSA_DefenderId -properties principalsallowedtoretrievemanagedpassword

Gotcha #2: Log on As Service

Now that we have the gMSA, we need to make sure that the gMSA can logon as a service on the domain controllers. The easiest way to do this is to use Group Policy.

1. Open Group Policy Management and expand down to your Domain Controllers OU.
2. Right-click the Default Domain Controllers Policy and select Edit….
3. Expand to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment.

4. Find the Log on as a service policy and double-click it.
5. Check the Define these policy settings box.
6. Click Add User or Group.
7. Add your gMSA and close Group Policy Management saving all changes.

Gotcha #3: Dollar Sign

Finally, remember that when referencing a gMSA, you must include the dollar sign on the end of the account. So, when defining the account in the Defender for Identity Portal, be sure to use the $ on the end.

Disclaimer

All content provided on this blog is for information purposes only. Windows Management Experts, Inc makes no representation as to accuracy or completeness of any information on this site. Windows Management Experts, Inc will not be liable for any errors or omission in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants, should you need any further assistance.