Active Directory-Sicherheit auditieren: Was zuerst zu prüfen ist und wie sich Remediation nachweisen lässt

Wenn Sie active directory sicherheit auditieren wollen, sollten Sie mit belastbarer Evidenz statt mit einer generischen Checkliste beginnen. Ein verteidigbares Active-Directory-Audit muss zeigen, welche Identitäten das Verzeichnis kontrollieren können, welche Berechtigungen Geheimnisse replizieren oder Vertrauensgrenzen neu schreiben können, welche Protokoll- oder Zertifikatseinstellungen noch kurze Angriffspfade eröffnen und welche Nachweise Sie aufbewahren, damit sich Remediation später verifizieren lässt.

Dieser Leitfaden bleibt auf On-Prem Active Directory fokussiert. Wenn Ihre Operatoren, privilegierten Rollen oder Wiederherstellungsabläufe zusätzlich von Microsoft Entra abhängen, sollte diese Prüfung parallel zu einer separaten Entra-Bewertung durchgeführt werden, anstatt beide Bereiche in einem unscharfen Bericht zu vermischen. Das Ziel ist enger: zeigen, was ein AD-Audit zuerst abdecken muss, welche Findings früh priorisiert werden sollten und wie sich belegen lässt, dass eine Korrektur die Control Plane tatsächlich verändert hat.

Ein brauchbares AD-Audit sollte fünf Ergebnisse liefern:

1. ein abgegrenztes Inventar der wirklich relevanten Verzeichnisoberflächen
2. eine Liste von Identitäten und Berechtigungen, die privilegierte Assets kontrollieren oder Geheimnisse replizieren können
3. eine kürzere Liste von Angriffspfaden, die sofortige Remediation verlangen
4. Evidenz dafür, dass Hardening-Kontrollen in Produktion wirklich durchgesetzt sind
5. ein Validierungspaket, das sich mit dem nächsten Prüfzyklus vergleichen lässt

Active Directory-Sicherheit auditieren: Was bedeutet das eigentlich?

Ein Active-Directory-Audit ist weder nur eine Passwort-Policy-Prüfung noch ein einmaliger Gesundheitsbericht. Es ist eine evidenzbasierte Überprüfung der Identitäten, Berechtigungen, Dienste, Richtlinien und Telemetrie, die bestimmen, wer das Verzeichnis kontrollieren kann und wie schnell diese Kontrolle missbraucht werden könnte.

Das bedeutet, dass das Auditergebnis konkrete Fragen beantworten muss:

• Welche Benutzer, Gruppen, Service Accounts oder Computer haben domänenweite oder nahezu domänenweite Kontrolle?
• Welche Rechte können sensible Verzeichnisdaten replizieren oder Vertrauensgrenzen neu schreiben?
• Welche Protokoll- und Delegationseinstellungen senken die Angriffskosten für einen Angreifer?
• Welche Findings sind nur Konfigurationsdrift und welche eröffnen direkte Eskalationspfade?
• Welche Exporte, Logs und Zustands-Snapshots beweisen, dass eine Korrektur real ist?

Wenn die Prüfung diese Fragen nicht beantworten kann, bleibt sie eine Checkliste und ist noch kein Audit. Dieser Unterschied ist wichtig, weil eine Umgebung in einer Compliance-Tabelle akzeptabel aussehen und trotzdem kurze Pfade zu Domain Admin über Replikationsrechte, Delegation, veraltete privilegierte Konten oder Zertifikatsmissbrauch offenlassen kann.

Den Umfang festlegen, bevor Findings geprüft werden

Der schnellste Weg, Zeit zu verlieren, besteht darin, Findings zu prüfen, bevor der Umfang festgelegt ist.

Zwingende Scope-Entscheidungen

Zuerst muss entschieden werden, welche Verzeichnisoberflächen tatsächlich im Spiel sind:

• die geprüfte Domäne oder Gesamtstruktur
• Domain Controller und privilegierte Administrationsgruppen
• delegierte Admin-Gruppen und Service Accounts mit hoher Auswirkung
• Replikationsrechte, ACL-sensitive Objekte und Vererbungsgrenzen
• Kerberos-Delegation und die Exponierung von Service Principals
• Group Policy, LDAP-Posture, Windows LAPS und Audit Policy
• AD CS, aber nur wenn es in der Gesamtstruktur vorhanden ist

