Ein Active-Directory-Sicherheitsaudit sollte mehr leisten, als nur Fehlkonfigurationen aufzulisten. Es sollte Ihrem Team helfen, drei praktische Fragen zu beantworten:
- Welche Findings exponieren Tier 0 oder privilegierte Identitäten?
- Welche Pfade lassen sich als Nächstes realistisch missbrauchen?
- Welche Behebungen sollten zuerst umgesetzt werden?
Wenn Sie den kürzesten Weg wollen, starten Sie mit einem dedizierten Workflow für Active Directory security audit und führen Sie den Collector lokal über ETC Collector aus. Wenn Sie zuerst die vollständige Prüfliste wollen, nutzen Sie den Leitfaden unten.
1. Mit privilegierten Identitäten und Tier 0 beginnen
Die meisten AD-Auditprogramme verlieren Zeit, weil sie mit allgemeiner Hygiene statt mit privilegierter Exposition starten. Die erste Prüfrunde sollte sich konzentrieren auf:
- Domain Admins, Enterprise Admins, Schema Admins und andere eingebaute privilegierte Gruppen
- delegierte Admin-Pfade
- Konten mit Replikationsrechten
- privilegierte Konten mit veralteten Passwörtern oder schwachen Schutzmaßnahmen
adminCount-Anomalien und verwaiste Schutzmechanismen
In diesem Teil des Audits möchten Sie wissen, welche Identitäten domänenweite Vertrauensgrenzen verändern können, nicht nur welche Einstellungen unordentlich wirken.
2. Kerberos- und Delegationspfade prüfen
Kerberos-Schwächen treiben weiterhin viele hochkritische AD-Findings. Ein praxisnahes Audit sollte prüfen:
- kerberoastbare Konten
- AS-REP-roastbare Konten
- unbeschränkte Delegation
- eingeschränkte Delegation mit riskanten Zielen
- Missbrauch resource-based constrained delegation
- privilegierte Konten mit SPNs
- Konten, die noch auf schwache Verschlüsselung angewiesen sind
Diese Prüfungen sind wichtig, weil sie direkt mit Credential Theft, Lateraler Bewegung und Privilegieneskalation verbunden sind.
3. Kennwortrichtlinie und Kontohygiene prüfen
Die Prüfung von Kennwortrichtlinien bleibt sinnvoll, sollte aber immer mit Exposition und Remediation-Impact verbunden werden. Fokussieren Sie sich auf:
- password never expires
- password not required
- reversible encryption
- veraltete privilegierte Konten
- deaktivierte Konten in Admin-Gruppen
- schwache Abdeckung durch Fine-Grained Password Policies
Wenn Ihre Umgebung noch Ausnahmen enthält, dokumentieren Sie, ob sie begründet, temporär und einem klaren Owner zugewiesen sind.
4. ADCS und Zertifikatsmissbrauch auditieren
ADCS wird in internen Reviews oft übersehen, obwohl es direkte Eskalationspfade schaffen kann. Ihr Audit sollte abdecken:
- verwundbare Zertifikat-Templates
- gefährliche Template-ACLs
- Enrollment-Agent-Missbrauch
- schwaches Certificate Mapping
- riskante CA-Flags und RPC-Einstellungen
Wenn Ihr aktueller Prozess keine ESC-artigen Zertifikatsangriffe bewertet, bleibt das Audit für moderne AD-Verteidigung unvollständig.
5. ACLs, Replikationsrechte und Attack Paths untersuchen
Eine rohe ACL-Prüfung allein reicht nicht. Sie müssen verstehen, welche Berechtigungen sich zu einem sinnvollen Missbrauch verketten lassen. Ein starkes Audit sollte sichtbar machen:
- Missbrauch von
GenericAll,WriteDacl,WriteOwnerund erweiterten Rechten - Replikationsrechte und DCSync-fähige Principals
- gefährliche Berechtigungen auf OUs, GPOs und AdminSDHolder
- Attack Paths, die domänenweite Assets in ein bis zwei Schritten erreichen
Hier zeigt sich der Unterschied zwischen tiefer Analyse und einem einfachen Posture-Check.
6. GPOs, Logging und Hardening einbeziehen
Group Policy und Hardening des Kontrollpfads liefern weiterhin wertvolle schnelle Verbesserungen. Prüfen Sie:
- zu schwache Kennwortrichtlinien in der Default Domain Policy
- fehlendes LDAP Signing oder Channel Binding
- fehlendes PowerShell-Logging
- unzureichendes UNC Path Hardening
- gefährliche Logon-Skripte
- schwache SMB- und TLS-Konfigurationen auf Domain Controllern
Solche Findings wirken oft operativ, sind aber genau die Kontrollen, die die Angriffskosten in der Praxis verändern.
7. Remediation nach Identitätsauswirkung priorisieren
Bearbeiten Sie Remediation nicht in einer flachen Liste. Gruppieren Sie die Ergebnisse nach Wirkung:
- kritisch: direkte privilegierte Exposition, Attack-Path-Abkürzungen, Zertifikatsmissbrauch, DCSync-Fähigkeit
- hoch: Delegationsmissbrauch, roastbare privilegierte Konten, riskante ACLs, Legacy Auth oder schwache Protokolleinstellungen
- mittel: Hygiene- und Policy-Drift, die die Angriffsfläche vergrößern
- niedrig: informatives Cleanup mit geringer Ausnutzbarkeit
Wenn Sie einen Workflow brauchen, der nach diesem Modell arbeitet, zeigt die Seite Active Directory security audit, wie sich die Review strukturieren lässt. EtcSec pricing erklärt außerdem, wann eine SaaS-Nachverfolgung zusätzlich zu ETC Collector sinnvoll wird.
8. Die Prüfung nach Änderungen wiederholen
Ein AD-Audit sollte kein einmal jährliches Artefakt sein. Wiederholen Sie dieselben Checks nach:
- Rollenänderungen
- GPO-Updates
- Änderungen an Certificate Services
- Änderungen an delegierter Administration
- Fusionen, neuen Standorten oder neuen Domänen
Genau deshalb prüfen Teams auch eine PingCastle alternative: Häufig ist nicht der erste Bericht das Problem, sondern das Fehlen eines wiederholbaren Prüfprozesses danach.
Fazit
Ein wirksames AD-Sicherheitsaudit ist eine wiederholbare Prüfung privilegierter Exposition und nicht nur ein Gesundheitsbericht. Beginnen Sie mit Tier 0, Kerberos, Delegation, ADCS und ACL-Missbrauchspfaden. Priorisieren Sie die Remediation anschließend danach, was die Reichweite eines Angreifers tatsächlich verändert.
Wenn Sie einen dedizierten Workflow möchten, starten Sie mit der Seite Active Directory security audit oder sehen Sie sich an, wie ETC Collector die technische Sammlung lokal ausführt.
9. Ein Nachweispaket für jeden Review-Zyklus aufbauen
Ein nützliches AD-Audit wird schneller und konsistenter, sobald das Team sich auf ein wiederholbares Nachweispaket einigt. Statt bei jeder Administratoränderung wieder ad hoc zu prüfen, sollte vorab festgelegt werden, welche Exporte, Screenshots und Verzeichnis-Snapshots in jeder Review-Runde gesammelt werden. So lassen sich Zyklen leichter vergleichen, Remediation-Prioritäten besser begründen und offene Findings sauber erklären.
| Review-Bereich | Zu sammelnde Nachweise | Warum das wichtig ist |
|---|---|---|
| Privilegierter Zugriff | Mitglieder von Domain Admins, Enterprise Admins, Operator-Gruppen und delegierten Admin-Gruppen | Zeigt die kürzesten Wege zu Tier 0 und macht zu breite Zugriffe sichtbar |
| Kerberos und Delegation | Konten mit SPNs, AS-REP-roastbare Konten, unconstrained Delegation und riskante constrained Delegation | Verknüpft Fehlkonfigurationen mit Credential Theft und lateral movement |
| Replikation und ACL-Missbrauch | DCSync-fähige Principals und gefährliche ACLs auf OUs, GPOs, AdminSDHolder und kritischen Gruppen | Macht Missbrauchspfade sichtbar, die auf den ersten Blick nicht privilegiert wirken |
| ADCS | Aktive CAs, veröffentlichte Templates, riskante Template-Berechtigungen und Enrollment-Agent-Exposure | Deckt zertifikatsbasierte Eskalation ab, die intern oft übersehen wird |
| Hardening und Logging | LDAP Signing, Channel Binding, PowerShell Logging, SMB-Einstellungen und Script-Exposure | Bestätigt, ob kompensierende Kontrollen die Handlungsfreiheit eines Angreifers wirklich begrenzen |
Der Sinn dieses Nachweispakets ist nicht Bürokratie, sondern Vergleichbarkeit. Wenn in jedem Zyklus dieselben Daten exportiert werden, wird die Review belastbar. Das Team kann dann zeigen, ob ein privilegierter Pfad neu ist, unverändert bleibt oder nur teilweise behoben wurde, statt aus dem Gedächtnis zu argumentieren. Außerdem wird klarer, welche Themen Architekturarbeit brauchen und welche nur Ownership und Cleanup erfordern.
Hilfreich ist auch eine einfache Namenskonvention. Speichern Sie Exporte nach Review-Datum, Domäne und Kontrollbereich, damit der nächste Analyst Unterschiede schnell nachvollziehen kann. Wenn mehrere Teams beteiligt sind, definieren Sie, wer sammelt, wer Findings validiert und wer Ausnahmen freigibt. So wird aus dem Audit ein wiederholbarer Betriebsprozess statt einer einmaligen technischen Übung.
Active Directory: Validierung vor dem Abschluss
Eine starke Prüfung von Active Directory sollte mit Produktionsnachweisen enden und nicht mit der Annahme, dass der riskante Pfad verschwunden ist. Bevor Sie den Befund schließen, prüfen Sie privilegierte Identitäten, delegierte Rechte und vererbte Zugriffe, den tatsächlichen Geltungsbereich der geänderten Richtlinie, ACL, Gruppe oder GPO und die Logging- oder Collector-Nachweise zum Befund erneut. Bestätigen Sie, dass der sicherere Zustand für den wirklich relevanten Scope gilt: die produktive OU, die effektive Rollenvergabe, den Anwendungspfad oder den Vertrauens- und Delegationspfad, den ein Angreifer tatsächlich missbrauchen würde. Dokumentieren Sie den technischen Owner, die fachliche Abhängigkeit und die Rollback-Bedingung, damit der nächste Review-Zyklus beurteilen kann, ob der sicherere Zustand erhalten blieb.
Nutzen Sie eine kurze Abschluss-Checkliste:
- prüfen, dass der riskante Zustand aus Angreifersicht verschwunden ist und nicht nur auf einem Admin-Screenshot
- einen Vorher/Nachher-Export oder ein Logbeispiel aufbewahren, das die geänderte Scope beweist
- Owner und Ausnahmeentscheidung dokumentieren, falls die Kontrolle nicht vollständig erzwungen werden konnte
Für benachbarte Exponierungen gleichen Sie das Ergebnis mit Azure Identity Protection: Reaktion auf Kompromittierte Konten, AD & Azure Compliance: NIS2, ISO 27001, CIS, AD Sicherheitsüberwachung: Event IDs und SIEM, und Passwörter in AD-Beschreibungen: Erkennung und Bereinigung ab. Dieselbe Kontrolllücke taucht oft in benachbarten Identitätspfaden, Logging-Lücken oder überbreiten Delegationen wieder auf; genau deshalb ist die Abschlussvalidierung so wichtig.
Active Directory: Nachweise für den nächsten Review-Zyklus
Der nächste Prüfer sollte den Fall nicht aus dem Gedächtnis rekonstruieren müssen. Bewahren Sie den Nachweis auf, der den ursprünglichen Befund begründete, den Nachweis der umgesetzten Änderung und die Notiz, warum der Endzustand akzeptabel ist. Für dieses Thema besteht der nützlichste Nachweissatz meist aus den aktuellen Export der betroffenen Identitäten, Gruppen oder delegierten Pfade, den Vorher/Nachher-Nachweis für die geänderte Konfiguration oder Kontrolle und das Ticket, den Owner und die Ausnahmennotiz zum Endzustand. Dieses kompakte Paket beschleunigt quartalsweise oder anlassbezogene Reviews deutlich und erklärt, ob das Problem entfernt, reduziert oder formell akzeptiert wurde.
| Aufbewahren | Warum es wichtig ist |
|---|---|
| Identitäts-, Gruppen- oder Pfadexport | Zeigt den betroffenen Scope und die geänderten Objekte |
| Konfigurations- oder Berechtigungsnachweis | Belegt, dass die Kontrolle in Produktion greift |
| Owner-, Ticket- und Ausnahmeprotokoll | Erhält Ownership und fachliche Begründung |
Wenn eine spätere Admin-, Richtlinien- oder Applikationsänderung den Pfad erneut öffnet, hilft dieser historische Nachweissatz auch dabei, die Drift sauber zu belegen. Genau das macht Active Directory zu einem wiederholbaren Assurance-Prozess statt zu einem Einmal-Check.
FAQ
Wie oft sollte ein AD-Sicherheitsaudit laufen?
Die meisten internen Teams sollten die Kern-Review mindestens vierteljährlich und nach größeren Identitätsänderungen wiederholen. Dazu gehören Fusionen, Domänen-Umstrukturierungen, Änderungen an Certificate Services, neue Modelle delegierter Administration oder größere GPO-Anpassungen. Wenn sich die Umgebung schnell verändert oder viele Administratoren beteiligt sind, sind monatliche Spot-Checks auf Tier-0-Exposure und privilegierte Gruppen oft sinnvoll.
Was sollte nach dem Audit zuerst behoben werden?
Beginnen Sie mit Findings, die einem Angreifer direkten oder fast direkten privilegierten Zugriff geben. Zu große Mitgliedschaft in privilegierten Gruppen, DCSync-fähige Konten, unconstrained Delegation, gefährliche Zertifikat-Templates und sehr kurze ACL-basierte Attack Paths sollten vor allgemeiner Hygiene stehen. Passwortalter, alte Konten und Logging-Lücken bleiben wichtig, verdienen aber selten Priorität eins, wenn bereits ein domänenweiter Eskalationspfad offen ist.
Wer sollte die Remediation besitzen?
Die Security sollte Priorisierung und Validierung steuern, aber die eigentliche Remediation gehört zu dem Team, das die riskante Konfiguration ändern kann. Das kann AD Engineering, Endpoint Management, PKI-Owner oder ein Applikationsteam mit Service-Accounts sein. Das Audit wird deutlich wirksamer, wenn jedes große Finding einen benannten Owner, ein Zieldatum und eine explizite Risikoentscheidung hat, falls die Änderung nicht sofort möglich ist.
Sollte ADCS immer im Scope sein?
Wenn ADCS irgendwo im Forest existiert, sollte es im Scope sein. Zertifikatsbasierte Eskalationspfade können ansonsten gute Arbeit bei Gruppenhärtung, Passwortpolitik oder Delegation unterlaufen. Interne Teams schieben ADCS oft in eine separate PKI-Review, aber genau diese Trennung erzeugt blinde Flecken. Ein AD-Audit ist stärker, wenn Templates, Enrollment-Rechte und CA-Einstellungen Teil desselben privilegierten Expositionsbildes sind.
Welche Nachweise sollten zwischen Audit-Zyklen aufbewahrt werden?
Bewahren Sie genug Material auf, um zu zeigen, was sich geändert hat, was offen blieb und was als Ausnahme akzeptiert wurde. In der Praxis sind das meist die für die Review verwendeten Exporte, die finale Findings-Liste, der Remediation-Tracker und das Ausnahme-Register mit Ownern und Wiedervorlage-Terminen. Nur den Abschlussbericht aufzubewahren reicht nicht aus, weil dadurch die nächste Review langsamer wird und Fortschritt schwerer belegbar ist.
Wann sollte ein AD-Audit mit einer Entra-ID-Review kombiniert werden?
Wenn privilegierte Administratoren auch Cloud-Dienste nutzen, wenn Hybrid Sync oder App-Management kritische Identitäten beeinflusst oder wenn Recovery-Prozesse von Cloud-Rollen abhängen, sollte die AD-Review mit einer Entra-Review kombiniert werden. Viele Teams stellen fest, dass die On-Prem-Posture sauberer aussieht als die gesamte Identity-Control-Plane. Die Kombination aus Active Directory security audit und Microsoft Entra ID security audit hilft, diese blinden Flecken zu vermeiden.
Warum sollte die Sammlung der Nachweise möglichst automatisiert werden?
Sobald ein Team dieselben Exporte in jedem Zyklus benötigt, sollte der Sammlungsteil so weit wie möglich standardisiert oder skriptbar sein. Das reduziert Übertragungsfehler, beschleunigt Folge-Reviews und hilft neuen Analysten, mit denselben Grundlagen zu arbeiten. Automatisierung ersetzt nicht die fachliche Bewertung, verhindert aber, dass jede neue Review in wiederholter Handarbeit stecken bleibt. Gerade bei mehreren Domänen oder Mandanten entscheidet diese Konsistenz oft darüber, ob das Audit wirklich wiederholbar bleibt und ob Drift früh genug sichtbar wird.
Verwandte Beitrage
Dieses Thema sollte immer zusammen mit AD-Angriffspfade: Fehlkonfigurationen bis Domain Admin, ACL-Missbrauch und DCSync: Die Stillen Pfade zu Domain Admin, ADCS Zertifikatangriffe: Wie ESC1 bis ESC8 zu Domain Admin Führen, AD Sicherheitsüberwachung: Event IDs und SIEM und AD Gruppenverschachtelung: Versteckte DA-Pfade gelesen werden. Zusammen zeigen diese Beitrage, wie sich dieselben Identitats- und Berechtigungsfehler in realen Assessments gegenseitig verstarken.
- AD-Angriffspfade: Fehlkonfigurationen bis Domain Admin
- ACL-Missbrauch und DCSync: Die Stillen Pfade zu Domain Admin
- ADCS Zertifikatangriffe: Wie ESC1 bis ESC8 zu Domain Admin Führen
- AD Sicherheitsüberwachung: Event IDs und SIEM
- AD Gruppenverschachtelung: Versteckte DA-Pfade
Diese internen Verweise helfen dabei, nicht nur einen einzelnen Befund, sondern den gesamten Risikopfad zu bewerten.
Validierung im Betrieb
Vor dem Abschluss der Massnahme sollten dieselben Prufschritte erneut ausgefuhrt werden, die das Risiko ursprunglich sichtbar gemacht haben. Bestatigen Sie, dass der problematische Pfad aus Sicht eines Angreifers verschwunden ist, dass zugehorige Rechte, Gruppen, Ausnahmen und Abhangigkeiten sauber dokumentiert sind und dass die neue Konfiguration im laufenden Betrieb tragfahig bleibt. Diese Schlussprufung trennt eine formale Anderung von einer echten Risikoreduktion.
Fragen vor dem Endgueltigen Abschluss
Bevor ein Team einen Identitaetsbefund als abgeschlossen bewertet, sollte es einige praktische Fragen mit nachvollziehbaren Belegen beantworten koennen. Welches Konto, welche Gruppe oder welches System stellt weiterhin den sensibelsten Ausnahmeweg dar? Welche betriebliche Abhaengigkeit hat eine vollstaendige Bereinigung verhindert, und wer hat dieses Restrisiko bewusst akzeptiert? Welche Ueberwachungsregel, welcher Review-Rhythmus oder welcher kompensierende Kontrollmechanismus deckt die verbleibende Exposition heute in der Produktion ab? Diese Fragen sind wichtig, weil Identitaetsschwaechen oft dann zurueckkehren, wenn die Remediation im Bericht sauberer aussieht als in der Realitaet. Wenn Eigentum, Geschaeftsbezug und naechster Prueftermin nicht klar benannt sind, ist der neue Kontrollzustand in der Regel weniger stabil als angenommen.
Welche Nachweise fuer die Naechste Pruefung Aufbewahrt Werden Sollten
Reife Sicherheitsteams behalten genau die Nachweise, die den naechsten Review schneller und belastbarer machen. Dazu gehoeren in der Regel der aktuelle Eigentuemer des betroffenen Assets, die konkrete Konfigurationsaenderung zur Risikoreduktion, die Liste noch akzeptierter Ausnahmen und der technische Beleg dafuer, dass der neue Zustand in der Produktion wirklich durchgesetzt wird. Diese Dokumentation ist wichtig, weil Identitaets- und Berechtigungsprobleme selten einmalige Entdeckungen bleiben. Sie tauchen spaeter ueber Administratorwechsel, Applikationsdrift oder nur teilweise verstandene Alt-Abhaengigkeiten erneut auf. Wenn die Aenderung und ihre Begruendung sauber festgehalten werden, sinkt das Risiko, dass ein spaeteres Team dieselbe Analyse wiederholen oder dieselbe Schwachstelle unbeabsichtigt erneut einfuehren muss.
Was Nach dem Naechsten Grossen Change Erneut Geprueft Werden Sollte
Die zuverlaessigsten Sicherheitsprogramme pruefen denselben Kontrollbereich noch einmal nach dem naechsten groesseren Change-Fenster und nicht nur direkt nach der ersten Remediation. Neue Anwendungen, OU-Verschiebungen, delegierte Administratoren und Notfallausnahmen stellen das Risiko im normalen Betrieb haeufig erneut her. Ein kurzer Nachreview zu Aenderungen, Eigentuemern und Ausnahmen reicht oft aus, um diese Drift frueh zu erkennen.
Ein letzter Abgleich mit den Eigentuemern privilegierter Gruppen, den offenen Ausnahmen und dem naechsten Review-Termin stellt sicher, dass die Checkliste auch im Alltag tragfaehig bleibt.
