Active Directory absichern: Die 10 wichtigsten Maßnahmen

Warum Active Directory das primäre Angriffsziel ist

In den meisten mittelständischen Unternehmen gibt es ein System, das über allem steht: Active Directory. Es verwaltet Benutzerkonten, steuert Gruppenmitgliedschaften, regelt den Zugriff auf Dateifreigaben, Anwendungen und E-Mail, und es authentifiziert jeden Login auf jedem Windows-Rechner im Netzwerk. Wer die Kontrolle über Active Directory gewinnt, hat die Kontrolle über das gesamte Unternehmen.

Genau das macht AD zum bevorzugten Ziel von Angreifern. Ransomware-Gruppen wie LockBit, BlackCat oder Conti haben ihre Angriffsketten über Jahre perfektioniert, und in fast jeder spielt die Kompromittierung von Active Directory die zentrale Rolle. Der typische Ablauf: Phishing-Link, Zugriff auf einen Arbeitsplatz-PC, laterale Bewegung durchs Netzwerk, bis Domain-Admin-Rechte erlangt sind.

Microsoft hat festgestellt, dass bei über 80 Prozent der erfolgreichen Ransomware-Angriffe Active Directory kompromittiert wurde. Das BSI bestätigt diesen Befund.

Das Problem ist nicht, dass Active Directory per se unsicher wäre. Das Problem ist, dass die meisten AD-Umgebungen im Mittelstand über Jahre gewachsen sind, ohne dass jemand systematisch an die Sicherheit gedacht hat. Accounts werden nie bereinigt, Gruppen sind unübersichtlich verschachtelt, lokale Admin-Passwörter überall identisch, Service Accounts laufen mit Domain-Admin-Rechten.

Die folgenden zehn Maßnahmen ändern das. Sie sind nach Priorität geordnet und speziell auf Unternehmen mit rund 100 Mitarbeitern zugeschnitten, also auf Umgebungen mit einer Domain, einem oder zwei Domain Controllern und einer überschaubaren IT-Abteilung.

Maßnahme 1: Tiered Administration einführen

Tiered Administration ist das Fundament jeder AD-Härtung. Das Konzept ist einfach: Du trennst die Verwaltung deiner IT-Umgebung in drei Ebenen (Tiers) und stellst sicher, dass Anmeldedaten einer höheren Ebene niemals auf einer niedrigeren Ebene verwendet werden.

Tier 0 umfasst die Domain Controller und alles, was direkt die Kontrolle über Active Directory hat. Hierhin gehören Domain Admins, Enterprise Admins, Schema Admins und die Systeme, die diese Accounts verwenden.

Tier 1 umfasst die Server-Infrastruktur: Dateiserver, Datenbankserver, Applikationsserver, Exchange, SharePoint. Die Admin-Accounts auf dieser Ebene haben Zugriff auf Geschäftsdaten, aber nicht auf die Domain Controller.

Tier 2 umfasst die Arbeitsplätze und Endgeräte der Mitarbeiter. Die Helpdesk-Accounts, die Probleme auf Arbeitsplätzen lösen, haben keinen Zugriff auf Server oder Domain Controller.

Die zentrale Regel lautet: Ein Tier-0-Account meldet sich niemals an einem System in Tier 1 oder Tier 2 an. Ein Tier-1-Account meldet sich niemals an einem Arbeitsplatz an. Diese Trennung verhindert, dass ein Angreifer, der einen Arbeitsplatz kompromittiert hat, direkt an Anmeldedaten gelangt, mit denen er Domain Controller übernehmen kann.

In der Praxis bedeutet das: Dein IT-Admin bekommt mindestens zwei, idealerweise drei getrennte Accounts. Einen normalen Account für E-Mail und alltägliche Arbeit (Tier 2), einen Server-Admin-Account für die Verwaltung der Server (Tier 1) und einen Domain-Admin-Account für Active-Directory-Aufgaben (Tier 0). Der Domain-Admin-Account wird ausschließlich auf den Domain Controllern oder über dedizierte Privileged Access Workstations (PAWs) verwendet.