Der Scope muss ehrlich bleiben. Wenn AD CS nicht bereitgestellt ist, sollte es als außerhalb des Umfangs markiert werden und danach kann man weitergehen. Wenn ein separates PKI-Team dafür zuständig ist, AD CS aber in der Gesamtstruktur existiert, gehört es trotzdem ins Audit, weil Zertifikatsausstellung die privilegierte Exponierung weiterhin verändern kann. Dasselbe gilt für hybride Identität: Wenn Microsoft Entra privilegierte Operatoren, Recovery-Pfade oder App-Administration beeinflusst, sollte diese Abhängigkeit benannt werden, ohne zu behaupten, dass ein Entra-Review ein AD-Review ersetzt.

Welche Evidenz vor dem ersten Export feststehen muss

An dieser Stelle muss auch festgelegt werden, welche Nachweise zwischen den Zyklen aufbewahrt werden. Wenn das Audit später belegen soll, dass eine privilegierte Gruppe bereinigt oder ein gefährliches Recht entfernt wurde, muss diese Anforderung vor dem ersten Export feststehen.

Zuerst privilegierten Zugriff und Tier 0 prüfen

Beginnen Sie mit der Control Plane des Verzeichnisses, oft operativ als Tier 0 beschrieben. Das bedeutet, die Identitäten und Administrationspfade zu prüfen, die direkt die Domäne, die Domain Controller, Vertrauensgrenzen oder die Objekte verändern können, die diese schützen.

Was im ersten Durchlauf geprüft werden sollte

Mindestens geprüft werden sollten:

• eingebaute und benutzerdefinierte privilegierte Gruppen
• delegierte Admin-Gruppen und verschachtelte Gruppenpfade
• veraltete privilegierte Konten und alte Ausnahme-Konten
• privilegierte Service Accounts mit dauerhaftem Zugriff
• administrative Trennung zwischen normalen Benutzeridentitäten und Admin-Identitäten

Das ist der richtige Startpunkt, weil schlechte Administrationspraxis und schwache Segmentierung genau dort liegen, wo echte AD-Kompromittierungen Fuß fassen. Die ANSSI-Leitlinie von 2023 zur sicheren Administration von auf AD basierenden Informationssystemen sagt ausdrücklich, dass AD-Kompromittierungen aus schlechten Administrationspraktiken und unzureichender Segmentierung entstehen, und beschreibt anschließend, wie Angreifer laterale Bewegung und Privilegieneskalation nutzen, um die vollständige Kontrolle über das Verzeichnis zu übernehmen.

Was dieser Abschnitt beweisen muss

Der praktische Test ist einfach: Können Sie erklären, wer das Verzeichnis administriert, von wo aus, mit welchem Kontotyp und warum dieser Zugriff noch existiert? Wenn nicht, sollte das Audit zuerst hier stoppen. Ein Verzeichnis mit sauberer Passwort-Policy, aber schwachem privilegiertem Zugriffsdesign bleibt ein schwaches Verzeichnis.

Für verwandte Drift-Muster nutzen Sie Privileged Access Drift Active Directory: How Admin Rights Creep Back After Audits und Stale Privileged Accounts: Hidden Risk in Active Directory als ergänzende Reviews.

Replikationsrechte, ACL-Missbrauch und kurze Angriffspfade auditieren

Nach den privilegierten Gruppen sollten die Berechtigungen geprüft werden, die diese Gruppen still umgehen können. Ein ernsthaftes AD-Audit muss Principals mit geheimer Replikationsfähigkeit und breiter Kontrolle über sensible Objekte einschließen.

Rechte, die sofort geprüft werden sollten

Microsoft dokumentiert DS-Replication-Get-Changes-All als Control-Access-Right, das die Replikation geheimer Domänendaten erlaubt. Das reicht aus, um Replikationsrechte zu einem erstklassigen Auditthema zu machen und nicht zu einem exotischen Sonderfall. Wenn Sie nicht genau wissen, welche Principals replizierungsbezogene Rechte besitzen, ist das Audit unvollständig.

Dasselbe gilt für Objektkontrolle. Es geht nicht nur darum, offensichtliche Admin-Mitgliedschaften zu finden. Gesucht werden Schreib-, Berechtigungsverwaltungs- oder Besitzpfade auf hochkritische Objekte wie:

• die Domänenwurzel
• privilegierte Gruppen
• AdminSDHolder
• OUs, in denen sensible Administratoren, Server oder GPOs liegen
• mit GPOs verknüpfte Container, die die Sicherheitslage im großen Maßstab verändern können

Welche Telemetrie Änderungen validieren hilft

