Configure a Directory Service Account for Defender for Identity with a gMSA

This article describes how to create a group managed service account (gMSA) for use as a Defender for Identity DSA entry.

For more information, see Directory Service Accounts for Microsoft Defender for Identity.

Tip

In multi-forest, multi-domain environments, we recommend creating the gMSAs with a unique name for each forest or domain. Also, create a universal group in each domain, containing all sensors' computer accounts so that all sensors can retrieve the gMSAs' passwords, and perform the cross-domain authentications.

Prerequisites: Grant permissions to retrieve the gMSA account's password

Before you create the gMSA account, consider how to assign permissions to retrieve the account's password.

When using a gMSA entry, the sensor needs to retrieve the gMSA's password from Active Directory. This can be done either by assigning to each of the sensors or by using a group.

• In a single-forest, single-domain deployment, if you aren't planning to install the sensor on any AD FS / AD CS servers, you can use the built-in Domain Controllers security group.

• In a forest with multiple domains, when using a single DSA account, we recommend creating a universal group and adding each of the domain controllers and AD FS / AD CS servers to the universal group.

If you add a computer account to the universal group after the computer received its Kerberos ticket, it won't be able to retrieve the gMSA's password until it receives a new Kerberos ticket. The Kerberos ticket has a list of groups that an entity is a member of when the ticket is issued.

In such scenarios, do one of the following:

• Wait for new Kerberos ticket to be issued. Kerberos tickets are normally valid for 10 hours.

• Reboot the server. When the server is rebooted, a new Kerberos ticket is requested with the new group membership.

• Purge the existing Kerberos tickets. This forces the domain controller to request a new Kerberos ticket.

  To purge the tickets, from an administrator command prompt on the domain controller, run the following command: klist purge -li 0x3e7

Create the gMSA account

This section describes how to create a specific group that can retrieve the account's password, create a gMSA account, and then test that the account is ready to use.

Note

If you have never used gMSA accounts before, you might need to generate a new root key for the Microsoft Group Key Distribution Service (KdsSvc) within Active Directory. This step is required only once per forest.

To generate a new root key for immediate use, run the following command:

Add-KdsRootKey -EffectiveImmediately

Update the following code with variable values for your environment. Then, run the PowerShell commands as an administrator:

# Variables:
# Specify the name of the gMSA you want to create:
$gMSA_AccountName = 'mdiSvc01'
# Specify the name of the group you want to create for the gMSA,
# or enter 'Domain Controllers' to use the built-in group when your environment is a single forest, and will contain only domain controller sensors.
$gMSA_HostsGroupName = 'mdiSvc01Group'
# Specify the computer accounts that will become members of the gMSA group and have permission to use the gMSA. 
# If you are using the 'Domain Controllers' group in the $gMSA_HostsGroupName variable, then this list is ignored
$gMSA_HostNames = 'DC1', 'DC2', 'DC3', 'DC4', 'DC5', 'DC6', 'ADFS1', 'ADFS2'

# Import the required PowerShell module:
Import-Module ActiveDirectory

# Set the group
if ($gMSA_HostsGroupName -eq 'Domain Controllers') {
    $gMSA_HostsGroup = Get-ADGroup -Identity 'Domain Controllers'
} else {
    $gMSA_HostsGroup = New-ADGroup -Name $gMSA_HostsGroupName -GroupScope DomainLocal -PassThru
    $gMSA_HostNames | ForEach-Object { Get-ADComputer -Identity $_ } |
        ForEach-Object { Add-ADGroupMember -Identity $gMSA_HostsGroupName -Members $_ }
}

# Create the gMSA:
New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$env:USERDNSDOMAIN" `
 -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroup

Grant required DSA permissions

The DSA requires read only permissions on all the objects in Active Directory, including the Deleted Objects Container.

The read-only permissions on the Deleted Objects container allows Defender for Identity to detect user deletions from your Active Directory.

Use the following code sample to help you grant the required read permissions on the Deleted Objects container, whether or not you're using a gMSA account.

Tip

If the DSA you want to grant the permissions to is a Group Managed Service Account (gMSA), you must first create a security group, add the gMSA as a member, and add the permissions to that group. For more information, see Configure a Directory Service Account for Defender for Identity with a gMSA.

# Declare the identity that you want to add read access to the deleted objects container:
$Identity = 'mdiSvc01'

