Verzeichnisdienstkonten für Microsoft Defender for Identity

  • Artikel

In diesem Artikel wird beschrieben, wie Microsoft Defender for Identity Verzeichnisdienstkonten (DSAs) verwendet.

Während ein DSA in einigen Szenarien optional ist, empfehlen wir, eine DSA für Defender for Identity für die vollständige Sicherheitsabdeckung zu konfigurieren.

Wenn Sie z. B. eine DSA konfiguriert haben, wird die DSA zum Herstellen einer Verbindung mit dem Do Standard Controller beim Start verwendet. Eine DSA kann auch verwendet werden, um den Do Standard-Controller für Daten zu Entitäten abzufragen, die im Netzwerkdatenverkehr angezeigt werden, überwachte Ereignisse und überwachte ETW-Aktivitäten

Für die folgenden Features und Funktionen ist eine DSA erforderlich:

  • Beim Arbeiten mit einem Sensor, der auf einem AD FS/AD CS-Server installiert ist.

  • Anfordern von Mitgliedslisten für lokale Administratorgruppen von Geräten, die in Netzwerkdatenverkehr, Ereignissen und ETW-Aktivitäten über einen SAM-R-Aufruf an das Gerät angezeigt werden. Erfasste Daten werden verwendet, um potenzielle Lateral Movement-Pfade zu berechnen.

  • Zugreifen auf den DeletedObjects-Container , um Informationen zu gelöschten Benutzern und Computern zu sammeln.

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

  • Wenn Sie eine andere Do Standard über LDAP abfragen, um Details zu erhalten, wenn Aktivitäten von Entitäten in diesen anderen Aktionen erkannt werden Standard.

Wenn Sie eine einzelne DSA verwenden, muss die DSA über Leseberechtigungen für alle Aufgaben verfügen Standard in den Gesamtstrukturen. In einer nicht vertrauenswürdigen Umgebung mit mehreren Gesamtstrukturen ist für jede Gesamtstruktur ein DSA-Konto erforderlich.

Ein Sensor in jeder Do Standard wird als do Standard Synchronizer definiert und ist für das Nachverfolgen von Änderungen an den Entitäten in der Do Standard verantwortlich. Zu Beispielen können Änderungen Objekte enthalten, die von Defender for Identity nachverfolgt werden, Entitätsattribute, die von Defender for Identity nachverfolgt werden usw.

Hinweis

Standardmäßig unterstützt Defender for Identity bis zu 30 Sensoren. Wenden Sie sich an den Defender for Identity-Support, um weitere Anmeldeinformationen hinzuzufügen.

Unterstützte DSA-Kontooptionen

Defender for Identity unterstützt die folgenden DSA-Optionen:

Option BESCHREIBUNG Konfiguration
Gruppenverwaltetes Dienstkonto gMSA (empfohlen) Bietet eine sicherere Bereitstellung und Kennwortverwaltung. Active Directory verwaltet die Erstellung und Drehung des Kennworts des Kontos, genau wie das Kennwort eines Computerkontos, und Sie können steuern, wie oft das Kennwort des Kontos geändert wird. Weitere Informationen finden Sie unter Konfigurieren eines Verzeichnisdienstkontos für Defender for Identity mit einer gMSA.
Reguläres Benutzerkonto Einfache Verwendung bei den ersten Schritten und einfachere Konfiguration von Leseberechtigungen zwischen vertrauenswürdigen Gesamtstrukturen, erfordert jedoch zusätzlichen Aufwand für die Kennwortverwaltung.

Ein normales Benutzerkonto ist weniger sicher, da Es erfordert, dass Sie Kennwörter erstellen und verwalten, und kann zu Ausfallzeiten führen, wenn das Kennwort abläuft und nicht sowohl für den Benutzer als auch für die DSA aktualisiert wird.		 Erstellen Sie ein neues Konto in Active Directory, das als DSA mit Leseberechtigungen für alle Objekte verwendet werden soll, einschließlich Berechtigungen für den Container "DeletedObjects ". Weitere Informationen finden Sie unter Erforderliche Berechtigungen.

DSA-Eintragsverwendung

In diesem Abschnitt wird beschrieben, wie DSA-Einträge verwendet werden und wie der Sensor einen DSA-Eintrag in einem bestimmten Szenario auswählt. Sensorversuche unterscheiden sich je nach Typ des DSA-Eintrags:

type Beschreibung
gMSA-Konto Der Sensor versucht, das gMSA-Kontokennwort aus Active Directory abzurufen, und meldet sich dann bei der Do Standard an.
Reguläres Benutzerkonto Der Sensor versucht, sich bei der Do Standard mithilfe des konfigurierten Benutzernamens und Kennworts anzumelden.

Die folgende Logik wird angewendet:

  1. Der Sensor sucht nach einem Eintrag mit einer genauen Übereinstimmung des Do Standard Namens für die Ziel-Do Standard. Wenn eine genaue Übereinstimmung gefunden wird, versucht der Sensor, die Anmeldeinformationen in diesem Eintrag zu authentifizieren.

  2. Wenn keine genaue Übereinstimmung vorliegt oder wenn die Authentifizierung fehlgeschlagen ist, durchsucht der Sensor die Liste nach einem Eintrag in der übergeordneten Funktion Standard mit DNS-FQDN und versucht stattdessen, die Anmeldeinformationen im übergeordneten Eintrag zu authentifizieren.

  3. Wenn kein Eintrag für das übergeordnete Objekt vorhanden ist Standard oder wenn die Authentifizierung fehlgeschlagen ist, durchsucht der Sensor die Liste nach einem gleichgeordneten Vorgang Standard Eintrag, wobei der DNS-FQDN verwendet wird, und versucht stattdessen, die Anmeldeinformationen im gleichgeordneten Eintrag zu authentifizieren.

  4. Wenn kein Eintrag für das gleichgeordnete Element vorhanden ist Standard oder wenn die Authentifizierung fehlgeschlagen ist, überprüft der Sensor die Liste erneut und versucht erneut, sich bei jedem Eintrag zu authentifizieren, bis er erfolgreich ist. DSA gMSA-Einträge haben eine höhere Priorität als normale DSA-Einträge.

