Was ein AD/Entra-Hybrid-Audit wirklich prüft und warum die meisten Teams beim ersten Mal scheitern
Was ein AD/Entra-Hybrid-Audit wirklich prüft und warum die meisten Teams beim ersten Mal scheitern
Oct 2, 2026
Die meisten AD-Bereinigungsprozesse enden an der Domänengrenze, hybride Audits jedoch nicht. Erfahren Sie, was Prüfer in Active Directory und Entra ID tatsächlich kontrollieren und welche Lücken Teams bei ihrer ersten Prüfung zum Verhängnis werden.
Fragt man einige IT-Teams, wie sie das Offboarding handhaben, hört man immer dieselbe Antwort: das Konto in Active Directory deaktivieren, das Ticket schließen und weitermachen.
Dann ruft ein Prüfer das Entra-ID-Inventar ab und stellt fest, dass dieses Konto noch immer aktiviert und weiterhin der Anwendungsrolle zugewiesen ist, die es am ersten Tag hatte. Bei der Synchronisierung wurde die Änderung übersehen, es wurde keine Warnung ausgelöst, weil keine konfiguriert war, und beide Verzeichnisse meldeten ein fehlerfreies Konto. Sie waren sich lediglich über dessen Status uneinig.
Ähnliche Aussagen höre ich oft von Teams, die bis zu ihrem ersten hybriden Audit überzeugt waren, ihre Identitätshygiene im Griff zu haben.
„Unsere AD-Hygiene ist gewährleistet“ ist nicht dasselbe wie „Wir bestehen ein Hybrid-Audit“
Die meisten Teams verfügen über eine Form von AD-Bereinigungsprozess: vierteljährliche Überprüfungen inaktiver Konten, Audits privilegierter Gruppen und Kontrollen der Kennwortrichtlinien. Das ist ein echter Prozess, der in der Regel funktioniert … für Active Directory.
Die meisten veröffentlichten Empfehlungen zur AD-Sicherheit zielen darauf ab, AD durch Patches, die Einteilung von Administratorkonten in Sicherheitsstufen und das Schließen von Delegierungspfaden gegen Angreifer zu härten. Das sind sinnvolle Maßnahmen, doch sie beantworten nicht die Frage, die ein Prüfer tatsächlich stellt. Geprüft wird nicht, ob Ihr Verzeichnis einen Angriff überstehen würde. Geprüft wird, ob Ihre Identitätsdaten als Beweismittel Bestand haben, wenn sie im Nachhinein überprüft werden.
Das Problem liegt im Umfang. Dieser Prozess ist fast immer auf das lokale AD beschränkt, weil dort die Tools, die Zuständigkeiten und die etablierten Abläufe angesiedelt sind. Prüfer grenzen ihre Prüfungen jedoch anders ab: Sie betrachten die Identität so, wie sie überall dort existiert und funktioniert, wo sie genutzt werden kann. In einer hybriden Microsoft-Umgebung schließt das auch die synchronisierte Entra-ID-Seite ein.
Das ist die Lücke zwischen dem, was Sicherheitsteams für geprüft halten, und dem, was ein Auditor tatsächlich heranzieht:
- Was Teams üblicherweise überprüfen: AD-Kontohygiene, Einhaltung der Passwortrichtlinien und Mitgliedschaft in privilegierten AD-Gruppen.
- Was Prüfer tatsächlich abrufen: all das sowie Synchronisierungsstatus und -verzögerung, Abweichungen bei Berechtigungen zwischen den beiden Verzeichnissen, einen Änderungsverlauf für die Synchronisierungskonfiguration selbst und sämtliche Berechtigungen, die in Entra bestehen, ohne dass es ein lokales Gegenstück gibt, mit dem sie abgeglichen werden können. Auch die Standards bestätigen dies: Sowohl die Kriterien für logischen Zugriff in SOC 2 (CC6.1-CC6.3) als auch die Zugriffskontrollen in ISO 27001:2022 (A.5.15, A.5.18 und A.8.2 zum privilegierten Zugriff) verlangen, dass der Zugriff in seinem tatsächlichen Zustand überprüft wird, nicht so, wie ein einzelnes System ihn darstellt. Genau darin liegt der blinde Fleck einer reinen AD-Betrachtung, den die meisten Teams in eine hybride Prüfung mitnehmen.
Teams bestehen die AD-Hälfte dieser Liste und werden von der Entra-Hälfte überrascht, weil sie einen Hygieneprozess aus der AD-Ära auf eine Umgebung der Hybrid-Ära anwenden, nicht, wie sie nachlässig sind.
Die fünf Dinge, die ein Prüfer in Woche eins anfordert
- Synchronisierungsverzögerung und -abweichung: Das Konto ist in AD deaktiviert, verfügt in Entra aber weiterhin über privilegierte Rechte, weil die Synchronisierung noch nicht ausgeführt wurde, unvollständig war oder unbemerkt einen Bereich ausschließt, für den sie nie konfiguriert wurde. Prüfer verlangen einen Abgleich, keine Momentaufnahme, doch die meisten Teams haben noch nie einen solchen erstellt. Kein Anbieter oder Analyst veröffentlicht eine Gesamtquote dazu, wie häufig dies vorkommt, weil niemand die Lücke misst, die Sie schließen sollen. Nur durch den Abgleich erfahren Sie, wo Sie stehen.
- Ein Änderungsverlauf für die Synchronisierungskonfiguration selbst: Sie müssen wissen, wer wann den Synchronisierungsumfang oder die Filterregeln geändert hat. Das ist wichtig, weil es sich bei realen Vorfällen um einen dokumentierten Wendepunkt handelt und nicht nur um ein Kästchen auf einer Audit-Checkliste. Microsoft beschreibt in seinem eigenen Bericht vom August 2025 über die Ransomware-Gruppe Storm-0501 genau dieses Vorgehen: Die Angreifer kompromittierten einen nicht überwachten Entra Connect Sync-Server, extrahierten die Anmeldedaten des Verzeichnissynchronisierungskontos und setzten anschließend das lokale Passwort des Zielbenutzers zurück. Entra Connect Sync übertrug diese Änderung daraufhin ordnungsgemäß und legitim an die Cloud-Identität und verschaffte ihnen so ein synchronisiertes Konto mit der Rolle „Globaler Administrator”, das nie für MFA registriert worden war. Der Synchronisierungsmechanismus tat genau das, wofür er entwickelt worden war, allerdings im Auftrag eines Angreifers, der den einen Server gefunden hatte, den niemand überwachte. Wenn es für Ihre Synchronisierungskonfiguration und die zugehörigen administrativen Anmeldedaten kein Änderungsprotokoll gibt, können weder Sie noch ein Auditor dieses Szenario ausschließen. Es handelt sich auch nicht um ein isoliertes Muster: Die gemeinsame Warnmeldung von CISA, FBI, RCMP, ASD und NCSC-UK zur Gruppe Scattered Spider dokumentiert bei mehreren Opfern dasselbe grundlegende Vorgehen: Ein über den Helpdesk veranlasstes Zurücksetzen von Anmeldedaten oder MFA wurde genutzt, um über den hybriden Synchronisierungspfad in privilegierte Cloud-Rollen vorzudringen.
- Reine Cloud-Berechtigungen ohne lokale Entsprechung: Rollen oder Gruppenmitgliedschaften, die direkt in Entra zugewiesen werden und nie mit AD in Berührung kommen, bleiben für alle Prüfprozesse unsichtbar, die weiterhin auf AD ausgerichtet sind. Sie können ebenso leicht versehentlich erstellt wie vollständig vergessen werden.
- Die eigenen Berechtigungen des Synchronisierungs-/Dienstkontos: Das Konto, unter dem Ihr Connect-Sync- oder Cloud-Sync-Prozess ausgeführt wird, verfügt häufig dauerhaft über mehr Berechtigungen als jedes menschliche Konto in der Umgebung. Bei einer routinemäßigen AD-Überprüfung wird es meist am wenigsten untersucht, weil es nicht wie ein „Benutzer“ aussieht.
- Eine lückenlose Nachweiskette auf beiden Seiten, nicht nur zum aktuellen Stand: Prüfer möchten sehen, wer was wann geändert hat, und zwar in beiden Verzeichnissen. Die meisten Teams können einen übersichtlichen Bericht zum aktuellen Stand erstellen, doch deutlich weniger können einen Bericht vorlegen, der tatsächlich die Grenze zwischen AD und Entra überbrückt.
Wer ist für die Lücke verantwortlich?
AD liegt in der Regel in der Verantwortung eines Infrastruktur- oder Identitätsteams, Entra hingegen in der eines Cloud- oder M365-Teams. Diese Aufteilung der Zuständigkeiten ist das Problem, nicht eine Lücke bei den Tools. Die Auditvorbereitung übernimmt diese Trennung standardmäßig. Das bedeutet, dass jedes Team einen einwandfreien Bericht vorlegen kann, allerdings nur für seinen Teil.
Anstatt diese Lücke zu schließen, verstärken die nativen Tools sie noch. Das Active Directory Administrative Center bildet AD übersichtlich ab, das Entra Admin Center wiederum Entra. Keines von beiden zeigt, was zwischen den Systemen geschieht, da keines dafür zuständig ist.
Das Audit scheitert nicht an einem unsauberen Verzeichnis, sondern daran, dass es zweigeteilt ist und niemand die Lücke dazwischen verantwortet.
Was diese Woche zu prüfen ist
Sie müssen nicht auf eine Prüfungsankündigung warten, um zu wissen, wo Sie stehen. Vor Ihrer nächsten Prüfung:
- Rufen Sie Ihre Synchronisierungsfehlerprotokolle ab: nicht nur die Zusammenfassung zu Erfolg oder Fehlschlag, sondern auch, ob ein Auftrag trotz teilweiser oder unbemerkter Fehler als „erfolgreich“ gilt.
- Vergleichen Sie die Mitgliedschaft in privilegierten Gruppen direkt zwischen AD und Entra, statt beide Seiten einzeln zu prüfen.
- Erfassen Sie die Berechtigungen Ihrer Synchronisierungs- und Dienstkonten genauso wie bei einem menschlichen Administratorkonto.
- Aufbewahrung des Änderungsverlaufs bestätigen ist auf beiden Seiten vorhanden und vergleichbar, nicht nur der aktuelle Stand, sondern auch der Verlauf.
- Prüfen Sie auf reine Cloud-Rollenzuweisungen, für die es keine entsprechende AD-Zuweisung zum Vergleich gibt.
Für keine dieser Maßnahmen sind zunächst neue Tools erforderlich. Allerdings muss jemand den Vergleich über beide Verzeichnisse hinweg durchführen, anstatt jedes einzeln zu prüfen.
Was das für Sie bedeutet
Ein hybrides AD-/Entra-Audit prüft etwas grundlegend anderes als ein reines AD-Audit und ist daher nicht einfach nur eine schwierigere Variante derselben Prüfung. Die meisten Teams gehen dennoch mit einer reinen AD-Checkliste an die Sache heran. Deshalb bringt das erste Audit häufig Befunde ans Licht, mit denen niemand gerechnet hat.
Netwrix Directory Manager weist Sie zwar nicht auf diese Synchronisierungslücke hin, kann Ihnen aber den Großteil der oben beschriebenen manuellen Abstimmungsarbeit abnehmen, sodass Sie die Informationen nicht selbst mühsam zusammentragen müssen. Sie erhalten eine zentrale Übersicht über den Lebenszyklus von Gruppen, deren Verantwortliche und die Administratoraktivitäten in AD, Entra ID und Google Workspace, einschließlich eines integrierten Audit-Trails für Administratoraktionen. Damit haben Sie bereits einen Vorsprung bei der Zusammenstellung der Nachweise, die ein Auditor anfordern wird.
Teilen auf
Erfahren Sie mehr
Über den Autor
Dave Miles
David Miles ist ein erfahrener Produktmanager bei Netwrix und leitet die Produktstrategie für Netwrix Directory Manager (NDM) im Identity- und Access-Management-Portfolio des Unternehmens.
Mit mehr als zwei Jahrzehnten Erfahrung in den Bereichen Identität und Cybersicherheit bringt David eine praktische Perspektive auf die Herausforderungen mit, denen Organisationen bei der Verwaltung von Identitäten, der Sicherung des Zugriffs und der Risikominderung in komplexen Unternehmensumgebungen gegenüberstehen.
Im Laufe seiner Karriere hat David an der Schnittstelle von Technologie, Sicherheit und Produktstrategie gearbeitet und leitende Positionen bei Arctic Wolf, One Identity, Dell und Quest Software innegehabt. Seine Erfahrung umfasst Produktführung, Softwareentwicklung, Kundenbindung und Markteinführung, was ihm eine breite Perspektive auf die technischen und geschäftlichen Herausforderungen der Unternehmens-Identitätssicherheit gibt.
David arbeitet regelmäßig mit Kunden und Technologieteams weltweit zusammen, um aufkommende Identitätsherausforderungen zu verstehen und in praktische Produktstrategien und -lösungen umzusetzen.
Er lebt in Somerset, Großbritannien.
Erfahren Sie mehr zu diesem Thema
Systemprotokolle: Wie man einen KI-Agenten von einem menschlichen Hacker unterscheidet
Netwrix Auditor in zwei Capterra-Shortlists 2026 aufgenommen
NIST CSF 2.0: Was ist neu im Cybersecurity Framework
Markt für Lösungen im Bereich Privileged Access Management: Leitfaden 2026
Datenschutzgesetze der Bundesstaaten: Unterschiedliche Ansätze zum Datenschutz