Freigeben über


Verzeichnisdienstkonten für Microsoft Defender for Identity

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

Hinweis

Unabhängig von den konfigurierten Verzeichnisdienstkonten wird der Sensordienst unter der LocalService-Identität und der Updatedienst unter der LocalSystem-Identität ausgeführt.

Obwohl eine DSA in einigen Szenarien optional ist, empfiehlt es sich, eine DSA für Defender for Identity für eine vollständige Sicherheitsabdeckung zu konfigurieren.

Wenn Sie beispielsweise eine DSA konfiguriert haben, wird die DSA verwendet, um beim Start eine Verbindung mit dem Domänencontroller herzustellen. Eine DSA kann auch verwendet werden, um den Domänencontroller nach Daten zu Entitäten abzufragen, die im Netzwerkdatenverkehr, überwachten Ereignissen und überwachten ETW-Aktivitäten angezeigt werden.

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

  • Wenn Sie mit einem Sensor arbeiten, 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. Gesammelte 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.

  • Domänen- und Vertrauenszuordnung, die beim Starten des Sensors und erneut alle 10 Minuten erfolgt.

  • Abfragen einer anderen Domäne über LDAP nach Details, wenn Aktivitäten von Entitäten in diesen anderen Domänen erkannt werden.

Wenn Sie eine einzelne DSA verwenden, muss die 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 wird als Domänensynchronisierung definiert und ist für die Nachverfolgung von Änderungen an den Entitäten in der Domäne verantwortlich. Änderungen können beispielsweise erstellte Objekte, Entitätsattribute, die von Defender for Identity nachverfolgt werden usw. umfassen.

Hinweis

Defender for Identity unterstützt standardmäßig bis zu 30 Anmeldeinformationen. 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 Rotation 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 einem gMSA.
Reguläres Benutzerkonto Einfache Verwendung beim Einstieg und einfachere Konfiguration von Leseberechtigungen zwischen vertrauenswürdigen Gesamtstrukturen, erfordert jedoch zusätzlichen Mehraufwand für die Kennwortverwaltung.

Ein reguläres Benutzerkonto ist weniger sicher, da Sie Kennwörter erstellen und verwalten müssen. Dies 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 der Berechtigungen für den DeletedObjects-Container . Weitere Informationen finden Sie unter Gewähren erforderlicher DSA-Berechtigungen.
Lokales Dienstkonto Das lokale Dienstkonto wird standardmäßig verwendet, wenn keine DSA konfiguriert ist.
Hinweis:
  • SAM-R-Abfragen für potenzielle Lateral Movement-Pfade werden in diesem Szenario nicht unterstützt.
  • LDAP-Abfragen nur innerhalb der Domäne, in der der Sensor installiert ist. Bei Abfragen an andere Domänen in derselben Gesamtstruktur oder gesamtstrukturübergreifenden Domäne tritt ein Fehler auf.
  • Keine

    Hinweis

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

    DSA-Eintragsverwendung

    In diesem Abschnitt wird beschrieben, wie DSA-Einträge verwendet werden und wie der Sensor in einem bestimmten Szenario einen DSA-Eintrag 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 mit dem konfigurierten Benutzernamen und Kennwort bei der Domäne anzumelden.

    Die folgende Logik wird angewendet:

    1. Der Sensor sucht nach einem Eintrag mit einer exakten Übereinstimmung des Domänennamens für die Zieldomäne. Wenn eine genaue Übereinstimmung gefunden wird, versucht der Sensor, sich mit den Anmeldeinformationen in diesem Eintrag zu authentifizieren.

    2. Wenn keine genaue Übereinstimmung vorliegt oder die Authentifizierung fehlgeschlagen ist, durchsucht der Sensor die Liste mithilfe des DNS-FQDN nach einem Eintrag in der übergeordneten Domäne und versucht stattdessen, sich mit den Anmeldeinformationen im übergeordneten Eintrag zu authentifizieren.

    3. Wenn kein Eintrag für die übergeordnete Domäne vorhanden ist oder bei der Authentifizierung ein Fehler aufgetreten ist, durchsucht der Sensor die Liste mit dem DNS-FQDN nach einem gleichgeordneten Domäneneintrag und versucht, sich stattdessen mit den Anmeldeinformationen im gleichgeordneten Eintrag zu authentifizieren.

    4. Wenn kein Eintrag für die nebengeordnete Domäne vorhanden ist oder die Authentifizierung fehlgeschlagen ist, überprüft der Sensor die Liste erneut und versucht, sich mit jedem Eintrag erneut zu authentifizieren, bis er erfolgreich ist. DSA gMSA-Einträge haben eine höhere Priorität als reguläre DSA-Einträge.

    Beispiellogik mit einer DSA

    Dieser Abschnitt enthält ein Beispiel dafür, wie der Sensor die DSA-Gesamtmenge 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-Domänennamen der Zieldomäne, z emea.contoso.com . B. und dem DSA gMSA-Eintrag, z emea.contoso.com. B. .

    2. Der Sensor sucht nach einer Übereinstimmung zwischen dem DNS-Domänennamen der Zieldomäne, z emea.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 der Zieldomäne, z emea.contoso.com . B. und dem DSA gMSA-Eintragsdomänennamen, z contoso.com. B. .

    4. Der Sensor sucht nach einer Übereinstimmung im DNS-Stammnamen der Zieldomäne, z emea.contoso.com . B. und dem Domänennamen des regulären DSA-Eintrags, z contoso.com. B. .

    5. Der Sensor sucht nach dem Zieldomänennamen für eine gleichgeordnete Domäne, z emea.contoso.com . B. und den DSA gMSA-Eintragsdomänennamen, z apac.contoso.com. B. .

    6. Der Sensor sucht nach dem Zieldomänennamen für eine gleichgeordnete Domäne, z emea.contoso.com . B. und den Domänennamen des regulären DSA-Eintrags, z. B apac.contoso.com. .

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

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

    Die in diesem Beispiel gezeigte Logik wird mit der folgenden Konfiguration implementiert:

    • DSA-Einträge:

      • DSA1.emea.contoso.com
      • DSA2.fabrikam.com
    • Sensoren und der DSA-Eintrag, der zuerst verwendet wird:

      FQDN des Domänencontrollers 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 sich ein Sensor beim Start nicht erfolgreich über LDAP bei der Active Directory-Domäne authentifizieren kann, wechselt der Sensor nicht in den Ausführungszustand, und es wird ein Integritätsproblem generiert. Weitere Informationen finden Sie unter Probleme mit der Defender for Identity-Integrität.

    Erteilen der erforderlichen DSA-Berechtigungen

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

    Mit den schreibgeschützten Berechtigungen für den Container "Gelöschte Objekte " kann Defender for Identity Benutzerlöschungen aus Ihrem Active Directory erkennen.

    Verwenden Sie das folgende Codebeispiel, um die erforderlichen Leseberechtigungen für den Container "Gelöschte Objekte " zu erteilen, unabhängig davon, ob Sie ein gMSA-Konto verwenden oder nicht.

    Tipp

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

    Führen Sie beispielsweise Folgendes aus, um die Berechtigungen für das mdiSvc01-Konto zu überprüfen und vollständige Details anzugeben:

    Test-MDIDSA -Identity "mdiSvc01" -Detailed
    

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

    Nächster Schritt