Für ein Unternehmen mit 100 Mitarbeitern ist das keine übertriebene Komplexität. Ein gehärteter Rechner, auf dem ausschließlich die AD-Verwaltung stattfindet, reicht für den Anfang. Ein sauberes Berechtigungskonzept ist die Grundlage für die konsequente Umsetzung der Tiered Administration. Das Entscheidende ist die Trennung der Accounts und die Disziplin, sie einzuhalten.

Umsetzung: Erstelle separate OU-Strukturen für die drei Tiers und implementiere Logon-Restrictions per GPO. Die Technik dafür heißt „User Rights Assignment" unter „Deny log on locally" und „Deny log on through Remote Desktop Services".

Maßnahme 2: LAPS implementieren

LAPS steht für Local Administrator Password Solution und löst eines der ältesten und häufigsten Sicherheitsprobleme in Windows-Umgebungen: identische lokale Admin-Passwörter auf allen Rechnern.

Der klassische Fehler sieht so aus: Bei der Einrichtung des Unternehmensimages wird ein lokales Administratorpasswort festgelegt, sagen wir „Firma2019!". Dieses Passwort wird auf jeden Client und jeden Server ausgerollt. Es ändert sich nie. Jeder in der IT-Abteilung kennt es, und wahrscheinlich steht es auch noch in einer Excel-Tabelle auf einem Netzwerklaufwerk.

Das Problem: Wenn ein Angreifer dieses Passwort auf einem einzigen Rechner ausliest (etwa über Mimikatz oder ein anderes Credential-Dumping-Tool), hat er lokalen Admin-Zugriff auf jeden Rechner im Netzwerk. Die laterale Bewegung wird trivial.

LAPS löst das, indem es für jeden Rechner ein individuelles, zufällig generiertes lokales Admin-Passwort setzt und dieses im Active Directory speichert. Nur berechtigte Administratoren können die Passwörter im AD auslesen, und die Passwörter werden automatisch rotiert.

Microsoft hat LAPS mittlerweile als „Windows LAPS" direkt in Windows 11 und Windows Server 2025 integriert. Für ältere Systeme gibt es das klassische „Legacy LAPS" als kostenlosen Download. Das Grundprinzip ist bei beiden gleich: Ein GPO-Client-Extension generiert das Passwort, schreibt es verschlüsselt in ein AD-Attribut des Computer-Objekts und setzt ein Ablaufdatum.

Umsetzung: Installiere die LAPS-Schemaerweiterung (bei Legacy LAPS) oder aktiviere Windows LAPS per GPO. Definiere die Passwortlänge (mindestens 20 Zeichen), die Komplexität und das Rotationsintervall (30 Tage ist ein guter Ausgangswert). Teste auf einer kleinen Gruppe von Rechnern, bevor du ausrollst. Der gesamte Rollout dauert bei 100 Arbeitsplätzen einen Nachmittag.

Maßnahme 3: Kerberoasting verhindern

Kerberoasting ist eine Angriffstechnik, die einen fundamentalen Designaspekt von Kerberos ausnutzt: Wenn ein Benutzer ein Service Ticket für einen Dienst anfordert, wird dieses Ticket mit dem Passwort-Hash des zugehörigen Service Accounts verschlüsselt. Ein Angreifer mit einem normalen Benutzerkonto kann Service Tickets für alle Service Accounts anfordern und anschließend offline versuchen, die Passwörter zu knacken. Das Gefährliche daran: Für die Anforderung des Tickets braucht der Angreifer keine besonderen Rechte, und der Brute-Force-Angriff findet offline statt, also ohne Fehlversuche, die eine Kontosperrung auslösen würden.

Service Accounts mit einem Service Principal Name (SPN) und einem schwachen Passwort wie „Sommer2020!" sind in wenigen Minuten geknackt. Wenn dieser Service Account dann auch noch Mitglied der Gruppe Domain Admins ist (was erschreckend oft vorkommt), hat der Angreifer den Jackpot.

Die Gegenmaßnahmen sind klar und umsetzbar:

Starke Passwörter für Service Accounts. Jeder Service Account mit einem SPN braucht ein zufällig generiertes Passwort mit mindestens 30 Zeichen. Bei dieser Länge ist Offline-Brute-Force praktisch aussichtslos.