Logging ist hier wichtig, muss aber präzise beschrieben werden. Event 5136 wird erzeugt, wenn ein Verzeichnisdienstobjekt geändert wird, aber nur dann, wenn das Objekt die passende SACL enthält. Event 4662 protokolliert Operationen auf einem AD-Objekt, aber ebenfalls nur dann, wenn die passende SACL vorhanden ist und die Operation sie auslöst. Keines dieser Events ist ein magischer Detector. Es sind Evidenzpunkte, mit denen sich hochkritische Änderungen validieren und konkrete Objekte überwachen lassen, nachdem der Scope korrekt gesetzt wurde.

Genau deshalb ist Angriffspfad-Denken wichtig. Die Frage ist nicht nur, ob ein Recht existiert. Die eigentliche Frage lautet, ob dieses Recht einen kurzen Pfad zur Verzeichniskontrolle eröffnet. Für eine tiefere Pfadprüfung ergänzen Sie das Audit mit ACL Abuse and DCSync: The Silent Paths to Domain Admin und Active Directory Attack Paths to Domain Admin.

Kerberos, Delegation und Service-Account-Exponierung prüfen

Kerberos bleibt zentral für die AD-Exponierung, insbesondere über Service Accounts und Delegationseinstellungen.

Welche Konten und Einstellungen zuerst geprüft werden sollten

Mindestens geprüft werden sollten:

• Benutzer- oder Service-Accounts mit SPNs
• privilegierte Konten, die ebenfalls SPNs exponieren
• unconstrained delegation
• constrained delegation und resource-based constrained delegation, wenn sie verwendet werden
• Service Accounts ohne klaren Owner, ohne aktuelle Review oder mit übermäßigen Rechten

Warum Service-Account-Exponierung zum Kernaudit gehört

SPN-tragende Konten gehören in den Scope, weil Kerberoasting von Service Tickets für diese SPNs abhängt. Deshalb bleibt MITRE ATT&CK T1558.003 ein nützlicher Detection-Kontext für ein technisches Audit. Das Audit braucht keinen Exploit-Walkthrough. Es muss aber zeigen, welche Service Accounts Offline-Cracking-Potenzial bieten und ob einige davon zusätzlich privilegiert sind.

Delegation braucht dieselbe Präzision. Microsoft beschreibt constrained delegation als restriktivere Form der Delegation als unconstrained delegation, weil sie die Dienste begrenzt, zu denen ein Server im Namen eines Benutzers handeln darf. Das macht constrained delegation nicht automatisch sicher. Es bedeutet nur, dass sie im Kontext geprüft werden muss: welche Frontend-Dienste erlaubt sind, welche Back-End-Dienste ihnen vertrauen und ob der fachliche Bedarf noch besteht.

Wenn Sie die delegationsspezifische Detailanalyse brauchen, verwenden Sie Kerberos Delegation Attacks: From Unconstrained to RBCD Abuse. Im Audit selbst sollte der Fokus auf Ownership, Privileg und erreichbaren Missbrauchspfaden liegen.

AD CS einbeziehen, wenn es in der Gesamtstruktur existiert

Wenn Active Directory Certificate Services irgendwo in der Gesamtstruktur bereitgestellt ist, muss es einbezogen werden. Microsoft dokumentiert AD CS als Windows-Server-Rolle zum Ausstellen und Verwalten von PKI-Zertifikaten, die in sicheren Kommunikations- und Authentifizierungsprotokollen verwendet werden. Das reicht aus, um AD CS als Identitätsinfrastruktur zu behandeln und nicht als Randthema für eine spätere PKI-Prüfung.

Was der AD-CS-Teil abdecken sollte

Ein brauchbares AD-Audit sollte daher prüfen:

• Enterprise CAs, die für Authentifizierung relevante Zertifikate ausstellen
• veröffentlichte Zertifikatvorlagen
• wer enrollen darf und wer Vorlagenberechtigungen ändern kann
• ob Zertifikatsausstellung die privilegierte Exponierung erweitert
• ob Zertifikatspfade Eskalationsrouten erzeugen, die bereits geleistete Arbeit an Gruppen und Delegation umgehen

Man darf nicht annehmen, dass jede AD-Umgebung AD CS hat. Wenn AD CS aber vorhanden ist, darf es nicht aus dem Audit herausfallen. Zertifikatsausstellung und Vorlagenberechtigungen können materiell verändern, wer sich authentifizieren darf und als wen. Für die technische Detailanalyse siehe ADCS Certificate Attacks: How ESC1 to ESC8 Lead to Domain Admin.

GPO, LDAP, LAPS und Logging-Kontrollen prüfen

Sobald privilegierte Pfade und Eskalationsmechanismen verstanden sind, sollten die Kontrollen geprüft werden, die die Umgebung härten und die Telemetrie erzeugen sollen, auf die sich das Team stützt.

