Active Directory haerten: Was Sie zuerst absichern und wie Sie es validieren

Active Directory haerten ist weder ein reines GPO-Projekt noch eine Checkliste für genau einen Lauf. Ein brauchbarer Plan zum Härten von Active Directory reduziert die Zahl privilegierter Pfade, entfernt schwache Protokolle und wiederverwendbare Geheimnisse und weist anschließend nach, dass die Kontrollen auch nach dem Rollout noch funktionieren. Wenn Sie zuerst den umfassenderen Review-Workflow brauchen, beginnen Sie mit Active Directory-Sicherheit auditieren: Was zuerst zu prüfen ist und wie sich Remediation nachweisen lässt. Dieser Artikel ist enger gefasst: Er konzentriert sich darauf, was zuerst abzusichern ist.

Was Active Directory haerten tatsächlich bedeutet

In der Praxis bedeutet das Härten von Active Directory, die Zahl der Wege zu reduzieren, über die ein Angreifer privilegierte Kontrolle erreichen kann, und anschließend die verbleibenden administrativen Pfade zu schützen und zu überwachen. Microsofts Strategie für privilegierten Zugriff behandelt privilegierten Zugriff ausdrücklich als höchste Sicherheitspriorität und empfiehlt, privilegierte Aktionen auf wenige autorisierte Wege zu beschränken, die dann eng geschützt und überwacht werden.

Deshalb muss gutes Härtungs-Work geordnet ablaufen. Wenn Sie mit kosmetischem Baseline-Tuning beginnen, bevor Sie privilegierte Identitäten trennen, administrative Hosts härten und wiederverwendbare Geheimnisse entfernen, bleibt die Control Plane leicht erreichbar. Der ANSSI Active Directory Leitfaden: So setzen Sie die Sicherheitsempfehlungen praktisch um kommt operativ zum gleichen Schluss: Zuerst das Administrationsmodell segmentieren, danach die unterstützenden Kontrollen härten.

Active Directory härten beginnt mit privilegiertem Zugriff und administrativen Pfaden

Die erste Priorität ist privilegierter Zugriff, nicht weil das ein modisches Thema wäre, sondern weil die Kompromittierung privilegierter Konten und Pfade meist den Rest des Verzeichnissicherheitsmodells kollabieren lässt. Microsofts Guidance zu sicheren administrativen Hosts ist eindeutig: Ein vertrauenswürdiges System sollte nie von einem weniger vertrauenswürdigen Host aus administriert werden, und dedizierte administrative Hosts sollten keine normale Benutzersoftware wie E-Mail, Webbrowser oder Office-Anwendungen ausführen.

Daraus ergibt sich die erste Härtungssequenz:

1. Privilegierte Konten von Alltagsidentitäten trennen.
2. Privilegierte Administration auf dedizierte Workstations, Jump Hosts oder gleichwertige sichere administrative Hosts verlagern.
3. Beschränken, wo sich hochprivilegierte Identitäten authentifizieren dürfen.
4. Messen, ob privilegierte Sitzungen noch von gewöhnlichen Benutzergeräten aus stattfinden.

Hier gehören auch Kontrollen wie die Sicherheitsgruppe Protected Users und Authentication Policies / Authentication Policy Silos hin. Sie sind nützliche Containment-Kontrollen für die richtigen Konten, aber keine universellen Standardstartpunkte. Microsoft dokumentiert wichtige Caveats: Mitglieder von Protected Users müssen sich mit AES authentifizieren können, Dienst- und Computerkonten sollten nicht hinzugefügt werden, und hochprivilegierte Konten sollten erst dann aufgenommen werden, wenn die operativen Auswirkungen validiert wurden. Authentication policy silos können zusätzlich einschränken, auf welchen Hosts ausgewählte hochprivilegierte Benutzer-, Computer- und Dienstkonten sich authentifizieren dürfen. Dadurch werden sie sinnvoll, sobald administrative Tiers und Pfade bereits definiert sind.

Danach Protokoll- und Verzeichnis-Exposure reduzieren

Sobald privilegierte Pfade enger gefasst sind, besteht der nächste Schritt beim Härten von Active Directory darin, Protokoll-Exposure zu reduzieren, das weiterhin Abhören, Manipulation oder schwache Admin-Gewohnheiten ermöglicht.

LDAP signing und channel binding