Group Managed Service Accounts (gMSA) verwenden. gMSAs sind AD-verwaltete Service Accounts, deren 240-Zeichen-Passwort automatisch alle 30 Tage rotiert wird. Kein Mensch kennt oder verwaltet dieses Passwort. Wo immer ein Dienst gMSA unterstützt, solltest du darauf umstellen. Die meisten modernen Anwendungen, einschließlich SQL Server, IIS und SCCM, können mit gMSAs arbeiten.

Unnötige SPNs entfernen. Prüfe regelmäßig, welche Accounts einen SPN registriert haben. Accounts, die keinen Dienst mehr bereitstellen, sollten ihren SPN verlieren. Das reduziert die Angriffsfläche.

AES-Verschlüsselung erzwingen. Stelle sicher, dass Service Accounts AES-256-Verschlüsselung für Kerberos-Tickets verwenden (das Attribut msDS-SupportedEncryptionTypes). RC4-verschlüsselte Tickets lassen sich deutlich schneller knacken als AES-verschlüsselte.

Monitoring. Überwache Event ID 4769 (Kerberos Service Ticket Requests) mit dem Verschlüsselungstyp 0x17 (RC4). Ein plötzlicher Anstieg von RC4-basierten Ticket-Anfragen ist ein starkes Indiz für einen Kerberoasting-Angriff.

Maßnahme 4: Protected Users Gruppe nutzen

Die Sicherheitsgruppe „Protected Users" existiert seit Windows Server 2012 R2 und ist eine der am meisten unterschätzten Sicherheitsfunktionen in Active Directory. Mitglieder dieser Gruppe erhalten automatisch eine Reihe von Schutzmaßnahmen, die Credential-Theft-Angriffe erheblich erschweren.

Konkret passiert Folgendes, wenn ein Account Mitglied von Protected Users ist:

• Kein NTLM. Der Account kann sich nicht per NTLM authentifizieren, sondern nur per Kerberos. Das verhindert Pass-the-Hash-Angriffe, die auf NTLM-Hashes basieren.
• Kein DES oder RC4 für Kerberos. Es werden ausschließlich AES-Schlüssel verwendet, was Kerberoasting erschwert.
• Kein Delegation. Der Account kann nicht delegiert werden, weder eingeschränkt noch uneingeschränkt. Das verhindert Token-Impersonation-Angriffe.
• Ticket-Lebensdauer auf 4 Stunden begrenzt. Kerberos-Tickets (TGT) laufen schneller ab, was das Zeitfenster für Angreifer verkleinert.
• Keine Zwischenspeicherung von Anmeldedaten. Passwort-Hashes werden nicht im Speicher des Rechners gecached. Mimikatz findet dort nichts Verwertbares.

Für welche Accounts solltest du Protected Users aktivieren? Für alle hochprivilegierten Accounts: Domain Admins, Enterprise Admins, Schema Admins, und alle Accounts mit administrativem Zugriff auf Domain Controller oder andere Tier-0-Systeme.

Vorsicht bei Service Accounts: Service Accounts, die auf NTLM oder Delegation angewiesen sind, funktionieren als Protected Users nicht mehr. Teste sorgfältig, bevor du einen Service Account in die Gruppe aufnimmst. Für interaktive Admin-Accounts hingegen gibt es selten einen Grund, Protected Users nicht zu nutzen.

Umsetzung: Öffne „Active Directory Users and Computers", navigiere zum Container „Users", finde die Gruppe „Protected Users" und füge deine hochprivilegierten Accounts hinzu. Die Schutzmaßnahmen greifen sofort nach der nächsten Anmeldung. Das dauert buchstäblich fünf Minuten, und der Sicherheitsgewinn ist enorm.

Maßnahme 5: Credential Guard aktivieren

Windows Credential Guard nutzt Virtualization-Based Security (VBS), um Anmeldedaten in einem isolierten Bereich des Systems zu speichern, auf den selbst ein Angreifer mit lokalen Admin-Rechten nicht zugreifen kann. Im Klartext: Selbst wenn ein Angreifer Mimikatz auf einem Rechner mit Credential Guard ausführt, bekommt er keine NTLM-Hashes und keine Kerberos-Tickets aus dem Speicher.

