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: |
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:
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.
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.
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.
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:
Der Sensor sucht nach einer Übereinstimmung zwischen dem DNS-Domänennamen der Zieldomäne, z
emea.contoso.com
. B. und dem DSA gMSA-Eintrag, zemea.contoso.com
. B. .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
Der Sensor sucht nach einer Übereinstimmung im DNS-Stammnamen der Zieldomäne, z
emea.contoso.com
. B. und dem DSA gMSA-Eintragsdomänennamen, zcontoso.com
. B. .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, zcontoso.com
. B. .Der Sensor sucht nach dem Zieldomänennamen für eine gleichgeordnete Domäne, z
emea.contoso.com
. B. und den DSA gMSA-Eintragsdomänennamen, zapac.contoso.com
. B. .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. Bapac.contoso.com
. .Der Sensor führt ein Roundrobin aller DSA gMSA-Einträge aus.
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.