Kontrollen, die direkt validiert werden müssen

Für LDAP erklärt Microsoft, dass LDAP signing LDAP-Kommunikation kryptographisch signiert, um Authentizität und Integrität zu prüfen, während channel binding die Anwendungssicherheit an die zugrunde liegende TLS-Sitzung bindet. Praktisch heißt das: Das Audit muss die tatsächlich wirksame Domain-Controller-Policy prüfen und nicht nur den beabsichtigten Zielzustand. Das ist gerade deshalb wichtig, weil Microsoft die Versionsgrenzen klar dokumentiert: Neue Active-Directory-Bereitstellungen auf Windows Server 2025 verlangen LDAP signing standardmäßig, während aktualisierte Umgebungen ihre bestehende Policy behalten. Das bedeutet, dass die effektive Posture geprüft werden muss und nicht einfach ein Default angenommen werden darf. Für Konfigurations- und Validierungsdetails siehe LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

Für Windows LAPS dokumentiert Microsoft, dass die Funktion lokale Administratorpasswörter automatisch verwaltet und sichert und auch das DSRM-Passwort von Active-Directory-Domain-Controllern sichern kann. Ein AD-Audit sollte daher nicht nur prüfen, ob LAPS vorhanden ist, sondern auch, ob die vorgesehene Population abgedeckt ist, wo die Passwörter gesichert werden, wer sie lesen darf und ob DSRM-Schutz dort konfiguriert ist, wo er benötigt wird. Für die operative Lücke siehe Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter.

Logging, das Kontrolländerungen belegt

Beim Logging muss die Formulierung präzise bleiben:

• Audit Security Group Management deckt Änderungen wie Erstellung, Löschung sowie Hinzufügen und Entfernen von Gruppenmitgliedern ab.
• Event 5136 hilft, Objektänderungen zu validieren, wenn die richtige SACL existiert.
• Event 4662 hilft, Operationen auf sensiblen AD-Objekten zu überwachen, wenn Directory Service Access Auditing und die SACLs korrekt konfiguriert sind.

Microsoft erklärt außerdem, dass advanced audit policy settings über Group Policy verwaltet werden können, damit Organisationen granulareres Auditing für die Benutzer und Gruppen planen, testen und ausrollen können, die wirklich zählen. Das ist die richtige operative Haltung: Policy testen, Event-Volumen und Aufbewahrung bestätigen und verifizieren, dass das Team die entstehende Evidenz tatsächlich auswertet. Für die Ereignisse, die nach dem Rollout am wichtigsten sind, siehe Active Directory Monitoring: Security Event IDs That Matter.

Evidenz, die zwischen Auditzyklen aufbewahrt werden sollte

Ein nützliches AD-Audit hinterlässt ein wiederverwendbares Evidenzpaket und nicht nur ein Folienset.

Minimales Evidenzpaket

Zu jedem Artefakt sollten Datum, Scope, Quelle und Owner gespeichert werden. Wenn das nächste Audit nicht denselben Typ von Exporten vergleichen kann, verbringt das Team Zeit damit zu diskutieren, ob ein Finding neu ist, anstatt zu beweisen, dass ein Pfad verschwunden ist.

Remediation nach Identitätsauswirkung priorisieren

Es sollte nicht in einer flachen Queue remediated werden. Begonnen werden muss mit dem, was die Reichweite eines Angreifers am direktesten verändert.

Fixes, die meist zuerst kommen sollten

Remediations mit erster Priorität umfassen typischerweise:

• replikationsbezogene Rechte, die geheime Domänendaten exponieren können
• ACL- oder Vererbungspfade, die kurze Wege zu privilegierten Objekten eröffnen
• unconstrained delegation und stark exponierte privilegierte Service Accounts
• AD-CS-Fehlkonfigurationen, die Authentifizierungs- oder Enrollment-Missbrauch ermöglichen

Kontrollen, die den nächsten Zyklus stärken

Danach kommen Kontrollen, die die Freiheit des Angreifers einschränken und künftige Validierung verbessern:

• LDAP-signing- und channel-binding-Posture
• Windows-LAPS-Abdeckung und privilegierte Passwort-Hygiene
• Lücken in der Audit Policy, durch die hochkritische Objekte faktisch unüberwacht bleiben