Microsoft dokumentiert LDAP signing und LDAP channel binding als Schutzmaßnahmen für AD DS LDAP-Traffic. LDAP signing hilft dabei, Authentizität und Integrität zu verifizieren, während channel binding die Anwendungsebene an die zugrunde liegende TLS-Sitzung bindet, um Hijacking und Man-in-the-Middle-Szenarien zu erschweren. Praktisch bedeutet das: Ein ernsthafter Härtungsplan muss prüfen, ob unsignierte SASL-Binds oder unsichere LDAP-Muster von Domain Controllern noch toleriert werden.

Der klassische Fehler ist blinde Erzwingung. Bevor Sie die Einstellung verschärfen, validieren Sie, welche Anwendungen, Appliances, Skripte oder Legacy-Middleware noch von schwachem LDAP-Verhalten abhängen. Bewahren Sie dann den Nachweis dieser Kompatibilitätsprüfung und des final erzwungenen Zustands auf. Der zugehörige Deep Dive bleibt auf Englisch: LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.

SMB signing

Microsofts Guidance zu SMB signing ist als Härtungskontrolle genauso nützlich, weil sie die Nachrichtenintegrität schützt und bei der Abwehr von Relay- und Spoofing-Angriffen hilft. SMB signing auf hochwertigen Administrations- und Dateiverwaltungspfaden zu erzwingen, ist oft eine Kontrolle, die früh priorisiert werden sollte.

Auch hier ist die Reihenfolge wichtig. Microsoft weist darauf hin, dass es in Umgebungen mit Nicht-Microsoft-Dateiservern zu Kompatibilitätsproblemen kommen kann, wenn Signaturanforderungen erzwungen werden. Der richtige Schritt ist also nicht „sofort überall einschalten“, sondern „messen, wo unsigniertes SMB noch relevant ist, Abhängigkeiten validieren und dann mit Nachweis erzwingen“. Der zugehörige Deep Dive ist SMB-Signierung deaktiviert: Warum das weiter NTLM-Relay ermöglicht.

Active Directory härten bedeutet, wiederverwendbare Geheimnisse zu reduzieren

Viele AD-Intrusionen beschleunigen sich noch immer, weil wiederverwendbare Geheimnisse zu leicht gestohlen, wiederverwendet oder lateral ausgenutzt werden können. Das ist die dritte Priorität, weil sie oft begrenzt, wie weit sich die Kompromittierung eines einzelnen Hosts ausbreiten kann.

Windows LAPS

Microsoft dokumentiert Windows LAPS als integrierte Funktion, die Kennwörter lokaler Administratorkonten automatisch verwaltet und sichert. Darüber hinaus kann sie auf Windows Server Active Directory Domain Controllern auch das DSRM-Kennwort verwalten. Das macht Windows LAPS zu einer zentralen Härtungskontrolle und nicht bloß zu einer Komfortfunktion. Wenn lokale Admin- oder DSRM-Kennwörter statisch, geteilt oder manuell rotiert bleiben, trägt die Umgebung weiter vermeidbares Lateralmovement-Risiko.

Das Ziel ist nicht nur die Bereitstellung. Validieren Sie Kennwortrotation, Abrufberechtigungen, Backup-Ziel und ob Ausnahmen weiterhin Teile der Flotte außerhalb der Kontrolle lassen. Zugehöriger Deep Dive: Windows LAPS nicht bereitgestellt: Warum gemeinsame lokale Admin-Passwörter weiter relevant sind.

Kennwörter von Dienstkonten und gMSA

Microsofts Guidance zu group Managed Service Accounts ist wertvoll, weil sie den Verwaltungsaufwand für Kennwörter von Dienstkonten reduziert und das SPN-Management vereinfacht. Wo die Anwendung es unterstützt, entfernt der Wechsel von klassischen benutzergebundenen Dienstkonten zu gMSA eine Klasse langlebiger manuell verwalteter Kennwörter.

Das ist kein pauschaler Migrationsbefehl. Vor der Umstellung müssen Anwendungssupport, Cluster- oder Farm-Verhalten, SPN-Abhängigkeiten und operatives Ownership validiert werden. Für Konten, die noch nicht auf gMSA umgestellt werden können, sollten Kennwortalter reduziert, unnötige Privilegien entfernt und geprüft werden, ob das Konto überhaupt noch der richtige Principal für den Dienst ist.