Das ist ein fundamentaler Schutz gegen eine der häufigsten Angriffstechniken. Ohne Credential Guard kann ein Angreifer, der lokalen Admin-Zugriff auf einen Rechner hat, den LSASS-Prozess dumpen und alle dort gespeicherten Anmeldedaten extrahieren. Wenn sich ein Domain Admin auf diesem Rechner angemeldet hat (Verstoß gegen Tiered Administration, siehe Maßnahme 1), hat der Angreifer dessen Anmeldedaten.

Credential Guard eliminiert diesen Angriffsvektor. Die Anmeldedaten werden in einer isolierten virtuellen Maschine gespeichert, auf die das reguläre Betriebssystem keinen Zugriff hat.

Voraussetzungen: UEFI-Firmware mit Secure Boot, TPM 2.0 und Windows 10/11 Enterprise oder Education (oder Windows Server 2016+). Auf Windows 11 22H2 und neuer ist Credential Guard standardmäßig aktiviert.

Umsetzung: Aktiviere Credential Guard per Gruppenrichtlinie unter „Computer Configuration > Administrative Templates > System > Device Guard > Turn On Virtualization Based Security". Setze die Option „Credential Guard Configuration" auf „Enabled with UEFI lock". Der UEFI-Lock stellt sicher, dass ein Angreifer Credential Guard nicht einfach per GPO wieder deaktivieren kann.

Kompatibilitätshinweis: Ältere Anwendungen, die NTLM v1 oder CredSSP in bestimmten Konfigurationen verwenden, können Probleme machen. Teste auf einer Pilotgruppe, bevor du die GPO unternehmensweit ausrollst.

Maßnahme 6: AdminSDHolder und SDProp verstehen und absichern

AdminSDHolder ist ein Container-Objekt in Active Directory, dessen Zugriffssteuerungsliste (ACL) automatisch auf alle privilegierten Accounts und Gruppen übertragen wird. Der Prozess namens SDProp (Security Descriptor Propagator) läuft alle 60 Minuten auf dem PDC-Emulator und überschreibt die ACLs aller geschützten Objekte mit der ACL des AdminSDHolder-Containers.

Das klingt technisch, aber die Sicherheitsrelevanz ist hoch: Wenn ein Angreifer die ACL des AdminSDHolder-Containers manipulieren kann, erlangt er indirekt Kontrolle über alle privilegierten Accounts in der Domain. Innerhalb von 60 Minuten werden seine manipulierten Berechtigungen auf alle Domain Admins, Enterprise Admins und andere geschützte Gruppen propagiert.

Was du tun solltest:

Erstens, prüfe die aktuelle ACL des AdminSDHolder-Containers. Nur Domain Admins und Enterprise Admins sollten dort Schreibrechte haben. Entferne jede andere Berechtigung, die dort nicht hingehört.

Zweitens, überwache Änderungen am AdminSDHolder-Container. Jede Modifikation der ACL dieses Objekts ist ein potenzieller Angriffsindikator. Konfiguriere ein Audit-Log für Änderungen an diesem spezifischen Objekt (Objekt-Audit in der SACL des AdminSDHolder-Containers aktivieren).

Drittens, verstehe die Liste der geschützten Gruppen. SDProp schützt standardmäßig: Administrators, Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Server Operators, Print Operators, Backup Operators und die Gruppe Replicator. Wenn Mitglieder dieser Gruppen plötzlich ungewöhnliche Berechtigungen haben, die sich nicht durch GPOs erklären lassen, könnte AdminSDHolder manipuliert worden sein.

Umsetzung: Öffne ADSI Edit, navigiere zum Objekt CN=AdminSDHolder,CN=System,DC=deinedomain,DC=de und überprüfe die Security-Properties. Dokumentiere die Soll-ACL und vergleiche sie regelmäßig mit dem Ist-Zustand. In einer 100-Mitarbeiter-Umgebung ist das einmal im Quartal in einer halben Stunde erledigt.

Maßnahme 7: GPO Hardening

