Microsoft Defender for Identity (MDI) schützt das lokale Active Directory (AD) vor Identitätsbedrohungen als cloud-basierte Sicherheitslösung. Durch die umfassende Analyse von Benutzeraktivitäten und das Erkennen komplexer Angriffsvektoren gewährleistet Microsoft Defender for Identity (MDI) einen integrativen Schutz vor Identitätskompromittierungen.
Microsoft Defender for Identity geht über die blosse Erkennung von Sicherheitsvorfällen hinaus, indem es umfassende Angriffsszenarien wie Pass-the-Hash, Pass-the-Ticket und Reconnaissance-Techniken erkennt, identifiziert und analysiert. Die integrierte Bedrohungsanalyse nutzt maschinelles Lernen und heuristische Algorithmen, um ungewöhnliches Verhalten innerhalb der IT-Infrastruktur zu identifizieren, wie beispielsweise plötzliche Rechteerweiterungen. Dank dieser Analysen können Sicherheits-Teams schneller auf potenzielle Angriffe reagieren.
Voraussetzungen und Lizenzierung
Lizenzen
Für die Nutzung von Microsoft Defender for Identity ist eine der folgenden Lizenzen erforderlich:
- Enterprise Mobility + Security E5/A5
- Microsoft 365 E5/A5
- Microsoft 365 E5/A5/F5 Security Add-On*
- Microsoft 365 F5 Security + Compliance Add-On*
- eine eigenständige Defender for Identity Lizenz
* zusätzliche Lizenzen sind notwendig
Eine Übersicht der Microsoft Lizenzpakete mit deren Features kann unter https://m365maps.com/ abgerufen werden.
Rollen
Für die Konfiguration und Verwaltung von Microsoft Defender for Identity (MDI) sind folgende Rollen nach dem Prinzip der geringsten Berechtigungen vorgesehen:
Rolle | Beschreibung |
Sicherheitsadministrator | Bereitstellung und Verwalten von Microsoft Defender for Identity |
Sicherheitsoperator | Einstellungen für Microsoft Defender for Identity konfigurieren Verwalten von Microsoft Defender for Identity-Sicherheitswarnungen und -aktivitäten |
Sicherheitsleseberechtigter | Anzeigen der Einstellungen von Microsoft Defender for Identity |
Weitere Rollen und Berechtigungen sind im folgenden Artikel beschrieben: Rollengruppen – Microsoft Defender for Identity | Microsoft Learn
Für die Verbindung von Sensoren mit dem lokalen Active Directory wird ein gruppenverwaltetes Dienstkonto (gMSA) verwendet. Zum Erstellen eines gMSA-Kontos ist entweder ein Domänenadministrator-Konto oder eine Berechtigung zur Erstellung von msDS-GroupManagedServiceAccount-Objekten erforderlich.
Betriebssysteme
Microsoft Defender for Identity erfordert die folgende Betriebssystem als Desktop- oder Coreversion:
- Windows Server 2016, vollständig gepatcht
- Windows Server 2019, vollständig gepatcht
- Windows Server 2022, vollständig gepatcht
- Windows Server 2025, vollständig gepatcht
Installationen werden für Domänencontroller, Active Directory Federation Service (AD FS) und Active Directory Certificate Services (AD CS) unterstützt.
Microsoft empfiehlt Active Directory Federation Service (AD FS) auf Microsoft Entra ID zu migrieren. Weitere Informationen hierzu: Referenz zur Ausserbetriebnahme von AD FS | Microsoft Learn
Netzwerk
Für den reibungslosen Betrieb werden nachfolgende Netzwerk Ports für die Kommunikation benötigt. Detaillierte Informationen dazu: Voraussetzungen – Microsoft Defender for Identity | Microsoft Learn
Internet Ports
Protokoll | Transport | Port | Von | Nach |
SSL | TCP | 443 | MDI-Sensor | Defender for Identity-Clouddienst |
Die Verbindung lässt sich wie folgt testen. Der notwendige Arbeitsbereichsname für den Test ist im Microsoft Defender Portal (https://security.microsoft.com) > Einstellungen > Identitäten > Allgemein > Info zu finden.

Folgender PowerShell Befehl testet die Verbindung.
1 | invoke-WebRequest https://%Arbeitsbereichsname%sensorapi.atp.azure.com/tri/sensor/api/ping |
Als Ergebnis soll HTTP Status Code 200 ausgegeben werden.

Interne Ports
Protokoll | Transport | Port | Von | Nach |
DNS | TCP/UDP | 53 | MDI-Sensor | DNS Server |
Netlogon | TCP/UDP | 445 | MDI-Sensor | Alle Geräte im Netzwerk |
Radius | UDP | 1813 | Radius | MDI-Sensor |
SSL | TCP | 444 | Sensordienst | Sensorupdatedienst |
Localhost-Ports* |
*Notwendig für den Sensor-Dienst-Updater, Der Datenverkehr zwischen localhost und localhost ist in der Regel erlaubt, es sei denn, er wird durch eine benutzerdefinierte Firewallregel eingeschränkt.
Netzwerknamensauflösung (Network Name Resolution, NNR)
Protokoll | Transport | Port | Von | Nach |
NTLM über RPC | TCP | 135 | MDI-Sensor | Alle Geräte im Netzwerk |
NetBIOS | UDP | 137 | MDI-Sensor | Alle Geräte im Netzwerk |
RDP* | TCP | 3389 | MDI-Sensor | Alle Geräte im Netzwerk |
*nur das erste Client hello Paket erforderlich.
Domäne für Microsoft Defender Identity vorbereiten
Gruppenverwaltetes Dienstkonto erstellen
Für die Verbindung von Sensoren mit der lokalen Active Directory Domäne stehen zwei Varianten zur Verfügung:
- Verzeichnisdienstkonto (AD-Benutzerkonto und Kennwort)
- Gruppenverwaltetes Dienstkonto (automatisiert verwaltetet, gMSA)
Eine Anmeldung mit einem gruppenverwalteten Dienstkonto (gMSA) wird aus Sicherheitsgründen priorisiert. Im Folgenden wird ein gruppenverwaltetes Dienstkonto (gMSA) erstellt. Dabei handelt es sich um ein Domänenkonto, das für die Ausführung von Diensten genutzt wird. Ein wesentlicher Sicherheitsvorteil eines gMSA ist, dass die Kennwortverwaltung automatisch erfolgt und nicht manuell durchgeführt werden muss.
Falls auf dem Domänencontroller noch kein gruppenverwaltetes Dienstkonto (gMSA) erstellt wurde, muss zuvor ein KDS Root Key angelegt werden. Dieser ist erforderlich, um die gMSA-Kennwörter sicher zu generieren und zu verwalten. Der folgende PowerShell-Befehl wird dafür verwendet:
1 | Add-KdsRootKey -EffectiveImmediately |

Ein gruppenverwaltetes Dienstkonto (gMSA) lässt sich mit PowerShell erstellen. Dazu muss PowerShell auf einem Domänencontroller mit einem Benutzerkonto gestartet werden, das entweder über Domänenadministrator-Berechtigungen oder die Berechtigung zum Erstellen von msDS-GroupManagedServiceAccount-Objekten verfügt.
Folgende Parameter anpassen:
- Name: Name für das Dienstkonto, z.B. MDI-SvcAccount
- DNSHostName: FQDN des Dienstkontos, z.B. MDI-SvcAccount.int.cloudcoffee.ch
- PrincipalsAllowedToRetrieveManagedPassword: sämtliche Domänencontroller angeben, damit die Sensoren Zugriff auf das Kennwort erhalten
1 | New-ADServiceAccount -Name MDI-SvcAccount -DNSHostName MDI-SvcAccount.int.cloudcoffee.ch -KerberosEncryptionType AES256 -ManagedPasswordIntervalInDays 30 -PrincipalsAllowedToRetrieveManagedPassword cclvsrdc001$ |

Die Eigenschaften des gruppenverwalteten Dienstkontos können folgenden PowerShell Befehl abgerufen werden.
1 | Get-ADServiceAccount -Identity MDI-SvcAccount |

Der folgende PowerShell-Befehl prüft den Zugriff auf das gruppenverwaltete Dienstkonto vom lokalen Server.
1 | Test-ADServiceAccount -Identity MDI-SvcAccount |

Berechtigungen für gruppenverwaltetes Dienstkonto
Microsoft Defender for Identity (MDI) erhält Lesezugriff auf die Objekte im Active Directory, um seine Aufgaben erfüllen zu können. Für die Erkennung gelöschter Benutzer ist zusätzlich Zugriff auf den Container für gelöschte Objekte erforderlich. Der Zugriff auf gelöschte Objekte setzt voraus, dass der Active Directory-Papierkorb aktiviert ist.
Active Directory Administrative Center > Aufgaben > Papierkorb aktivieren

Im folgenden PowerShell-Skript (Quelle: Konfigurieren einer DSA für Defender for Identity mit einem gMSA – Microsoft Defender for Identity | Microsoft Learn) müssen die Variablen $Identity und $groupName angepasst und das Skript anschliessend ausgeführt werden.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | # Declare the identity that you want to add read access to the deleted objects container: $Identity = 'MDI-SvcAccount' # If the identity is a gMSA, first to create a group and add the gMSA to it: $groupName = 'MDI-SvcAccountGroup' $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 |
Die Berechtigungen für das gruppenverwaltete Dienstkonto (gMSA) wurden erfolgreich gesetzt.

Gruppenrichtlinien für erweiterte Überwachungsrichtlinien
Der Konfigurationsbericht von Microsoft Defender for Identity (MDI) überprüft die Security Access Control Lists (SACLs) der Domäne sowie die erforderlichen Gruppenrichtlinien. Werden dabei Abweichungen von den Anforderungen festgestellt, weist der Bericht darauf hin.
Für die Erstellung des Berichts wird das PowerShell Modul DefenderForIdentity benötigt.
1 2 | Install-Module -Name DefenderForIdentity Import-Module DefenderForIdentity |

Konfigurationsbericht erstellen, die Option Path auf den gewünschten Speicherorts des Berichts ändern.
1 | New-MDIConfigurationReport -Path C:\Scripts\MDI -Mode Domain -OpenHtmlReport |
Nach dem Ausführen des PowerShell Befehls wird nach der Identity gefragt. Hier den Hostnamen eingeben, z.B. CCLVSRDC001

Der HTML-Bericht zeigt übersichtlich, welche Konfigurationen bereits erfüllt sind und welche noch angepasst werden müssen. Für nicht erfüllte Einstellungen werden direkt die passenden PowerShell-Befehle bereitgestellt, um die Konfiguration zu vereinfachen. Wer detaillierte Informationen zu den von Microsoft Defender for Identity (MDI) berücksichtigten Ereignissen sucht, findet diese unter folgendem Link: Übersicht über Ereignissammlungen – Microsoft Defender for Identity | Microsoft Learn

Auszug aus den Gruppenrichtlinien:

Kapazitätsplanungstool
Das Kapazitätsplanungstool analysiert die Leistungsanforderungen von Microsoft Defender for Identity (MDI), indem es Daten zum Netzwerkverkehr, zur CPU-Auslastung, zum Speicherbedarf und weitere erfasst. Basierend auf diesen Informationen erstellt es einen Bericht mit Empfehlungen zur optimalen Ressourcenzuweisung.
Das Kapazitätsplanungstool TriSizingTool von Github herunterladen, entpacken und die Datei TriSizingTool.exe ausführen. Das Tool läuft danach 24 Stunden um die Daten zu sammeln.

Nach 24 Stunden steht der Bericht zur Leistungsfähigkeit für Microsoft Defender for Identity (MDI) als Excel-Datei zur Verfügung. Das Tabellenblatt Azure ATP Summary enthält in der Spalte Sensor Supported detaillierte Ergebnisse sowie Empfehlungen zur Leistungsbewertung. Weitere Informationen zu den Ergebnissen können hier nachgelesen werden: Planen der Bereitstellungskapazität – Microsoft Defender for Identity | Microsoft Learn

Bereitschaft überprüfen
Das PowerShell Script Test-MdiReadiness.ps1 überprüft alle wesentlichen Anforderungen für die Einrichtung. Werden bestimmte Bedingungen nicht erfüllt, stellt es hilfreiche Links zu relevanten Microsoft Learn-Artikeln bereit, die konkrete Anleitungen zur Lösung der identifizierten Probleme enthalten. Zu den überprüften Bereichen gehören unter anderem:
- Bereitschaft der Domänendienste
Überprüfung der Konfiguration von Objekt-, Exchange- und AD FS-Überwachung sowie weiterer relevanter Einstellungen. - Bereitschaft der Domänencontroller
Analyse der Konfiguration der erweiterten Überwachung, NTLM-Einstellungen, der Betriebssystemversion, der Anforderungen an Serverressourcen und mehr. - Bereitschaft der Zertifizierungsstellen-Server
Prüfung der Überwachungsrichtlinien für Zertifizierungsstellen-Server sowie der Aktualität der Stammzertifikate und weiterer Konfigurationen.
PowerShell Script Test-MdiReadiness.ps1 von Github herunterladen und ausführen.
1 | .\Test-MdiReadiness.ps1 -OpenHtmlReport |

Das PowerShell-Skript überprüft die Vorbereitungen der Active Directory-Umgebung für die Integration mit Microsoft Defender for Identity (MDI) und öffnet den HTML-Report im Browser. Hinweise zur Konfiguration, falls bestimmte Voraussetzungen fehlen, sind direkt über den Link in der Überschrift zugänglich.

Microsoft Defender for Identity konfigurieren
Die Konfiguration von Microsoft Defender for Identity (MDI) erfolgt im Microsoft Defender Portal vorgenommen.
Microsoft Defender Portal (https://security.microsoft.com) öffnen > Einstellungen > Identitäten auswählen.

Beim ersten Aufruf wird der Workspace eingerichtet und steht nach wenigen Minuten zur Verfügung.

Gruppenverwaltetes Dienstkonto
Das zuvor vorbereitete gruppenverwaltete Dienstkonto unter Verzeichnisdienstkonten > Anmledeinformationen hinzufügen hinterlegen.
- Name des gruppenverwalteten Dienstkontos angeben
- Option Gruppenverwaltetes Dienstkonto aktivieren
- Lokale Domäne angeben
- Eingaben mit Speichern abschliessen

Sensoren
Setupdatei für die Installation der Sensoren unter Sensoren > Sensor hinzufügen > Installationsprogramm herunterladen (1).
Zugriffsschlüssel (2) notieren

Heruntergeladene Datei Azure ATP Sensor Setup.zip auf dem Server entpacken und Installation mit Azure ATP Sensor Setup.exe starten.

Sprache (1) wählen und Weiter (2) klicken.

Bereitstellungstyp Sensor (1) wählen und Weiter (2) klicken.
Bei virutellen Gastsystemen auf VMWare sollte Large Send Offload (LSO) deaktiviert sein. Siehe dazu Sensoren auf VMware virtuellen Maschinen.

Zugriffsschlüssel (1) einfügen und Installieren (2) klicken.

Die Installation ist nach kurzer Zeit erfolgreich abgeschlossen.

Der Domänencontroller wird im Microsoft Defender Portal unter Sensoren angzeigt.

Den Sensor auf jedem relevanten Server installieren.
Benachrichtigungen
Benachrichtigungen an Emailempfänger können für Integritätsprobleme und neu erkannte Warnungen ausgelöst werden.
Benachrichtigungen zu Integritätsproblemen
Emailempfänger unter Benachrichtigungen > Benachrichtigungen zu Integritätsproblemen hinzufügen.

Benachrichtigungen über Warnungen
Emailempfänger unter Benachrichtigungen > Warnungsbenachrichtigungen hinzufügen.

Funktionskontrolle
Microsoft Defender for Identity (MDI) bietet einen Testmodus an, um die Konfiguration zu validieren. Dadurch werden alle Warnschwellwerte auf Niedrig gesetzt, weshalb eine höhere Anzahl an Warnungen versendet wird.
Microsoft Defender Portal (https://security.microsoft.com) > Einstellungen > Identitäten > Allgemein > Warnungsschwellenwerte anpassen öffnen und Option Empfohlener Testmodus (1) aktivieren und mit Änderungen anwenden (2) speichern.

Nachdem der Testmodus aktiviert ist, weist man einem Benutzer eine privilegierte Rolle, z.B. ein Organisations-Administrator, zu.

Diese Aktion löst die Benachrichtigung Verdächtiges Hinzufügungen zu sensiblen Gruppen aus. Wenn Emailbenachrichtigungen aktiviert sind, erscheint folgende Meldung im Postfach:

Eine genauere Untersuchung der Warnung ist im Microsoft Defender Portal möglich.
Microsoft Defender Portal (https://security.microsoft.com) > Vorfälle & Warnungen > Benachrichtigungen und Vorfall anklicken.

Detaillierte Angaben zum Vorfall werden nun angezeigt.

Nach erfolgreicher Funktionskontrolle die privilegierte Rolle beim Benutzer entfernen und den Testmodus wieder ausschalten.
Microsoft Defender Portal (https://security.microsoft.com) > Einstellungen > Identitäten > Allgemein > Warnungsschwellenwerte anpassen öffnen und Option Empfohlener Testmodus (1) deaktivieren und mit Änderungen anwenden (2) speichern.

Fehlersuche und Fehlerbehebung
Sensoren auf VMware virtuellen Maschinen
Bei Microsoft Defender for Identity Sensoren auf VMware virtuellen Maschinen kann die Warnung Einige Netzwerkdaten werden nicht analysiert auftreten.
Lösung: In der Netzwerkkarten Konfiguration des Gastsystems IPv4 TSO Offload auf Deaktiviert setzen.
Der folgende PowerShell Befehl prüft, ob Large Send Offload (LSO) aktiviert ist:
1 | Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*" |

Folgender PowerShell Befehl ausführen, um Large Send Offload (LSO) zu deaktivieren. Dies führt zu einem kurzen Unterbruch der Netzwerkverbindung.
1 | Disable-NetAdapterLso -Name %NameNetzwerkAdapter% |

Large Send Offload (LSO) ist nun deaktiviert.
1 | Get-NetAdapterAdvancedProperty | Where-Object DisplayName -Match "^Large*" |

Gut zu wissen
Sensor Update verzögern
Der Sensor prüft in regelmässigen Abständen auf Updates, lädt diese herunter und installiert sie automatisch. Aktiviert man die Funktion Verzögertes Update, wird dieser Vorgang um 72 Stunden verschoben. Dadurch können Administratoren innerhalb der Infrastruktur Aktualisierungsringe für den Microsoft Defender for Identity (MDI) Sensor implementieren.
Gerät (1) unter Microsoft Defender Portal (https://security.microsoft.com) > Einstellungen > Identitäten > Allgemein > Sensoren auswählen und Verzögertes Update aktivieren (2) anklicken.

Folge mir auf LinkedIn und Bluesky, um stets über meine neuesten Beiträge auf dem Laufenden zu bleiben.
War dieser Beitrag hilfreich für dich? Zeige deine Begeisterung mit dem herrlichen Aroma eines frisch gebrühten Kaffees für mich!