# If the identity is a gMSA, first to create a group and add the gMSA to it:
$groupName = 'mdiUsr01Group'
$groupDescription = 'Members of this group are allowed to read the objects in the Deleted Objects container in AD'
if(Get-ADServiceAccount -Identity $Identity -ErrorAction SilentlyContinue) {
    $groupParams = @{
        Name           = $groupName
        SamAccountName = $groupName
        DisplayName    = $groupName
        GroupCategory  = 'Security'
        GroupScope     = 'Universal'
        Description    = $groupDescription
    }
    $group = New-ADGroup @groupParams -PassThru
    Add-ADGroupMember -Identity $group -Members ('{0}$' -f $Identity)
    $Identity = $group.Name
}

# Get the deleted objects container's distinguished name:
$distinguishedName = ([adsi]'').distinguishedName.Value
$deletedObjectsDN = 'CN=Deleted Objects,{0}' -f $distinguishedName

# Take ownership on the deleted objects container:
$params = @("$deletedObjectsDN", '/takeOwnership')
C:\Windows\System32\dsacls.exe $params

# Grant the 'List Contents' and 'Read Property' permissions to the user or group:
$params = @("$deletedObjectsDN", '/G', ('{0}\{1}:LCRP' -f ([adsi]'').name.Value, $Identity))
C:\Windows\System32\dsacls.exe $params
  
# To remove the permissions, uncomment the next 2 lines and run them instead of the two prior ones:
# $params = @("$deletedObjectsDN", '/R', ('{0}\{1}' -f ([adsi]'').name.Value, $Identity))
# C:\Windows\System32\dsacls.exe $params

For more information, see Changing permissions on a deleted object container.

Verify that the gMSA account has the required rights

The Defender for Identity sensor service, Azure Advanced Threat Protection Sensor, runs as a LocalService and performs impersonation of the DSA account. The impersonation will fail if the Log on as a service policy is configured but the permission hasn't been granted to the gMSA account. In such cases, you'll see the following health issue: Directory services user credentials are incorrect.

If you see this alert, we recommend checking to see if the Log on as a service policy is configured. If you need to configure the Log on as a service policy, do so either in a Group Policy setting or in a Local Security Policy.

• To check the Local Policy, run secpol.msc and select Local Policies. Under User Rights Assignment, go to the Log on as a service policy setting. For example:

  

  If the policy is enabled, add the gMSA account to the list of accounts that can log on as a service.

• To check if the setting is configured in a Group Policy: Run rsop.msc and see if the Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Log on as a service policy is selected. For example:

  

  If the setting is configured, add the gMSA account to the list of accounts that can log on as a service in the Group Policy Management Editor.

Note

If you use the Group Policy Management Editor to configure the Log on as a service setting, make sure you add both NT Service\All Services and the gMSA account you created.

Configure a Directory Service account in Microsoft Defender XDR

To connect your sensors with your Active Directory domains, you'll need to configure Directory Service accounts in Microsoft Defender XDR.

1. In Microsoft Defender XDR, go to Settings > Identities. For example:

   

2. Select Directory Service accounts. You'll see which accounts are associated with which domains. For example:

   

3. To add Directory Service account credentials, select Add credentials and enter the Account name, Domain, and Password of the account you created earlier. You can also choose if it's a Group managed service account (gMSA), and if it belongs to a Single label domain. For example:

   

   Field	Comments
   Account name (required)	Enter the read-only AD username. For example: DefenderForIdentityUser. - You must use a standard AD user or gMSA account. - Don't use the UPN format for your username. - When using a gMSA, the user string should end with the $ sign. For example: mdisvc$ NOTE: We recommend that you avoid using accounts assigned to specific users.
   Password (required for standard AD user accounts)	For AD user accounts only, generate a strong password for the read-only user. For example: PePR!BZ&}Y54UpC3aB.
   Group managed service account (required for gMSA accounts)	For gMSA accounts only, select Group managed service account.
   Domain (required)	Enter the domain for the read-only user. For example: contoso.com. It's important that you enter the complete FQDN of the domain where the user is located. For example, if the user's account is in domain corp.contoso.com, you need to enter corp.contoso.com not contoso.com. For more information, see Microsoft support for Single Label Domains.

4. Select Save.

5. (Optional) If you select an account, a details pane will open with the settings for that account. For example:

   

Note

You can use this same procedure to change the password for standard Active Directory user accounts. There is no password set for gMSA accounts.

Troubleshooting

For more information, see Sensor failed to retrieve the gMSA credentials.

Next step

Configure SAM-R to enable lateral movement path detection in Microsoft Defender for Identity »