Gruppenrichtlinien sind das zentrale Konfigurationswerkzeug in Windows-Umgebungen, und sie können ebenso gut zur Härtung wie zum Angriff missbraucht werden. Ein Angreifer mit Schreibrechten auf eine GPO kann auf einen Schlag Malware an alle Computer verteilen, lokale Admin-Accounts anlegen oder Sicherheitseinstellungen deaktivieren.

Die Absicherung von GPOs umfasst zwei Dimensionen: die Berechtigungen auf die GPO-Objekte selbst und die sicherheitsrelevanten Einstellungen, die über GPOs verteilt werden.

GPO-Berechtigungen absichern:

Nur Domain Admins sollten GPOs erstellen, bearbeiten und verknüpfen können. Prüfe mit dem Tool BloodHound oder manuell über die GPMC (Group Policy Management Console), wer Schreibrechte auf deine GPOs hat. In gewachsenen Umgebungen finden sich dort regelmäßig Accounts, die vor Jahren berechtigt wurden und längst keine GPO-Verwaltung mehr durchführen.

Besonders kritisch ist die GPO „Default Domain Policy" und die GPO „Default Domain Controllers Policy". Manipulation an diesen GPOs betrifft die gesamte Domain.

Sicherheitsrelevante GPO-Einstellungen:

Setze über Gruppenrichtlinien mindestens die folgenden Härtungsmaßnahmen um:

Umsetzung: Erstelle eine dedizierte „Security Baseline" GPO, die auf die gesamte Domain verknüpft wird. Verwende als Vorlage die Microsoft Security Baselines (kostenlos im Security Compliance Toolkit verfügbar). Passe die Einstellungen an deine Umgebung an und teste sie in einer Staging-OU, bevor du sie produktiv schaltest.

Maßnahme 8: Monitoring kritischer Event-IDs

Alle vorherigen Maßnahmen zielen auf Prävention. Monitoring zielt darauf ab, Angriffe zu erkennen, die trotz aller Prävention stattfinden. Die Herausforderung ist nicht, dass zu wenig protokolliert wird, sondern dass zu viel. Ohne gezielte Filterung geht jedes Signal im Rauschen unter.

Die folgenden Event-IDs solltest du aktiv überwachen:

Angriffe auf privilegierte Accounts:

Kerberos-Angriffe:

Account-Manipulation:

Umsetzung: Aktiviere die erweiterten Audit-Richtlinien (Advanced Audit Policy Configuration) per GPO auf den Domain Controllern. Konfiguriere die Weiterleitung der Ereignisse an ein zentrales Log-System (Windows Event Forwarding oder einen SIEM-Agenten). Definiere für jede der genannten Event-IDs eine Alarmregel mit konkreter Eskalation.

Maßnahme 9: Service Accounts sichern

Service Accounts sind die stille Schwachstelle vieler AD-Umgebungen. Sie laufen unbeaufsichtigt, ihre Passwörter werden selten oder nie geändert, und sie haben häufig übermäßige Berechtigungen, weil bei der Einrichtung niemand genau geprüft hat, welche Rechte der Dienst wirklich braucht.

In einer typischen 100-Mitarbeiter-Umgebung findest du leicht 10 bis 30 Service Accounts: für den SQL Server, den Backup-Agenten, den Monitoring-Dienst, die ERP-Software, den Druckserver, den SCCM-Agenten und diverse kleinere Tools. Bei einer Bestandsaufnahme stellt sich regelmäßig heraus, dass mehrere dieser Accounts Mitglied der Gruppe Domain Admins sind (weil es bei der Einrichtung Berechtigungsprobleme gab und jemand den schnellen Weg gewählt hat), dass ihre Passwörter seit der Einrichtung vor Jahren nicht geändert wurden, und dass niemand genau weiß, welche Dienste sie eigentlich noch nutzen.

Schritt 1: Bestandsaufnahme. Identifiziere alle Service Accounts in deiner Domain. Per PowerShell liefert Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties ServicePrincipalName, PasswordLastSet, MemberOf eine Liste aller Accounts mit SPN, letztem Passwortdatum und Gruppenmitgliedschaften.

Schritt 2: Rechte minimieren. Entferne jeden Service Account aus der Gruppe Domain Admins. Vergib stattdessen die minimalen Rechte, die der Dienst tatsächlich benötigt. In den meisten Fällen reicht eine lokale Gruppe auf dem Zielserver oder eine dedizierte OU-basierte Delegation.