Beispiellogik mit einer DSA

Dieser Abschnitt enthält ein Beispiel dafür, wie der Sensor die DSA-Vollständigen versucht, wenn Sie über mehrere Konten verfügen, einschließlich eines gMSA-Kontos und eines regulären Kontos.

Die folgende Logik wird angewendet:

  1. Der Sensor sucht nach einer Übereinstimmung zwischen dem DNS-Do Standard Namen der Ziel-Do Standard, zemea.contoso.com. B. und dem DSA gMSA-Eintrag, zemea.contoso.com. B. .

  2. Der Sensor sucht nach einer Übereinstimmung zwischen dem DNS-Do Standard Namen der Ziel-Do Standard, zemea.contoso.com. B. und dem regulären DSA-Eintrag DSA, z. B.emea.contoso.com

  3. Der Sensor sucht nach einer Übereinstimmung im Dns-Stammnamen des Ziels Standard, zemea.contoso.com. B. und den DSA gMSA-Eintrag Standard Name, zcontoso.com. B. .

  4. Der Sensor sucht nach einer Übereinstimmung im Stamm-DNS-Namen des Ziels Standard, zemea.contoso.com. B. und den regulären DSA-Eintrag Standard Name, zcontoso.com. B. .

  5. Der Sensor sucht nach dem Ziel-Do Standard Namen für ein gleichgeordnetes Element Standard wie emea.contoso.com z. B. den DSA gMSA-Eintrag Standard Name, zapac.contoso.com. B. .

  6. Der Sensor sucht nach dem Ziel-Do Standard Namen für eine gleichgeordnete Funktion Standard, zemea.contoso.com. B. und den regulären DSA-Eintrag Standard Name, zapac.contoso.com. B. .

  7. Der Sensor führt ein Roundrobin aller DSA gMSA-Einträge aus.

  8. Der Sensor führt einen Roundrobin aller regulären DSA-Einträge aus.

Der Dienstvertrag wird wie im folgenden Code gezeigt implementiert.

  • DSA-Einträge:

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

  • Sensoren und der DSA-Eintrag, der zuerst verwendet wird:

    Vollqualifizierter Domänenname des Domänencontrollers (FQDN) Verwendeter DSA-Eintrag
    DC01.emea.contoso.com DSA1.emea.contoso.com
    DC02.contoso.com DSA1.emea.contoso.com
    DC03.fabrikam.com DSA2.fabrikam.com
    DC04.contoso.local Roundrobin

Wichtig

Wenn ein Sensor nicht erfolgreich über LDAP bei active Directory authentifiziert werden kann Standard beim Start wechselt der Sensor nicht in einen ausgeführten Zustand, und ein Integritätsproblem wird generiert. Weitere Informationen finden Sie unter Was ist Microsoft Defender for Identity?

Erteilen erforderlicher DSA-Berechtigungen

Die DSA erfordert schreibgeschützte Berechtigungen für alle Objekte in Active Directory, einschließlich des Containers "Gelöschte Objekte".

Die Leseberechtigungen für diesen Container Gelöschte Objekte ermöglicht es Defender for Identity, Benutzerlöschungen in Ihrem Active Directory zu erkennen.

Verwenden Sie das folgende Codebeispiel, um Ihnen bei der Erteilung der erforderlichen Leseberechtigungen für den Container "Gelöschte Objekte " zu helfen, unabhängig davon, ob Sie ein gMSA-Konto verwenden.

Tipp

Wenn die DSA, der Sie die Berechtigungen erteilen möchten, ein Gruppenverwaltetes Dienstkonto (Group Managed Service Account, gMSA) ist, müssen Sie zuerst eine Sicherheitsgruppe erstellen, die gMSA als Mitglied hinzufügen und dieser Gruppe die Berechtigungen hinzufügen. Weitere Informationen finden Sie unter Konfigurieren eines Verzeichnisdienstkontos für Defender for Identity mit einer 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

Weitere Informationen finden Sie unter Ändern von Berechtigungen für einen gelöschten Objektcontainer.

Testen Ihrer DSA-Berechtigungen und -Delegierungen über PowerShell

Verwenden Sie den folgenden PowerShell-Befehl, um zu überprüfen, ob Ihre DSA nicht über zu viele Berechtigungen verfügt, z. B. leistungsstarke Administratorberechtigungen:

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

Um z. B. die Berechtigungen für das mdiSvc01-Konto zu überprüfen und vollständige Details bereitzustellen, führen Sie Folgendes aus:

Test-MDIDSA -Identity "mdiSvc01" -Detailed

Weitere Informationen finden Sie in der PowerShell-Referenz zu DefenderForIdentity.

Nächster Schritt

Konfigurieren eines Verzeichnisdienstkontos für Defender for Identity mit einem gMSA »