Erst danach sollte Energie in Bereinigungen fließen, die die Governance verbessern, aber einen Angriffspfad für sich genommen nicht wesentlich verkürzen. Genau deshalb ist eine wiederholbare Prüfung wertvoller als ein statischer Bericht. Recurring AD Audit Workflow: Why Annual Audits Drift and How Continuous Posture Monitoring Works behandelt das Betriebsmodell, während Active Directory Security Audit Tools: What to Compare Before You Choose die Toolfrage behandelt.

Validierung nach der Remediation

Ein Finding ist nicht deshalb geschlossen, weil ein Ticket sagt, dass es geschlossen ist. Validiert werden muss von derselben Kontrolloberfläche aus, die das Problem offengelegt hat.

Nach einer Bereinigung privilegierter Zugriffe sollten Gruppen- und Delegations-Exporte erneut ausgeführt und bestätigt werden, dass die Identität den effektiven Pfad nicht mehr besitzt. Nach dem Entfernen von Replikationsrechten muss bestätigt werden, dass der Principal nicht mehr im Replikations-Review-Set auftaucht. Nach LDAP-Hardening muss die wirksame Policy überprüft und validiert werden, dass unsignierte Binds wie erwartet abgewiesen werden. Nach einem Windows-LAPS-Rollout müssen Policy-Anwendung und Passwort-Backup-Zustand für die Zielpopulation bestätigt werden. Nach einem AD-CS-Fix muss geprüft werden, dass die riskante Vorlage, der Enrollment-Scope oder der Berechtigungspfad tatsächlich verschwunden sind.

Was ein geschlossenes Finding enthalten sollte

Auch die Telemetrie muss validiert werden. Wenn Sie erwarten, dass künftige Änderungen an sensiblen Objekten 5136- oder 4662-Evidenz erzeugen, muss belegt werden, dass das SACL-Modell und die Audit Policy die vorgesehenen Events wirklich generieren. Wenn Gruppenänderungen wichtig sind, muss belegt werden, dass die relevanten Gruppenmanagement-Events im Logging-Pfad vorhanden sind und lange genug aufbewahrt werden, um nützlich zu sein.

Das finale Abschluss-Paket sollte enthalten:

• den Zustand davor und danach
• den Owner der Änderung
• die Validierungsmethode
• die verbleibende Ausnahme, falls es eine gibt
• das Datum, an dem das Finding erneut geprüft wird

Das ist es, was ein AD-Audit in eine wiederholbare Kontrolle verwandelt statt in ein Dokument, das im Moment der nächsten Delegationsänderung veraltet.

Wie EtcSec hilft, ein wiederholbares AD-Audit zu strukturieren

EtcSec sollte in diesen Workflow eingebettet sein und ihn nicht mit Marketing-Sprache ersetzen. Der nützliche Teil ist die Wiederholbarkeit.

Wo das Produkt passt und wo nicht

Ein wiederholbares AD-Audit braucht dieselben Prüfungen auf denselben Kontrolloberflächen, damit sichtbar wird, ob ein privilegierter Pfad neu ist, unverändert bleibt oder wirklich remediated wurde. EtcSec hilft, das zu strukturieren, indem es die Prüfung auf konkrete Findings wie EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION, ESC1_VULNERABLE_TEMPLATE, PATH_ACL_TO_DA, LDAP_SIGNING_DISABLED und LAPS_NOT_DEPLOYED fokussiert.

Das aktuelle Bereitstellungsmodell unterstützt außerdem lokale Erfassung, anstatt das Audit als reines SaaS-Exercise zu erzwingen. Das ist operativ relevant, weil AD-Evidenz besser ist, wenn der Erfassungspfad stabil bleibt, dieselben Kontrollen nach der Remediation erneut gemessen werden und die Ergebnisse zwischen den Zyklen aufbewahrt werden können.

Der praktische Wert bleibt deshalb eng und überprüfbar: das Audit strukturieren, die Findings messbar halten und Wiederholungsläufe besser verteidigbar machen. Wenn es eher um Toolauswahl als um Auditmethode geht, nutzen Sie Active Directory Security Audit Tools: What to Compare Before You Choose.

Primärquellen

• Audit Security Group Management
• 5136(S): A directory service object was modified
• 4662(S, F): An operation was performed on an object
• DS-Replication-Get-Changes-All extended right
• LDAP signing for Active Directory Domain Services
• Manage LDAP signing using Group Policy for Active Directory Domain Service
• What is Windows LAPS?
• Kerberos Constrained Delegation Overview in Windows Server
• What is Active Directory Certificate Services?
• Advanced Audit Policy Configuration
• Audit Active Directory objects in Windows Server 2003
• Recommandations pour l’administration sécurisée des SI reposant sur AD
• MITRE ATT&CK T1558.003: Kerberoasting