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 Identität „LocalService“ und der Aktualisierungsdienst unter der Identität „LocalSystem“ ausgeführt.
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: |
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:
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.
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.
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.
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:
Der Sensor sucht nach einer Übereinstimmung zwischen dem DNS-Do Standard Namen der Ziel-Do Standard, z
emea.contoso.com
. B. und dem DSA gMSA-Eintrag, zemea.contoso.com
. B. .Der Sensor sucht nach einer Übereinstimmung zwischen dem DNS-Do Standard Namen der Ziel-Do Standard, z
emea.contoso.com
. B. und dem regulären DSA-Eintrag DSA, z. B.emea.contoso.com
Der Sensor sucht nach einer Übereinstimmung im Dns-Stammnamen des Ziels Standard, z
emea.contoso.com
. B. und den DSA gMSA-Eintrag Standard Name, zcontoso.com
. B. .Der Sensor sucht nach einer Übereinstimmung im Stamm-DNS-Namen des Ziels Standard, z
emea.contoso.com
. B. und den regulären DSA-Eintrag Standard Name, zcontoso.com
. B. .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. .Der Sensor sucht nach dem Ziel-Do Standard Namen für eine gleichgeordnete Funktion Standard, z
emea.contoso.com
. B. und den regulären DSA-Eintrag Standard Name, zapac.contoso.com
. B. .Der Sensor führt ein Roundrobin aller DSA gMSA-Einträge aus.
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.