Directory Service Accounts for Microsoft Defender for Identity

This article describes how Microsoft Defender for Identity uses Directory Service Accounts (DSAs).

While a DSA is optional in some scenarios, we recommend that you configure a DSA for Defender for Identity for full security coverage.

For example, when you have a DSA configured, the DSA is used to connect to the domain controller at startup. A DSA can also be used to query the domain controller for data on entities seen in network traffic, monitored events, and monitored ETW activities

A DSA is required for the following features and functionality:

• When working with a sensor installed on an AD FS / AD CS server.

• Requesting member lists for local administrator groups from devices seen in network traffic, events and ETW activities via a SAM-R call made to the device. Collected data is used to calculate potential lateral movement paths.

• Accessing the DeletedObjects container to collect information about deleted users and computers.

• Domain and trust mapping, which occurs at sensor startup, and again every 10 minutes.

• Querying another domain via LDAP for details, when detecting activities from entities in those other domains.

When you're using a single DSA, the DSA must have Read permissions to all the domains in the forests. In an untrusted, multi-forest environment, a DSA account is required for each forest.

One sensor in each domain is defined as the domain synchronizer, and is responsible for tracking changes to the entities in the domain. For examples, changes might include objects created, entity attributes tracked by Defender for Identity, and so on.

Supported DSA account options

Defender for Identity supports the following DSA options:

DSA entry usage

This section describes how DSA entries are used, and how the sensor selects a DSA entry in any given scenario. Sensor attempts differ, depending on the type of DSA entry:

The following logic is applied:

1. The sensor looks for an entry with an exact match of the domain name for the target domain. If an exact match is found, the sensor attempts to authenticate using the credentials in that entry.

2. If there isn't an exact match, or if the authentication failed, the sensor searches the list for an entry to the parent domain using DNS FQDN, and attempts to authenticate using the credentials in the parent entry instead.

3. If there isn't an entry for the parent domain, or if the authentication failed, the sensor searches the list for a sibling domain entry, using the DNS FQDN, and attempts to authenticate using the credentials in the sibling entry instead.

4. If there isn't an entry for the sibling domain, or if the authentication failed, the sensor reviews the list again and tries to authenticate again with each entry until it succeeds. DSA gMSA entries have higher priority than regular DSA entries.

Sample logic with a DSA

This section provides an example of how the sensor tries the DSA entires when you have multiple accounts, including both a gMSA account and a regular account.

The following logic is applied:

1. The sensor looks for a match between the DNS domain name of the target domain, such as emea.contoso.com and the DSA gMSA entry, such as emea.contoso.com.

2. The sensor looks for a match between the DNS domain name of the target domain, such as emea.contoso.com and the DSA regular entry DSA, such as emea.contoso.com

3. The sensor looks for a match in the root DNS name of the target domain, such as emea.contoso.com and the DSA gMSA entry domain name, such as contoso.com.

4. The sensor looks for a match in the root DNS name of the target domain, such as emea.contoso.com and the DSA regular entry domain name, such as contoso.com.

5. The sensor looks for the target domain name for a sibling domain, such as emea.contoso.com and the DSA gMSA entry domain name, such as apac.contoso.com.

6. The sensor looks for the target domain name for a sibling domain, such as emea.contoso.com and the DSA regular entry domain name, such as apac.contoso.com.

7. The sensor runs a round robin of all DSA gMSA entries.

8. The sensor runs a round robin of all DSA regular entries.

The logic shown in this example is implemented with the following configuration:

• DSA entries:

  • DSA1.emea.contoso.com
  • DSA2.fabrikam.com

• Sensors and the DSA entry that's used first:

  Domain controller FQDN	DSA entry used
  DC01.emea.contoso.com	DSA1.emea.contoso.com
  DC02.contoso.com	DSA1.emea.contoso.com
  DC03.fabrikam.com	DSA2.fabrikam.com
  DC04.contoso.local	Round robin

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.

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

Test your DSA permissions and delegations via PowerShell

Use the following PowerShell command to verify that your DSA doesn't have too many permissions, such as powerful admin permissions:

Test-MDIDSA [-Identity] <String> [-Detailed] [<CommonParameters>]

For example, to check permissions for the mdiSvc01 account and provide full details, run:

Test-MDIDSA -Identity "mdiSvc01" -Detailed

For more information, see the DefenderForIdentity PowerShell reference.

Next step