Schritt 3: Auf gMSA umstellen. Stelle jeden Service Account, bei dem der Dienst gMSA unterstützt, auf ein Group Managed Service Account um. Die automatische Passwortrotation eliminiert das Risiko vergessener, nie geänderter Passwörter.

Schritt 4: Passwort-Richtlinie für verbleibende Service Accounts. Für Service Accounts, die kein gMSA nutzen können, gilt: Passwortlänge mindestens 30 Zeichen, zufällig generiert, Rotation mindestens jährlich. Dokumentiere jede Passwortänderung und den Prozess, der dafür nötig ist (welche Dienste müssen neu gestartet werden, welche Konfigurationen müssen aktualisiert werden).

Schritt 5: Interaktive Anmeldung verbieten. Service Accounts müssen sich als Dienst anmelden, nicht interaktiv. Setze per GPO „Deny log on locally" und „Deny log on through Remote Desktop Services" für alle Service Accounts. Das verhindert, dass ein Angreifer einen kompromittierten Service Account für interaktive Anmeldungen missbraucht.

Maßnahme 10: AD-Backup und Recovery

Alle vorherigen Maßnahmen zielen darauf ab, eine Kompromittierung von Active Directory zu verhindern oder frühzeitig zu erkennen. Aber was, wenn der schlimmste Fall eintritt? Was, wenn ein Angreifer tatsächlich Domain-Admin-Rechte erlangt, die AD-Datenbank manipuliert oder deine Domain Controller verschlüsselt hat?

Ohne ein funktionsfähiges AD-Backup ist die Antwort einfach und schmerzhaft: Du baust die gesamte IT-Umgebung von Grund auf neu auf. Das dauert Wochen, manchmal Monate, und es ist der Albtraum jeder IT-Abteilung.

Ein AD-Backup muss mehr sein als ein Dateisystem-Backup der Domain Controller. Die AD-Datenbank (NTDS.dit) muss konsistent gesichert werden, also im Zustand eines bestimmten Zeitpunkts, nicht als Sammlung einzeln gesicherter Dateien. Windows Server Backup mit der Option „System State" sichert die AD-Datenbank, die SYSVOL-Freigabe, die Registry und die Zertifikatsdienste-Datenbank in einem konsistenten Zustand.

Backup-Strategie für AD:

Sichere den System State mindestens täglich. Die Aufbewahrungsfrist muss die Tombstone Lifetime deiner Domain abdecken (standardmäßig 180 Tage, mindestens jedoch 60 Tage). Ein Backup, das älter ist als die Tombstone Lifetime, kann nicht für eine autoritative Wiederherstellung verwendet werden.

Speichere mindestens eine Backup-Kopie offline oder auf einem System, das nicht domänengebunden ist. Der Grund: Wenn ein Angreifer die Domain kompromittiert hat, hat er auch Zugriff auf alle domänengebundenen Backup-Systeme. Ein Backup auf einem domänengebundenen Backup-Server ist in diesem Szenario wertlos, weil der Angreifer es löschen oder verschlüsseln kann.

Recovery-Verfahren dokumentieren und testen:

Ein Backup, das du nie getestet hast, ist kein Backup. Es ist eine Hoffnung. Dokumentiere das Recovery-Verfahren Schritt für Schritt: Wie stelle ich einen Domain Controller aus dem Backup wieder her? Wie führe ich eine autoritative Wiederherstellung durch, wenn die AD-Datenbank manipuliert wurde? Wie stelle ich SYSVOL wieder her?

Teste das Recovery mindestens einmal jährlich in einer isolierten Testumgebung. Dabei stellst du nicht nur fest, ob das Backup technisch funktioniert, sondern auch, wie lange die Wiederherstellung dauert. Diese Information ist essenziell für deine Business-Impact-Analyse und deinen Wiederanlaufplan.

Forest Recovery als Worst Case: Wenn die gesamte Forest-Struktur kompromittiert wurde, benötigst du einen AD Forest Recovery. Der Prozess ist komplex: Alle Domain Controller herunterfahren, einen DC aus dem Backup wiederherstellen, Metadata bereinigen, KRBTGT-Passwort zweimal zurücksetzen, dann die übrigen DCs neu promovieren. Plane für dieses Szenario ein dokumentiertes Runbook.