Gezielte Härtung von Kennwortrichtlinien

Microsofts Guidance zu fine-grained password policies ist hier nützlich, aber nur im richtigen Scope. Fine-grained password policies gelten für Benutzerobjekte und globale Sicherheitsgruppen und sind kein universeller Ersatz für breitere Kennwort-Governance. Nutzen Sie sie, wenn Sie für ausgewählte administrative oder Dienstkontenpopulationen strengere Vorgaben benötigen, nicht als Ersatz für bessere allgemeine Credential-Hygiene. Für die benachbarte Kennwort-Kontrollschicht bleibt der Deep Dive auf Englisch: Active Directory Password Security: Misconfigurations That Matter.

Delegation und andere Eskalationspfade begrenzen

Die vierte Priorität ist die Control Plane rund um das Verzeichnis selbst: delegierte Berechtigungen, Kontrolle privilegierter Gruppen, GPO-Administration und replizierungsbezogene Rechte, die nicht breit erreichbar bleiben sollten.

Microsofts Group-Policy-Dokumentation erinnert daran, dass ein GPO nicht einfach nur „eine Einstellung“ ist. Es besitzt eine AD-Komponente und eine Dateisystem-Komponente und wird über die normale Verzeichnis-Scopelogik angewendet. Deshalb gehören GPO-Berechtigungen und Link-Scopes in Härtungsarbeit hinein und nicht nur ins Troubleshooting. Wenn niedrig privilegierte Benutzer ein GPO beeinflussen können, das privilegierte Systeme erreicht, hat das Härtungsprogramm eine strukturelle Lücke. Der benachbarte Artikel bleibt auf Englisch: GPO Misconfigurations: How Group Policy Becomes an Attack Vector.

Die gleiche Logik gilt für replizierungsbezogene Berechtigungen. Microsoft dokumentiert Replicating Directory Changes als ACE auf jedem Domain-Naming-Context, die Konten explizit gewährt werden kann. Das bedeutet, dass replizierungsfähiger Zugriff als privilegiert behandelt und ausdrücklich geprüft werden sollte, statt ihn als harmlos zu betrachten, nur weil er nicht „Domain Admin“ heißt. Das breitere Problem von Missbrauchsketten wird in AD-Angriffspfade: wie Fehlkonfigurationen bis zu Domain Admin verkettet werden behandelt.

Wenn AD CS bereitgestellt ist, sollte es in dasselbe Härtungsprogramm aufgenommen werden. Microsoft dokumentiert AD CS als Windows-Server-Rolle, die Zertifikate für sichere Kommunikation und Authentifizierung ausstellt und verwaltet. Anders gesagt: Wenn zertifikatsbasierte Authentifizierung in der Umgebung existiert, lässt das Härten des Verzeichnisses unter Ausblendung der Zertifikat-Control-Plane eine materielle Lücke. Halten Sie den Scope bedingt: Ist AD CS nicht bereitgestellt, muss es nicht künstlich in das Programm gezwungen werden. Ist es vorhanden, lesen Sie ADCS-Angriffspfade: wie Zertifikat-Fehlkonfigurationen zu Eskalationspfaden in Active Directory werden.

Logging und Validierung in den Härtungsplan einbauen

Härtung, die nicht erneut gemessen werden kann, driftet zurück in Vermutungen. Microsofts Empfehlungen zu Audit Policies und Event Collection machen den operativen Punkt klar: Zuerst brauchen Sie die richtigen Audit-Einstellungen, danach den richtigen Sammlungs- und Aufbewahrungspfad.

Windows Event Forwarding und Windows Event Collector können die von Ihnen ausgewählten Ereignisse zentralisieren, ersetzen aber nicht das Design der Audit Policy. Telemetrie zu Änderungen an Verzeichnisobjekten ist nur dann nützlich, wenn die nötigen Audit-Einstellungen und die richtige SACL-Abdeckung existieren. Microsoft dokumentiert zum Beispiel, dass Event 5136 erzeugt wird, wenn ein Verzeichnisdienstobjekt geändert wird, aber nur, wenn das Objekt den relevanten SACL-Eintrag für die auditierte Schreibaktion besitzt.

Daraus folgt eine praktische Regel für Härtungsprogramme:

• Vorher-/Nachher-Exporte für privilegierte Gruppenmitgliedschaften, GPO-Zustand, LDAP- und SMB-Policy-Status sowie delegierte Berechtigungen aufbewahren
• verifizieren, dass Domain Controller und administrative Systeme tatsächlich die Ereignisse protokollieren, auf die Sie sich verlassen wollen
• WEF/WEC als Transport- und Aufbewahrungsinfrastruktur behandeln, nicht als Beweis dafür, dass das Audit-Design vollständig ist

Für die Ereignis-Sichtbarkeitsschicht nutzen Sie AD-Sicherheitsüberwachung: die Event IDs, die wirklich zählen und Wiederkehrendes Active-Directory-Audit: warum jährliche Audits driften und wie sich kontinuierlich nachmessen lässt.

Prioritätenmatrix zum Härten von Active Directory

Wenn AD CS vorhanden ist, nehmen Sie Exposure von Certificate Templates, CA-Konfiguration und Enrollment Endpoints als bedingte zusätzliche Zeile in dieselbe Matrix auf, statt sie als separates Zukunftsprojekt zu behandeln.

Validierung nach Härtungsänderungen

Ein Härtungsprogramm ist erst abgeschlossen, wenn die Kontrollen unter Produktionsbedingungen weiterhin funktionieren. Nützliche Validierungsnachweise sind zum Beispiel:

1. Der Nachweis, dass privilegierte Administration nur noch von genehmigten Hosts oder definierten Jump Paths ausgeht.
2. Der Nachweis, dass LDAP-Clients mit der Zielhaltung für LDAP signing und channel binding weiterhin funktionieren.
3. Der Nachweis, dass administrative und dateibasierte SMB-Workflows mit den vorgesehenen Signaturanforderungen weiter funktionieren.
4. Der Nachweis, dass Windows LAPS lokale Admin- und DSRM-Geheimnisse rotiert und dass Retrieval-Rechte eng begrenzt sind.
5. Der Nachweis, dass Migrationen von Dienstkonten zu gMSA oder zu strengerem Betriebsmodell keine defekten SPNs oder unverwalteten Ausnahmen zurückgelassen haben.
6. Der Nachweis, dass delegierte Berechtigungen, replizierungsbezogene Rechte und GPO-Kontrollpfade vor und nach der Änderung überprüft wurden.
7. Der Nachweis, dass Audit Policy und Event-Pipeline tatsächlich die Kontrollen erfassen, auf die Sie sich stützen wollen.

Genau deshalb steht dieses Pillar neben dem Audit-Pillar und nicht darüber. Die Hardening-Frage lautet: „Was sichern wir zuerst ab?“ Die Audit-Frage lautet: „Was prüfen wir wiederkehrend, und wie weisen wir Drift oder Remediation im Zeitverlauf nach?“ Beides ist wichtig, aber es ist nicht derselbe Workflow.

Wie EtcSec wiederholbare AD-Härtungsreviews unterstützt

EtcSec passt hier als Schicht für wiederholbare Messung hinein, nicht als Abkürzung an der eigentlichen Härtungsarbeit vorbei. Ein lokaler Read-only-Collector kann helfen, die Ausbreitung privilegierter Konten, replizierungsfähige Berechtigungen, LDAP-signing-Exposure, SMB-signing-Exposure und Windows-LAPS-Abdeckung nach jeder Änderungswelle erneut zu messen. Das ist nützlich, wenn nachgewiesen werden muss, dass eine Härtungsentscheidung die Exposure tatsächlich reduziert hat, statt nur eine Richtlinieneinstellung auf dem Papier zu ändern.

Primäre Referenzen

• Best practices for securing Active Directory
• Implementing Secure Administrative Hosts
• Privileged access: Strategy
• LDAP signing for Active Directory Domain Services on Windows Server
• Overview of Server Message Block signing in Windows
• Windows LAPS overview
• Group Managed Service Accounts overview
• Protected Users security group
• Authentication Policies and Authentication Policy Silos
• System Audit Policy recommendations
• Use Windows Event Forwarding to help with intrusion detection
• What is Active Directory Certificate Services?
• Group Policy overview for Windows Server
• Configure fine-grained password policies for Active Directory Domain Services in Windows Server
• How to grant the "Replicating Directory Changes" permission for the Microsoft Metadirectory Services ADMA service account
• 5136(S): A directory service object was modified
• Recommandations pour l’administration sécurisée des SI reposant sur AD