Teilen über

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 beispielsweise einen DSA konfiguriert haben, wird der DSA verwendet, um beim Start eine Verbindung mit dem Domänencontroller herzustellen. 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 einen einzelnen DSA verwenden, muss der DSA über Leseberechtigungen für alle Domänen in den Gesamtstrukturen verfügen. In einer nicht vertrauenswürdigen Umgebung mit mehreren Gesamtstrukturen ist für jede Gesamtstruktur ein DSA-Konto erforderlich.

Ein Sensor in jeder Domäne ist als Domänensynchronizer definiert und für die Nachverfolgung von Änderungen an den Entitäten in der Domäne verantwortlich. Zu den Änderungen gehören beispielsweise erstellte Objekte, Entitätsattribute, die von Defender for Identity verfolgt 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.
Lokales Dienstkonto Das lokale Dienstkonto wird standardmäßig verwendet, wenn kein DSA konfiguriert ist.
Hinweis:
  • SAM-R-Abfragen nach möglichen seitlichen Bewegungspfaden werden in diesem Szenario nicht unterstützt.
  • LDAP-Abfragen nur innerhalb der Domäne, in der der Sensor installiert ist, ausgeführt. Abfragen an andere Domänen in derselben Gesamtstruktur oder einer anderen Gesamtstruktur schlagen fehl.
    		•  Keine

    Hinweis

    Während das lokale Dienstkonto standardmäßig mit dem Sensor verwendet wird und ein DSA in einigen Szenarien optional ist, wird empfohlen, einen DSA für Defender for Identity zu konfigurieren, um eine vollständige Sicherheitsabdeckung zu gewährleisten.

    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:

    Typ Beschreibung
    gMSA-Konto Der Sensor versucht, das gMSA-Kontokennwort aus Active Directory abzurufen, und meldet sich dann bei der Domäne 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 es keinen Eintrag für die übergeordnete Domäne gibt oder die Authentifizierung fehlgeschlagen ist, sucht der Sensor in der Liste nach einem Eintrag für eine Geschwisterdomäne, wobei er den DNS-FQDN verwendet, und versucht stattdessen, sich mit den Anmeldeinformationen im Eintrag für die Geschwisterdomäne 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, wie beispielsweise weitreichende 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 den DefenderForIdentity PowerShell-Verweisen.

    Nächster Schritt

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