Priorisierung für 100-Mitarbeiter-Unternehmen

Nicht alle zehn Maßnahmen müssen gleichzeitig umgesetzt werden. Für ein Unternehmen mit rund 100 Mitarbeitern, einer Domain und einer kleinen IT-Abteilung empfiehlt sich folgende Priorisierung:

Sofort (Woche 1-2)

1. LAPS implementieren – schnell umsetzbar, sofortige Wirkung, niedrige Komplexität.
2. Protected Users für alle Admin-Accounts – fünf Minuten Aufwand, enormer Sicherheitsgewinn.
3. Service Accounts aus Domain Admins entfernen – erfordert Prüfung, aber jeder Tag mit einem Service Account in Domain Admins ist ein Tag mit unnötigem Risiko.

Kurzfristig (Monat 1-2)

4. Tiered Administration – konzeptionell anspruchsvoller, aber das Fundament für alles Weitere.
5. GPO Hardening – nutze die Microsoft Security Baselines als Startpunkt.
6. Monitoring kritischer Event-IDs – auch ohne SIEM kannst du mit Windows Event Forwarding und PowerShell-Skripten starten.

Mittelfristig (Monat 3-6)

7. Credential Guard aktivieren – erfordert Kompatibilitätstests, lohnt sich aber.
8. Kerberoasting-Schutz – gMSA-Migration und Passwort-Härtung für Service Accounts.
9. AdminSDHolder absichern – einmalige Prüfung plus regelmäßiges Monitoring.
10. AD-Backup und Recovery testen – wenn du noch kein System-State-Backup machst, starte sofort. Den Recovery-Test planst du als Projekt ein.

Das Zusammenspiel der Maßnahmen

Die zehn Maßnahmen wirken nicht isoliert, sondern sie greifen ineinander. Tiered Administration verhindert, dass Admin-Credentials auf Endgeräten landen. Falls sie doch dort landen (weil jemand die Regeln umgeht), verhindert Credential Guard das Auslesen. Falls Credential Guard nicht aktiv ist (auf älteren Systemen), verhindert Protected Users zumindest das Caching von NTLM-Hashes. Falls der Angreifer trotzdem an Credentials kommt, begrenzt LAPS den Schaden auf einen einzelnen Rechner statt das gesamte Netzwerk. Und das Monitoring erkennt die verdächtigen Aktivitäten, die jeder dieser Schritte hinterlässt.

Diese Tiefenstaffelung, auch bekannt als Defense in Depth, ist das Prinzip, das jede seriöse Sicherheitsarchitektur leitet. Keine einzelne Maßnahme ist perfekt, aber die Kombination macht es einem Angreifer so schwer, dass er sich ein leichteres Ziel sucht.

Für dein ISMS bedeutet das: Dokumentiere jede Maßnahme als eigenes Control, definiere Soll-Zustand und Verantwortlichkeit, und überprüfe den Fortschritt im Management-Review. In ISMS Lite lassen sich die zehn AD-Härtungsmaßnahmen als Controls mit Umsetzungsstatus und Verantwortlichen anlegen und direkt den ISO-27001-Anforderungen zuordnen. So wird die AD-Härtung zu einem integralen Bestandteil deines Informationssicherheitsmanagementsystems.

Weiterführende Artikel

• Berechtigungskonzept erstellen: Rollen, Rechte und Genehmigungsworkflow
• Die 10 größten Sicherheitsrisiken im Mittelstand und wie du sie adressierst
• MFA einführen: Multi-Faktor-Authentifizierung im Unternehmen umsetzen
• Ransomware-Angriff: Sofortmaßnahmen und Wiederherstellung

Die zehn Maßnahmen in diesem Artikel geben dir einen konkreten Fahrplan. Fang mit den Quick Wins an, baue die komplexeren Maßnahmen schrittweise auf und dokumentiere jeden Schritt. Dein Auditor wird es dir danken, und im Ernstfall wirst du froh sein, dass du nicht gewartet hast.