Der Defender for Identity Sensor v3 lässt sich direkt über MDE aktivieren

In vielen Umgebungen, in denen ich mich um Identity Security kümmere, steht derzeit der Wechsel auf den neuen Defender for Identity Sensor v3 an. Die neue Sensorgeneration lässt sich direkt auf Domain Controllern aktivieren, die bereits in Defender for Endpoint (MDE) eingebunden sind. Damit entfällt die klassische Installation mit eigenem Setup-Paket, und das ist ein echter Fortschritt. Das klingt nach weniger Aufwand, doch wie so oft liegt die Tücke im Detail. Wer die Umstellung plant, sollte Voraussetzungen, Einschränkungen und den praktischen Ablauf kennen. Andernfalls stolpert man schnell über Probleme, mit denen man nicht gerechnet hat.

Ein paar Klicks im Portal ersetzen das Setup auf dem Domain Controller

Früher musste erst ein Setup auf dem Domain Controller ausgerollt werden, heute genügen ein paar Klicks in der Cloud. Im Microsoft Defender Portal wählt man unter System → Einstellungen → Identitäten → Aktivierung die gewünschten Domain Controller aus, die bereits mit MDE verbunden sind. Microsoft installiert dann im Hintergrund automatisch den Defender for Identity Sensor v3.x, und lokal muss man nichts anfassen – sofern die Bedingungen stimmen.

Praktisch ist das, weil man den Rollout zentral steuert und keine eigene Sensor-Software pflegen muss. Vor allem in größeren Umgebungen mit vielen Domain Controllern spart man Zeit und hat weniger Fehlerquellen. Die Aktivierung funktioniert allerdings nur auf Domain Controllern mit Windows Server 2019 oder neuer, die bereits in Defender for Endpoint eingebunden sind. Wer noch ältere DCs betreibt, schaut vorerst in die Röhre und muss für diese Server beim klassischen Sensor bleiben.

Nicht jeder Domain Controller lässt sich direkt migrieren

Wichtigste Voraussetzung für den Defender for Identity Sensor v3 ist Windows Server 2019, 2022 oder neuer; ältere Versionen wie 2016 werden nicht unterstützt. Außerdem muss der Domain Controller bereits als Gerät in Defender for Endpoint geführt sein, denn ohne dieses Onboarding kann Microsoft den Sensor nicht aus der Ferne ausrollen. Server mit Sonderrollen wie AD FS (Active Directory Federation Services) oder AD CS (Active Directory Certificate Services) bleiben ebenfalls außen vor. Auf ihnen muss der klassische Sensor installiert bleiben, weil dort bestimmte Protokollierungsanforderungen gelten.

Dazu kommt, dass der Sensor v3 einige erweiterte Funktionen (z. B. Eventtracing, Sensor-Profiling) noch nicht oder nur eingeschränkt beherrscht. Wer besonders detaillierte Analysen braucht, sollte in der offiziellen Microsoft-Dokumentation und bei den Voraussetzungen nachlesen, ob der neue Sensor schon alle Funktionen abdeckt, auf die der eigene Betrieb angewiesen ist.

Praxis-Tipp: Während des Rollouts von Sensor v3 sollte man die Health-Seite im Defender-Portal (Defender for Identity → Sensorzustand) regelmäßig kontrollieren. Typische Fehler wie „Prerequisite not met“ oder Kommunikationsprobleme tauchen dort schnell auf. Meist fehlt dann ein Update, das Gerät ist nicht eingebunden, oder es läuft schlicht die falsche Serverversion.

Dem Sensor v3 fehlen gegenüber dem klassischen Sensor noch einige Funktionen

Am stärksten unterscheiden sich die beiden Varianten darin, wie sie auf dem Server laufen. Der Defender for Identity Sensor v3 arbeitet als Zusatzfunktion im vorhandenen MDE-Agenten, der klassische Sensor wird dagegen als separater Windows-Dienst mit eigenem Updater installiert. Mehrere Windows-Installationen zu pflegen, ist damit nicht mehr nötig. Ein paar Einschränkungen gibt es allerdings noch:

• Keine Unterstützung für Server, die älter als Windows Server 2019 sind
• Keine Mehrinstanzfähigkeit auf AD-FS-/AD-CS-Servern
• Teils eingeschränkte Sensor-Logs (etwa bei sehr tiefgehender Fehlersuche)

Wer auf bestimmte forensische Funktionen angewiesen ist oder sehr spezielle Monitoring-Anforderungen hat, sollte genau prüfen, ob der neue Sensor schon alles Nötige mitbringt. Im Zweifel bleibt man vorerst beim klassischen Sensor.

In gemischten Umgebungen bleibt der klassische Sensor vorerst nötig

In der Praxis begegnen mir häufig hybride Umgebungen, in denen noch ältere Domain Controller (z. B. 2016) laufen oder sich einzelne AD-FS-/AD-CS-Server nicht auf den neuen Sensor umstellen lassen. Manchmal setzen außerdem Integrationen von Drittanbietern auf dem klassischen Sensor auf. In solchen Fällen empfehle ich den Parallelbetrieb. Neue DCs erhalten dann den Sensor v3 über das Defender-Portal, während die alten vorerst den klassischen Sensor behalten. Das kostet etwas mehr Aufwand, ist aber deutlich besser, als zu riskieren, dass ein DC ganz ohne Sensor läuft.

Die folgende Grafik zeigt schematisch, wie Microsoft die Aktivierung abwickelt, vom Onboarding als Voraussetzung bis zum einsatzbereiten Sensor:

flowchart TD
    DC["Domain Controller"] --> MDEOnboard["MDE Onboarding"]
    MDEOnboard --> Aktivierung["Sensor v3 Aktivierung (Portal)"]
    Aktivierung --> Bereitstellung["Automatische Bereitstellung"]
    Bereitstellung --> SensorAktiv["Sensor v3 aktiv"]
    DC -.-> ClassicSensor["Klassischer Sensor nötig" ]
    ClassicSensor -.-> SensorAktiv

Abbildung: Ablauf der Aktivierung des Defender for Identity Sensor v3 im Vergleich zur klassischen Variante.

Der Sensorzustand im Portal deckt Fehler früh auf

Unmittelbar nach der Aktivierung von Sensor v3 sollte man den Gesundheitsstatus kontrollieren. Im Defender-Portal unter Identitäten → Sensorzustand ist sofort zu sehen, ob ein Sensor nicht installiert werden konnte, ob es Kommunikationsprobleme gibt oder ob weitere Schritte nötig sind. Anhand der typischen Fehlercodes (z. B. „Unsupported OS“, „Device not onboarded“, „Role not supported“) lässt sich die Ursache schnell eingrenzen.

Welcher Sensor auf welchem Domain Controller läuft, zeigt das Defender-Portal unter „Identitäten → Sensoren“ im Detail an, einschließlich Sensorversion, Installationsdatum und aktuellem Status. Über diese Ansicht steuere ich in Projekten meist die Migration. Ich stelle einzelne DCs nacheinander um und prüfe nach jeder Aktivierung den Health-Report, bevor ich mir die nächsten Server vornehme.

Mit einer Mischstrategie gelingt der Umstieg ohne Schutzlücken

Der Defender for Identity Sensor v3 ist ohne Frage ein Schritt nach vorn. Er fügt sich besser in Defender for Endpoint ein und wird zentral verwaltet, außerdem fällt die aufwendige Installation weg. Das erleichtert Admins den Alltag spürbar. Die genannten Einschränkungen bei älteren DCs und Sonderrollen wie AD FS/AD CS sollte man trotzdem nicht unterschätzen. In vielen Tenants fahre ich derzeit am besten mit einer Mischstrategie, bei der neue, cloudverwaltete Domain Controller den Sensor v3 bekommen und für Legacy-Server der klassische Sensor Pflicht bleibt. Wer Migration und Health-Überwachung im Blick behält, nutzt die Vorteile des neuen Modells, ohne den Schutz bestehender Systeme aufs Spiel zu setzen.