Учетные записи службы каталогов для Microsoft Defender для удостоверений

В этой статье описывается, как Microsoft Defender для удостоверений использовать учетные записи службы каталогов (DSA).

Хотя DSA является необязательным в некоторых сценариях, рекомендуется настроить DSA for Defender для удостоверений для полного покрытия безопасности.

Например, если вы настроили DSA, DSA используется для подключения к контроллеру домена при запуске. DSA также можно использовать для запроса контроллера домена данных о сущностях, которые отображаются в сетевом трафике, отслеживаемых событиях и отслеживаемых действиях ТРАСС

DsA требуется для следующих функций и функций:

• При работе с датчиком, установленным на сервере AD FS/ AD CS.

• Запрос списков участников для локальных групп администраторов с устройств, замеченных в сетевом трафике, событиях и действиях ETW с помощью вызова SAM-R, выполненного на устройство. Собранные данные используются для вычисления потенциальных путей бокового перемещения.

• Доступ к контейнеру DeletedObjects для сбора сведений об удаленных пользователях и компьютерах.

• Сопоставление доменов и доверия, которое происходит при запуске датчика и снова каждые 10 минут.

• Запрос другого домена через LDAP для получения сведений при обнаружении действий от сущностей в этих других доменах.

При использовании одного DSA dsA dsA необходимо иметь разрешения на чтение для всех доменов в лесах. В недоверенной среде с несколькими лесами для каждого леса требуется учетная запись DSA.

Один датчик в каждом домене определяется как синхронизатор домена и отвечает за отслеживание изменений сущностей в домене. Например, изменения могут включать объекты, созданные объекты, атрибуты сущностей, отслеживаемые Defender для удостоверений и т. д.

Поддерживаемые параметры учетной записи DSA

Defender для удостоверений поддерживает следующие параметры DSA:

Использование записи DSA

В этом разделе описывается, как используются записи DSA и как датчик выбирает запись DSA в любом конкретном сценарии. Попытки датчика отличаются в зависимости от типа записи DSA:

Применяется следующая логика:

1. Датчик ищет запись с точным совпадением имени домена для целевого домена. Если найдено точное совпадение, датчик пытается пройти проверку подлинности с помощью учетных данных в этой записи.

2. Если нет точного совпадения или если проверка подлинности завершилась ошибкой, датчик выполняет поиск в списке записи в родительском домене с помощью полного доменного имени DNS и пытается выполнить проверку подлинности с помощью учетных данных в родительской записи.

3. Если для родительского домена нет записи или если проверка подлинности завершилась ошибкой, датчик выполняет поиск списка для записи домена с братским братом, используя полное доменное имя DNS и пытается выполнить проверку подлинности с помощью учетных данных в записи с братом.

4. Если нет записи для одноуровневого домена или если проверка подлинности завершилась ошибкой, датчик снова проверяет список и пытается выполнить проверку подлинности повторно с каждой записью до тех пор, пока она не завершится успешно. Записи DSA gMSA имеют более высокий приоритет, чем обычные записи DSA.

Пример логики с DSA

В этом разделе приведен пример того, как датчик пытается выполнить все dsA при наличии нескольких учетных записей, включая учетную запись gMSA и обычную учетную запись.

Применяется следующая логика:

1. Датчик ищет совпадение между dns-доменным именем целевого домена, например записью DSA gMSA, например emea.contoso.com emea.contoso.com.

2. Датчик ищет совпадение между DNS-доменным именем целевого домена, например emea.contoso.com с dsA регулярной записью DSA, например DSA. emea.contoso.com

3. Датчик ищет совпадение в корневом DNS-имени целевого домена, например имя домена записи DSA gMSA, например emea.contoso.com contoso.com.

4. Датчик ищет совпадение в корневом DNS-имени целевого домена, например и имени домена обычной записи DSA, например emea.contoso.com contoso.com.

5. Датчик ищет целевое доменное имя для одноуровневого домена, например emea.contoso.com имя домена записи DSA gMSA, например apac.contoso.com.

6. Датчик ищет целевое доменное имя для одноуровневого домена, например emea.contoso.com и имя домена обычной записи DSA, например apac.contoso.com.

7. Датчик выполняет циклический перебор всех записей DSA gMSA.

8. Датчик выполняет круглую перебор всех регулярных записей DSA.

Логика, показанная в этом примере, реализована со следующей конфигурацией:

• Записи DSA:

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

• Датчики и запись DSA, которые используются в первую очередь:

  Полное доменное имя контроллера домена	Используемая запись DSA
  DC01.emea.contoso.com	DSA1.emea.contoso.com
  DC02.contoso.com	DSA1.emea.contoso.com
  DC03.fabrikam.com	DSA2.fabrikam.com
  DC04.contoso.local	Циклический перебор

Предоставление необходимых разрешений DSA

ДЛЯ DSA требуются разрешения только для чтения всех объектов в Active Directory, включая контейнер удаленных объектов.

Разрешения только для чтения в контейнере удаленных объектов позволяют Defender для удостоверений обнаруживать удаления пользователей из Active Directory.

Используйте следующий пример кода, чтобы предоставить необходимые разрешения на чтение в контейнере удаленных объектов , независимо от того, используется ли учетная запись 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

Дополнительные сведения см. в разделе "Изменение разрешений" в контейнере удаленных объектов.

Тестирование разрешений и делегирований DSA с помощью PowerShell

Используйте следующую команду PowerShell, чтобы убедиться, что dsA не имеет слишком большого количества разрешений, таких как мощные разрешения администратора:

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

Например, чтобы проверить разрешения для учетной записи mdiSvc01 и указать полные сведения, выполните следующую команду:

Test-MDIDSA -Identity "mdiSvc01" -Detailed

Дополнительные сведения см. в справочнике по DefenderForIdentity PowerShell.

Следующий шаг