In vielen Umgebungen ist Active Directory der Dreh- und Angelpunkt für Identitäten, Berechtigungen und Geräteverwaltung. Genau deshalb zielen Angreifer oft zuerst auf Domain-Services: Wer ein Konto mit hohen Rechten erlangt, kann Passwörter zurücksetzen, Software verteilen oder Sicherheitsfunktionen abschalten. Stabiler Schutz entsteht nicht durch ein einzelnes Feature, sondern durch saubere Protokollhärtung, konsequente Rechtevergabe und überprüfbare Standards in den Gruppenrichtlinien.
Der folgende Leitfaden konzentriert sich auf drei Stellen, an denen in der Praxis besonders häufig Sicherheitslücken entstehen: Authentifizierung (Kerberos), Verzeichniszugriff (LDAP) und Konfigurationsdurchsetzung (GPO). Ergänzend kommen Baselines für Admin-Konten, Service-Accounts und Replikationsrechte dazu. Für angrenzende Themen wie Onboarding und Endpunktschutz lohnt außerdem ein Blick auf sicheres Onboarding und Windows Defender richtig konfigurieren.
Warum Active Directory so oft der Kipppunkt im Angriff ist
Typische Angriffsketten: von einem Client zur Domain
Ein häufiges Muster: Erst wird ein Client kompromittiert (Phishing, Malware, ungepatchte Anwendung), dann werden Anmeldeinformationen abgegriffen und im Netzwerk „seitlich“ weitergenutzt. Im AD-Kontext bedeutet das oft: lokale Adminrechte → Credential Dumping → Zugriff auf Dateifreigaben/Management-Server → Domänenrechte. Je homogener die Umgebung und je stärker die Berechtigungen „mitwandern“, desto schneller geht diese Kette auf.
Besonders kritisch sind dabei administrative Workflows, bei denen Domain-Admin-Konten sich auf normalen Clients anmelden oder Tools ausführen. Jede Anmeldung hinterlässt verwertbare Spuren (Tokens, Tickets, Hashes). Effektive Härtung trennt daher Rollen, Systeme und Anmeldepfade.
Was in AD-Umgebungen realistisch schiefgeht
- Zu breite Gruppenmitgliedschaften (z. B. IT-Helpdesk mit unnötigen Domänenrechten).
- Service-Accounts mit Kennwort „läuft seit Jahren“ und ohne Einschränkungen.
- Legacy-Protokolle oder unverschlüsseltes LDAP im internen Netz.
- GPOs, die lokale Administratoren verteilen oder Sicherheitsfeatures lockern.
- Unklare Verantwortlichkeiten: niemand „besitzt“ die Baseline.
Kerberos-Härtung: Tickets, Delegation und Kontorichtlinien
Kerberos verstehen, ohne tief abzutauchen
Kerberos (Ticket-basiertes Authentifizierungsprotokoll) arbeitet mit Tickets, die von einem Key Distribution Center (KDC) ausgestellt werden. Angreifer profitieren, wenn Tickets lange gültig sind, wenn privilegierte Konten auf unsicheren Systemen Tickets anfordern oder wenn Delegation falsch genutzt wird. Ziel ist, Ticket-Missbrauch zu erschweren und privilegierte Anmeldungen kontrollierbar zu machen.
Delegation restriktiv handhaben
Delegation ist funktional (z. B. Webdienst greift im Namen eines Nutzers auf Backend zu), aber riskant. In vielen Umgebungen ist Delegation historisch „einfach eingeschaltet“ worden, ohne die tatsächlichen Flows zu dokumentieren.
- Unconstrained Delegation vermeiden; nur nutzen, wenn zwingend erforderlich und klar begründet.
- Wo möglich Constrained Delegation einsetzen und auf benötigte Dienste begrenzen.
- Für hochprivilegierte Konten Delegation grundsätzlich ausschließen (Account-Option „Account is sensitive and cannot be delegated“ prüfen).
Privilegierte Konten: Anmeldewege und Ticket-Risiken
Domain-Admin und vergleichbare Rollen gehören auf dedizierte Admin-Workstations/Jump-Hosts, nicht auf Office-Clients. Das reduziert Ticket-Ausstellung auf potenziell kompromittierten Endpunkten deutlich. Ergänzend sollten Admins im Alltag mit nichtprivilegierten Konten arbeiten und nur für konkrete Tätigkeiten eskalieren.
In gemischten Umgebungen hilft eine saubere Trennung der Admin-Ebenen (z. B. Tiering): Domäne/Identität (Tier 0) getrennt von Server-Administration (Tier 1) und Client-Administration (Tier 2). Diese Trennung ist weniger „Theorie“, als vielmehr eine praktische Maßnahme gegen laterale Bewegung.
LDAP absichern: Verschlüsselung, Signierung und sinnvolle Filter
Warum ungesichertes LDAP im internen Netz ein echtes Problem ist
LDAP (Verzeichniszugriffsprotokoll) wird für Abfragen und teilweise auch für Authentifizierung genutzt. Ohne passende Schutzmaßnahmen können Inhalte im Netz mitgelesen oder manipuliert werden, besonders in Segmenten mit vielen Clients, Gastgeräten oder unsauberen Switch-Konfigurationen. Selbst in „vertrauenswürdigen“ LANs ist Verschlüsselung Standardhygiene, weil interne Netze nicht automatisch vertrauenswürdig sind.
LDAPS und LDAP-Signing korrekt einführen
Für die Praxis zählt vor allem, dass Clients und Anwendungen nicht stillschweigend auf unsichere Varianten zurückfallen. Die Umstellung sollte geplant erfolgen, damit Altanwendungen nicht den Betrieb stören.
- LDAPS (LDAP über TLS) für Verzeichnisabfragen und Bind-Operationen bevorzugen.
- LDAP-Signing erzwingen, damit Manipulationen am Transport erschwert werden.
- Client-seitig testen, welche Anwendungen noch „Simple Bind“ ohne TLS nutzen.
- Übergangsphase definieren: erst auditieren, dann gezielt umstellen, dann erzwingen.
Wichtig ist das Change-Management: Vor dem Erzwingen muss klar sein, welche Systeme betroffen sind (z. B. NAS, Druckmanagement, Legacy-Apps). Wird zu früh hart geschaltet, entstehen unnötige Ausfälle – wird nie hart geschaltet, bleibt die Lücke dauerhaft offen.
Gruppenrichtlinien sicher gestalten: weniger Macht, mehr Nachvollziehbarkeit
GPOs als Sicherheitswerkzeug statt als „Konfigurations-Sammelbecken“
Gruppenrichtlinien (GPO) sind in vielen Umgebungen das mächtigste Verteilwerkzeug. Genau diese Macht wird missbraucht, wenn Angreifer GPOs ändern oder neue GPOs verlinken können. Schutz bedeutet daher: Berechtigungen auf GPO-Objekten härten, Änderungen nachvollziehbar machen und Inhalte so gestalten, dass sie nicht als Hintertür taugen.
GPO-Berechtigungen und Änderungswege absichern
- Bearbeitungsrechte auf GPOs nur für klar definierte Admin-Gruppen (kein „Jeder IT-Admin“).
- Trennung von „GPO erstellen“ und „GPO verlinken“: Link-Rechte besonders kritisch behandeln.
- Änderungen dokumentieren (Change-Tickets/Commit-Logik), damit unerwartete Anpassungen auffallen.
- GPOs für Tier-0-Systeme strikt getrennt halten (separate OUs, separate Admins).
Lokale Adminrechte: gezielt statt flächig
Ein Klassiker: GPOs, die lokale Administratoren breit vergeben, um Support zu vereinfachen. Das reduziert kurzfristig Aufwand, erhöht aber massiv das Risiko für Credential Theft und späteres Domänen-Eskalieren.
Stattdessen: lokale Adminrechte nur nach Bedarf, zeitlich begrenzt und nachvollziehbar. Falls ein zentrales Konzept für lokale Administratoren existiert (z. B. passwortbasierte Rotation pro Gerät), sollte dieses Konzept konsequent sein und nicht durch Ausnahmen unterlaufen werden.
Service Accounts: die leisen Dauerrisiken in jeder Domäne
Wo Service-Accounts typischerweise zu weit gehen
Service-Konten laufen oft jahrelang, sind in Skripten hinterlegt und haben „zur Sicherheit“ hohe Rechte. Damit sind sie ideale Ziele: Sie sind dauerhaft aktiv, schwer zu ändern und häufig kaum überwacht. Typische Probleme sind Domänen-Admin-Mitgliedschaften, interaktive Anmelderechte oder fehlende Einschränkungen beim Logon.
Praktische Leitplanken für Service-Accounts
- Rechte minimal vergeben: nur die Ressourcen, die der Dienst wirklich braucht.
- Interaktive Anmeldung verbieten, wo nicht erforderlich (keine Anmeldung an Workstations).
- Passwortwechsel planbar machen (Wartungsfenster, Abhängigkeiten dokumentieren).
- Wenn möglich: Managed Service Accounts nutzen, um Passwortverwaltung zu automatisieren.
Ein hilfreicher Realitätscheck: Wenn ein Dienstkonto „alles darf“, ist das Problem selten technisch nötig, sondern organisatorisch. Der Aufwand liegt meist in fehlender Doku der Abhängigkeiten.
Ein schneller Härtungsdurchlauf, der im Alltag funktioniert
Schritte, die sich ohne Großprojekt umsetzen lassen
- Alle Domain-Admin-Anmeldungen der letzten Wochen prüfen und auf Admin-Workstations umstellen.
- GPO-Berechtigungen inventarisieren: Wer darf bearbeiten, wer darf verlinken?
- LDAP-Nutzung erfassen: Welche Systeme binden ohne TLS, welche können nicht?
- Service-Accounts auf hohe Rechte prüfen und interaktive Logons entfernen.
- Admin-Gruppenmitgliedschaften aufräumen (Helpdesk, Server-Admins, GPO-Admins trennen).
- Für wiederkehrende Admin-Aufgaben separate Konten und klar definierte Rollen verwenden.
Kontrolle und Monitoring: Woran sich Fortschritt messen lässt
Was im Betrieb sichtbar sein sollte
Härtung ohne Kontrolle hält selten. Mindestens sollten Änderungen an sicherheitsrelevanten Objekten sichtbar und auswertbar sein: GPO-Änderungen, Änderungen an Admin-Gruppen, neue Service-Principal-Names, Delegation-Flags und Kontooptionen. Werden diese Ereignisse zentral gesammelt, lassen sich Auffälligkeiten schneller einordnen. Für die Log-Auswertung ist ein strukturierter Ansatz hilfreich, wie er bei Windows-Logs auswerten beschrieben ist.
Kurze Orientierung: „Was ist riskant, was ist normal?“
| Beobachtung | Einordnung | Praktischer nächster Schritt |
|---|---|---|
| Domain-Admin meldet sich an Office-Client an | hoch riskant | Admin-Workstation einführen, Anmeldepfade blocken |
| Neue GPO wird auf zentrale OU verlinkt | kritisch zu prüfen | Change-Quelle validieren, Berechtigungen auf Link-Rechte prüfen |
| LDAP-Binds ohne TLS aus Client-Netz | vermeidbares Risiko | Betroffene Systeme identifizieren, Umstellung auf LDAPS planen |
| Service-Account ist Mitglied in Domain Admins | meist unnötig | Rechte reduzieren, Abhängigkeiten dokumentieren, Tests im Wartungsfenster |
| Delegation auf vielen Computerkonten aktiv | häufig Altlast | Delegation-Audit, nur begründete Ausnahmen behalten |
Zusammenspiel mit Endpoint- und Netzwerkmaßnahmen
Warum AD-Härtung alleine nicht reicht
AD-Sicherheit hängt eng mit Client- und Server-Härtung zusammen. Wenn Endpunkte leicht kompromittierbar sind oder Admins täglich auf unsicheren Systemen arbeiten, bleibt Kerberos- und GPO-Härtung nur teilweise wirksam. Gleichzeitig ist AD-Härtung ein Hebel, der viele Angriffe früh abwürgt: weniger privilegierte Anmeldungen, weniger mächtige GPOs, weniger verwertbare Service-Konten.
In der Praxis ergänzt sich das mit Maßnahmen wie sauberes Patchen (Updates testen, ausrollen, überwachen) und dem konsequenten Entfernen unsicherer Fernzugriffe, falls solche historisch gewachsen sind.
Häufige Stolpersteine bei der Umstellung
Legacy-Anwendungen und „stille“ Abhängigkeiten
Viele AD-Härtungen scheitern nicht an der Technik, sondern an unbekannten Abhängigkeiten: alte Scanner-Software, NAS-Integrationen, Java-Anwendungen, Druckdienste oder proprietäre Appliances. Deshalb ist ein auditierbarer Übergang wichtig: erst erfassen, dann gezielt modernisieren, erst danach erzwingen. Gerade bei LDAP ist das die entscheidende Reihenfolge.
Zu große Änderungen auf einmal
Ein häufiger Fehler ist das gleichzeitige Anziehen vieler Stellschrauben: LDAP-Signing erzwingen, GPOs umbauen, Admin-Gruppen aufräumen, Service-Accounts ändern. Besser ist ein Etappenplan, bei dem nach jeder Stufe geprüft wird, was wirklich besser wurde (weniger riskante Logons, weniger unsichere Binds, weniger überprivilegierte Konten).
Begriffe, die in Tickets und Doku klar benannt sein sollten
Konkrete Formulierungen helfen gegen Missverständnisse
In Change-Tickets und internen Dokus sollten die Ziele eindeutig sein: „LDAP über TLS für Anwendung X“, „GPO-Link-Rechte nur Gruppe Y“, „Service-Account Z ohne interaktives Logon“, „Delegation nur für definierte SPNs“. Solche Formulierungen sind prüfbar. Unscharfe Ziele wie „AD sicherer machen“ führen dagegen oft zu Diskussionen ohne messbares Ergebnis.
Active Directory Härtung ist damit keine einmalige Aufgabe, sondern eine fortlaufende Qualitätsarbeit: Rechte klein halten, Protokolle robust konfigurieren, Änderungen nachvollziehbar machen und die wenigen wirklich kritischen Konten besonders schützen. Werden diese Punkte umgesetzt, sinkt die Chance deutlich, dass ein einzelner kompromittierter Client zur Domänenübernahme führt.
