Active Directory kann jahrelang zuverlässig funktionieren und trotzdem sicherheitstechnisch problematisch konfiguriert sein. Anmeldungen funktionieren, Gruppenrichtlinien werden verteilt und Anwendungen erreichen ihre Server. Im Tagesgeschäft gibt es deshalb oft keinen offensichtlichen Hinweis darauf, dass sich über die Jahre riskante Berechtigungen oder veraltete Einstellungen angesammelt haben.
Ein ehemaliges Projektkonto besitzt noch administrative Rechte. Ein Service Account läuft seit Jahren mit demselben Passwort. Eine alte Group Policy enthält eine Ausnahme, die längst nicht mehr benötigt wird. Auf zahlreichen Windows-Systemen wird dasselbe lokale Administratorkennwort verwendet. Solche Konfigurationen sind in gewachsenen IT-Umgebungen keine Seltenheit.
Für die Sicherheit ist entscheidend, diese Altlasten systematisch zu identifizieren. Eine Fehlkonfiguration ist dabei nicht automatisch eine Software-Schwachstelle und schon gar nicht zwingend eine CVE. Sie kann aber die Angriffsfläche vergrößern und die Folgen einer kompromittierten Identität oder eines infizierten Systems erheblich verstärken.
Dieser Artikel zeigt fünf Bereiche, die Administratoren bei einem Active-Directory-Sicherheitscheck besonders genau betrachten sollten.
1. Zu viele privilegierte Konten und unkontrollierte Domain-Admin-Berechtigungen
Was ist die Fehlkonfiguration?
Eine der kritischsten Konfigurationen ist eine zu große Zahl dauerhaft privilegierter Konten. Besonders relevant ist die Gruppe „Domain Admins“, aber auch andere privilegierte Gruppen und delegierte Berechtigungen müssen berücksichtigt werden.
Problematisch sind beispielsweise Benutzerkonten, die zusätzlich zu ihrer normalen Tätigkeit dauerhaft administrative Rechte besitzen, gemeinsam genutzte Administratorkonten oder Konten, deren Berechtigungen ursprünglich nur vorübergehend erforderlich waren.
Auch verschachtelte Gruppen können die tatsächlichen Rechte schwer nachvollziehbar machen. Ein Benutzer muss nicht unmittelbar Mitglied einer besonders privilegierten Gruppe sein, um über eine Gruppenmitgliedschaft weitreichende Berechtigungen zu erhalten.
Warum entsteht dieses Problem so häufig?
Berechtigungen wachsen in vielen Unternehmen schrittweise. Für eine Migration werden zusätzliche Rechte vergeben, ein Administrator übernimmt neue Aufgaben oder ein Dienst erhält für eine Fehleranalyse vorübergehend erhöhte Berechtigungen.
Das Problem entsteht häufig nicht durch eine einzelne falsche Entscheidung, sondern dadurch, dass niemand später überprüft, ob die ursprüngliche Berechtigung noch notwendig ist.
Hinzu kommen organisatorische Veränderungen: Mitarbeiter wechseln die Abteilung, externe Dienstleister beenden Projekte und Systeme werden ersetzt. Die dazugehörigen Berechtigungen bleiben jedoch manchmal bestehen.
Warum ist das gefährlich?
Privilegierte Konten sind besonders attraktive Ziele, weil eine Kompromittierung weitreichende Auswirkungen haben kann. Je mehr solche Konten existieren und je häufiger sie im Alltag verwendet werden, desto größer ist die Zahl der Identitäten, die besonders geschützt und überwacht werden müssen.
Nach einer erfolgreichen Kompromittierung können Angreifer versuchen, vorhandene Berechtigungen für weitere Aktionen innerhalb der Umgebung auszunutzen. Die konkreten Möglichkeiten hängen von der Active-Directory-Struktur, den verfügbaren Schutzmaßnahmen und den Rechten des betroffenen Kontos ab.
Wie erkennt ein Administrator das Problem?
Prüfen Sie zunächst alle privilegierten Gruppen und berücksichtigen Sie dabei direkte und indirekte Mitgliedschaften. Eine sinnvolle Bestandsaufnahme beantwortet mindestens folgende Fragen:
- Wer besitzt administrative Rechte?
- Warum werden diese Rechte benötigt?
- Sind persönliche Administratorkonten vorhanden?
- Gibt es gemeinsam verwendete Konten?
- Welche Konten stammen aus abgeschlossenen Projekten?
- Besitzen Service Accounts unnötige administrative Rechte?
- Gibt es delegierte Berechtigungen außerhalb der offensichtlichen Administratorgruppen?
Eine gute Dokumentation ordnet jedem privilegierten Konto einen Zweck und einen Verantwortlichen zu.
Wie lässt sich das Problem beheben?
Nicht mehr benötigte Mitgliedschaften sollten entfernt werden. Administratoren sollten für alltägliche Aufgaben separate Standardkonten verwenden und administrative Tätigkeiten über getrennte privilegierte Konten durchführen.
Mittelfristig empfiehlt sich ein rollenbasiertes Berechtigungsmodell mit regelmäßiger Rezertifizierung. Besonders privilegierte Zugriffe sollten möglichst kontrolliert, nachvollziehbar und – sofern technisch und organisatorisch sinnvoll – zeitlich begrenzt werden.
Was sollte anschließend überwacht werden?
Sicherheitsrelevant sind insbesondere Änderungen an privilegierten Gruppen, neue administrative Konten, ungewöhnliche Anmeldungen und unerwartete Änderungen an Berechtigungen.
Schnellcheck:
- Sind alle Mitglieder privilegierter Gruppen bekannt?
- Werden indirekte Gruppenmitgliedschaften berücksichtigt?
- Haben Administratoren getrennte Konten?
- Gibt es gemeinsam genutzte Administratorkonten?
- Werden privilegierte Berechtigungen regelmäßig rezertifiziert?
2. Unsichere Service Accounts und schlecht verwaltete Kerberos-Dienstidentitäten
Was ist die Fehlkonfiguration?
Service Accounts werden von Anwendungen, Datenbanken, Diensten oder geplanten Aufgaben verwendet. Sicherheitsprobleme entstehen, wenn diese Konten unnötig viele Rechte besitzen, über lange Zeit unveränderte Passwörter verwenden oder interaktive Anmeldungen ermöglichen, obwohl dies für ihre Aufgabe nicht erforderlich ist.
Im Zusammenhang mit Kerberos spielen außerdem Service Principal Names, kurz SPNs, eine wichtige Rolle. Dienstidentitäten müssen korrekt zugeordnet und verwaltet werden. Eine unsaubere Konfiguration kann die Kontrolle über Dienstkonten erschweren.
Warum entsteht dieses Problem so häufig?
Viele Service Accounts stammen aus einer Zeit, in der Anwendungen manuell installiert wurden. Ein Dienst wurde mit einem Domänenkonto eingerichtet, das Passwort anschließend dokumentiert und über Jahre nicht mehr angefasst.
Bei späteren Änderungen weiß möglicherweise niemand mehr genau, welche Systeme das Konto verwenden. Eine Passwortänderung kann dann als riskant erscheinen, weil Abhängigkeiten nicht bekannt sind.
Warum ist das gefährlich?
Service Accounts sind häufig dauerhaft aktiv und besitzen Zugriff auf bestimmte Server oder Anwendungen. Wird ein solches Konto kompromittiert, können die Auswirkungen deshalb über den einzelnen Benutzer hinausgehen.
Besonders problematisch ist die Kombination aus einem alten Passwort, weitreichenden Berechtigungen und einer großen Zahl erreichbarer Systeme.
Kerberos selbst ist dabei nicht die Schwachstelle. Das Risiko entsteht häufig aus der unsicheren Verwaltung der Dienstidentitäten und ihrer Berechtigungen.
Wie erkennt ein Administrator das Problem?
Für jedes Servicekonto sollte bekannt sein:
- welcher Dienst es verwendet
- wer fachlich und technisch verantwortlich ist
- welche Gruppenmitgliedschaften bestehen
- auf welchen Systemen Berechtigungen vorhanden sind
- wann das Kennwort zuletzt geändert wurde
- welche SPNs zugeordnet sind
- ob interaktive Anmeldungen möglich sind
- ob das Konto überhaupt noch benötigt wird
Für geeignete Szenarien können Group Managed Service Accounts, kurz gMSA, die Verwaltung von Dienstpasswörtern vereinfachen.
Wie lässt sich das Problem beheben?
Zunächst sollten unnötige Gruppenmitgliedschaften und Berechtigungen entfernt werden. Reine Dienstkonten sollten nicht ohne Grund für interaktive Anmeldungen verwendet werden.
Wo Anwendungen dies unterstützen, sollte geprüft werden, ob ein verwaltetes Dienstkonto wie gMSA eingesetzt werden kann. Für bestehende Service Accounts sollten Passwortwechsel geplant und Abhängigkeiten dokumentiert werden.
Was sollte anschließend überwacht werden?
Überwachen Sie insbesondere neue Service Accounts, Änderungen an deren Gruppenmitgliedschaften, Änderungen an SPNs und ungewöhnliche Anmeldungen von Dienstidentitäten.
Schnellcheck:
- Sind alle Service Accounts inventarisiert?
- Ist für jedes Konto ein Verantwortlicher bekannt?
- Sind die Berechtigungen auf das Notwendige beschränkt?
- Werden verwaltete Dienstkonten für geeignete Anwendungen genutzt?
- Werden ungewöhnliche Anmeldungen von Service Accounts überwacht?
3. Zu weitreichende oder veraltete Group Policies
Was ist die Fehlkonfiguration?
Group Policies, kurz GPOs, steuern zahlreiche sicherheitsrelevante Windows-Einstellungen. Eine falsch konzipierte oder historisch gewachsene GPO-Struktur kann dazu führen, dass Sicherheitsvorgaben abgeschwächt oder Ausnahmen unkontrolliert auf viele Systeme angewendet werden.
Problematisch sind beispielsweise alte GPOs, widersprüchliche Richtlinien, unnötig weit gefasste Verknüpfungen oder Ausnahmen, deren ursprünglicher Zweck nicht mehr bekannt ist.
Warum entsteht dieses Problem so häufig?
In größeren Unternehmen werden GPOs häufig über Jahre erweitert. Neue Anwendungen benötigen Ausnahmen, Abteilungen erhalten spezielle Einstellungen und nach einer Migration bleiben alte Richtlinien zunächst bestehen.
Das führt nicht zwangsläufig zu einem unmittelbaren Sicherheitsproblem. Die Schwierigkeit besteht darin, dass die effektive Konfiguration irgendwann schwer nachvollziehbar wird.
Warum ist das gefährlich?
Eine fehlerhafte Einstellung in einer GPO kann eine große Zahl von Systemen gleichzeitig betreffen. Anders als bei einer einzelnen lokalen Fehlkonfiguration kann der Wirkungsbereich deshalb sehr groß sein.
Besonders relevant sind Richtlinien für Benutzerrechte, Sicherheitsoptionen, Firewall, Auditierung, Konten und administrative Einstellungen.
Wie erkennt ein Administrator das Problem?
Prüfen Sie nicht nur den Inhalt einzelner GPOs. Entscheidend ist, welche Richtlinien tatsächlich auf Clients und Server angewendet werden.
Kontrollieren Sie:
- Verknüpfungen von GPOs
- Vererbung und Prioritäten
- Sicherheitsfilter
- alte Richtlinien
- dokumentierte Ausnahmen
- widersprüchliche Einstellungen
- tatsächlich angewendete Richtlinien auf repräsentativen Systemen
Ein kleiner Kreis ausgewählter Testsysteme kann helfen, Änderungen nachvollziehbar zu überprüfen, bevor sie auf größere Bereiche ausgerollt werden.
Wie lässt sich das Problem beheben?
Nicht mehr benötigte GPOs sollten nach einer fachlichen Prüfung entfernt oder außer Betrieb genommen werden. Ausnahmen sollten einen dokumentierten Zweck und möglichst einen verantwortlichen Eigentümer haben.
Für wichtige Sicherheitskonfigurationen empfiehlt sich ein kontrollierter Änderungsprozess. Änderungen sollten zunächst getestet und anschließend überwacht werden.
Was sollte anschließend überwacht werden?
Sinnvoll sind Überwachung und Protokollierung von Änderungen an kritischen GPOs. Besonders wichtig sind Änderungen an Benutzerrechten, Sicherheitsoptionen und Auditierung.
Schnellcheck:
- Sind alle produktiven GPOs dokumentiert?
- Gibt es veraltete oder ungenutzte Richtlinien?
- Sind Ausnahmen begründet und dokumentiert?
- Ist bekannt, welche GPOs tatsächlich auf kritische Systeme wirken?
- Werden Änderungen an wichtigen GPOs überwacht?
4. Legacy-Authentifizierung mit NTLM und unzureichend abgesichertes LDAP
Was ist die Fehlkonfiguration?
Viele Active-Directory-Umgebungen enthalten noch ältere Anwendungen, Geräte oder Schnittstellen, die auf Legacy-Authentifizierung angewiesen sind.
NTLM ist hierfür ein bekanntes Beispiel. Auch LDAP verdient besondere Aufmerksamkeit. Entscheidend ist, dass Verzeichniszugriffe und Authentifizierung angemessen abgesichert werden und nicht unnötig auf ältere oder schwächere Verfahren angewiesen sind.
Warum entsteht dieses Problem so häufig?
Die Ursache liegt oft in Altanwendungen. Ein mehrere Jahre altes Gerät, eine Fachanwendung oder ein Dienst unterstützt moderne Authentifizierungsverfahren nicht vollständig.
Eine sofortige Abschaltung von NTLM oder die Umstellung einer LDAP-Verbindung kann dann den Betrieb beeinträchtigen. Aus diesem Grund bleiben Ausnahmen bestehen – manchmal deutlich länger als ursprünglich geplant.
Warum ist das gefährlich?
Legacy-Authentifizierung kann zusätzliche Angriffsmöglichkeiten schaffen und moderne Schutzmechanismen einschränken. NTLM kann beispielsweise in bestimmten Konstellationen für Relay-Szenarien relevant sein. Unsicher abgesicherte LDAP-Kommunikation kann ebenfalls Risiken für die Vertraulichkeit und Integrität der Kommunikation schaffen.
Das bedeutet nicht, dass jede NTLM-Nutzung automatisch zu einem Sicherheitsvorfall führt. Entscheidend sind die konkrete Umgebung, die eingesetzten Schutzmaßnahmen und der Grund für die Nutzung.
Wie erkennt ein Administrator das Problem?
Ein guter Ausgangspunkt ist die Analyse der vorhandenen Authentifizierungsereignisse.
Prüfen Sie:
- Wo wird NTLM noch verwendet?
- Welche Anwendungen und Geräte sind dafür verantwortlich?
- Welche Systeme unterstützen Kerberos?
- Welche Anwendungen greifen per LDAP auf Active Directory zu?
- Sind LDAP-Verbindungen angemessen abgesichert?
- Welche Legacy-Ausnahmen sind dokumentiert?
Die Identifikation der Abhängigkeiten sollte vor einer weitreichenden Deaktivierung erfolgen.
Wie lässt sich das Problem beheben?
Zunächst sollten nicht mehr benötigte Legacy-Abhängigkeiten entfernt werden. Anwendungen und Geräte, die moderne Verfahren unterstützen, sollten entsprechend umgestellt werden.
Für verbleibende Ausnahmen empfiehlt sich eine Dokumentation mit Verantwortlichem, technischem Grund und geplantem Ablösungstermin.
Bei LDAP sollten sichere Kommunikations- und Authentifizierungsverfahren eingesetzt und veraltete Konfigurationen schrittweise beseitigt werden.
Was sollte anschließend überwacht werden?
Nach Änderungen an der Authentifizierung sollte kontrolliert werden, ob weiterhin unerwartete NTLM-Nutzung auftritt und ob neue Legacy-Abhängigkeiten entstehen.
Schnellcheck:
- Ist bekannt, welche Systeme noch NTLM verwenden?
- Sind die dafür verantwortlichen Anwendungen dokumentiert?
- Werden LDAP-Verbindungen auf eine angemessene Absicherung geprüft?
- Sind Legacy-Ausnahmen einem Verantwortlichen zugeordnet?
- Gibt es einen Plan zur Ablösung unnötiger Legacy-Authentifizierung?
5. Veraltete Konten, übermäßige Berechtigungen und unzureichend verwaltete lokale Administratoren
Was ist die Fehlkonfiguration?
Nicht nur privilegierte Konten sind relevant. Auch längst nicht mehr benötigte Benutzerkonten, alte Computerkonten, übermäßige Gruppenmitgliedschaften und schlecht verwaltete lokale Administratoren können die Angriffsfläche vergrößern.
Ein häufiges Beispiel sind lokale Administratorkonten auf Windows-Endgeräten. Wenn viele Geräte dasselbe oder dauerhaft unveränderte Passwort verwenden, ist die Trennung zwischen einzelnen Systemen nur eingeschränkt wirksam.
Windows LAPS kann in geeigneten Umgebungen helfen, lokale Administratorpasswörter individuell zu verwalten und regelmäßig zu ändern.
Warum entsteht dieses Problem so häufig?
Inaktive Konten werden häufig aus Vorsicht nicht sofort gelöscht. Bei Mitarbeitern, Dienstleistern und ehemaligen Projekten fehlt manchmal ein klarer Prozess, der den Kontoeigentümer und den Zeitpunkt einer Deaktivierung festlegt.
Bei lokalen Administratorkonten wiederum steht häufig die einfache Administration im Vordergrund. Ein gemeinsames Passwort scheint zunächst praktisch, ist aber sicherheitstechnisch problematisch.
Warum ist das gefährlich?
Ein nicht mehr benötigtes Konto kann weiterhin eine gültige Identität darstellen. Besitzt es zusätzliche Berechtigungen, erhöht sich das Risiko entsprechend.
Bei lokalen Administratorpasswörtern kann die Wiederverwendung auf vielen Geräten dazu führen, dass ein kompromittiertes Kennwort nicht nur für ein einzelnes System relevant ist.
Die tatsächliche Auswirkung hängt von weiteren Faktoren wie Netzwerksegmentierung, Endpoint-Schutz und vorhandenen Zugriffsrechten ab.
Wie erkennt ein Administrator das Problem?
Prüfen Sie:
- inaktive Benutzerkonten
- deaktivierte und veraltete Computerkonten
- Gruppenmitgliedschaften ehemaliger Mitarbeiter
- Konten externer Dienstleister
- lokale Administratorgruppen
- Passwortverwaltung lokaler Administratorkonten
- Zugriff auf gespeicherte LAPS-Kennwörter
Ein Konto sollte nicht allein aufgrund eines beliebigen Alterswerts gelöscht werden. Vor einer Entfernung muss geklärt sein, ob es tatsächlich nicht mehr benötigt wird.
Wie lässt sich das Problem beheben?
Etablieren Sie einen definierten Joiner-Mover-Leaver-Prozess für Benutzer und Berechtigungen. Inaktive Konten sollten zunächst überprüft und anschließend nach einem dokumentierten Verfahren deaktiviert beziehungsweise entfernt werden.
Für lokale Administratorpasswörter sollte eine individuelle, kontrollierte Verwaltung eingeführt werden. Windows LAPS kann hierfür eine geeignete Option sein. Zusätzlich sollte die Zahl der Benutzer mit lokalen Administratorrechten reduziert werden.
Was sollte anschließend überwacht werden?
Überwachen Sie Änderungen an privilegierten lokalen Gruppen, Reaktivierungen deaktivierter Konten, neue administrative Konten und ungewöhnliche Anmeldungen.
Auch der Zugriff auf verwaltete lokale Administratorpasswörter sollte nachvollziehbar sein.
Schnellcheck:
- Werden inaktive Konten regelmäßig überprüft?
- Sind Berechtigungen ehemaliger Mitarbeiter zeitnah entfernt?
- Sind externe Konten dokumentiert?
- Haben Windows-Geräte individuelle lokale Administratorpasswörter?
- Ist der Zugriff auf LAPS-Passwörter angemessen eingeschränkt?
Active-Directory-Fehlkonfigurationen im direkten Vergleich
| Fehlkonfiguration | Hauptrisiko | Erkennung | Empfohlene Maßnahme |
|---|---|---|---|
| Zu viele privilegierte Konten | Größere Angriffsfläche für kompromittierte Identitäten | Gruppenmitgliedschaften, verschachtelte Gruppen und administrative Konten prüfen | Least Privilege, getrennte Administratorkonten und regelmäßige Rezertifizierung |
| Unsichere Service Accounts | Missbrauch dauerhaft aktiver Dienstidentitäten | Rechte, Passwortalter, SPNs und Anmeldeverhalten prüfen | Berechtigungen reduzieren und geeignete gMSA einsetzen |
| Veraltete GPOs und zu weitreichende Richtlinien | Sicherheitsprobleme können auf viele Systeme gleichzeitig wirken | GPO-Verknüpfungen, Vererbung und effektive Einstellungen analysieren | Richtlinien bereinigen, Ausnahmen dokumentieren und Änderungen kontrolliert testen |
| NTLM und unzureichend abgesichertes LDAP | Zusätzliche Risiken durch Legacy-Authentifizierung und unsichere Kommunikation | Authentifizierungs- und LDAP-Nutzung analysieren | Abhängigkeiten beseitigen und sichere Verfahren bevorzugen |
| Veraltete Konten und schlecht verwaltete lokale Administratoren | Unnötige Identitäten und wiederverwendete Zugangsdaten | Inaktive Konten, Gruppenmitgliedschaften und lokale Administratoren prüfen | Kontenlebenszyklus etablieren und lokale Passwörter mit LAPS verwalten |
So prüfen Administratoren Active Directory systematisch
Eine gute Sicherheitsprüfung muss nicht mit einer vollständigen Neuplanung der Domäne beginnen. Sinnvoller ist eine priorisierte Bestandsaufnahme.
1. Privilegierte Identitäten zuerst prüfen
Beginnen Sie mit den Konten und Gruppen, deren Kompromittierung besonders weitreichende Folgen hätte. Dokumentieren Sie direkte und indirekte Mitgliedschaften und klären Sie die geschäftliche Notwendigkeit.
2. Berechtigungen nachvollziehen
Prüfen Sie anschließend verschachtelte Gruppen, delegierte Berechtigungen und Konten mit Sonderrechten. Eine reine Betrachtung der Domain-Admins-Gruppe reicht nicht aus.
3. Service Accounts inventarisieren
Ordnen Sie jedes Dienstkonto einer Anwendung oder einem Dienst zu. Dokumentieren Sie Besitzer, Rechte, SPNs und Passwortverwaltung. Prüfen Sie, ob eine Umstellung auf ein verwaltetes Dienstkonto möglich ist.
4. Group Policies analysieren
Ermitteln Sie, welche GPOs produktiv verwendet werden und welche Einstellungen tatsächlich auf Servern und Clients ankommen. Alte Ausnahmen sollten einen nachvollziehbaren Grund haben.
5. Authentifizierung untersuchen
Analysieren Sie die Nutzung von NTLM und identifizieren Sie Anwendungen, die noch auf ältere Verfahren angewiesen sind. Prüfen Sie gleichzeitig die Absicherung von LDAP-Kommunikation.
6. Kontenlebenszyklus überprüfen
Suchen Sie nach inaktiven Benutzern, alten Computerkonten und ehemaligen Dienstleisterkonten. Entscheidend ist ein dokumentierter Prozess statt eines rein technischen Löschautomatismus.
7. Lokale Administratoren kontrollieren
Prüfen Sie, welche lokalen Administratoren existieren und wie deren Kennwörter verwaltet werden. Bewerten Sie Windows LAPS für geeignete Geräte.
8. Überwachung und Auditing vervollständigen
Eine Konfiguration ist nur dann nachhaltig kontrollierbar, wenn relevante Änderungen erkannt werden. Dazu gehören Änderungen an privilegierten Gruppen, Konten und Richtlinien sowie auffällige Anmeldeereignisse.
5-Minuten-Check: So prüfen Administratoren ihr Active Directory
Die folgenden Fragen liefern keine Sicherheitsbewertung in Form einer Punktzahl. Sie zeigen vielmehr, wo eine vertiefte Prüfung sinnvoll sein kann.
- Ist bekannt, wer aktuell Mitglied privilegierter Active-Directory-Gruppen ist?
- Verwenden Administratoren getrennte Konten für normale und administrative Tätigkeiten?
- Sind alle Service Accounts dokumentiert und auf notwendige Berechtigungen beschränkt?
- Ist bekannt, welche Systeme noch NTLM verwenden?
- Sind LDAP-Verbindungen angemessen abgesichert?
- Werden kritische Group Policies und ihre Ausnahmen regelmäßig überprüft?
- Werden inaktive Benutzer- und Computerkonten nach einem definierten Prozess behandelt?
- Werden lokale Administratorpasswörter individuell und kontrolliert verwaltet?
- Ist Windows LAPS für geeignete Systeme eingeführt oder bewertet?
- Werden Änderungen an privilegierten Gruppen und Konten überwacht?
Ein „Nein“ ist kein Beweis für eine kompromittierte Umgebung. Es ist ein Hinweis darauf, dass der betreffende Bereich genauer untersucht werden sollte.
Besonders wichtig ist die Kombination mehrerer Schwachstellen in der Konfiguration. Ein unnötig privilegiertes Konto ist bereits relevant. Treffen zusätzlich veraltete Passwörter, unzureichendes Monitoring und fehlende Netzwerksegmentierung zusammen, können die möglichen Auswirkungen einer Kontoübernahme deutlich größer sein.
Warum ein sicheres Active Directory allein keine sichere IT-Infrastruktur bedeutet
Active Directory ist eine zentrale Identitäts- und Berechtigungsplattform, aber nur eine Schicht der gesamten Sicherheitsarchitektur.
Endpoint Security schützt beispielsweise Arbeitsstationen und Server vor Schadsoftware und verdächtigen Aktivitäten. Mehrfaktor-Authentifizierung ergänzt den Schutz von Identitäten insbesondere bei externen und privilegierten Zugängen. Netzwerksegmentierung kann verhindern, dass ein kompromittiertes Endgerät ohne weitere Kontrolle auf kritische Systeme zugreift.
Auch Backups bleiben unverzichtbar. Selbst ein sehr gut gehärtetes Active Directory verhindert nicht jeden Sicherheitsvorfall. Wiederherstellbare und regelmäßig getestete Sicherungen sind deshalb ein eigenständiger Bestandteil der Resilienz.
Monitoring und Incident Response schließen eine weitere Lücke. Unternehmen müssen erkennen können, wenn privilegierte Berechtigungen geändert werden, und sollten einen definierten Prozess für kompromittierte Konten und Systeme besitzen.
Schließlich darf Active-Directory-Hardening nicht mit Patchmanagement verwechselt werden. Eine sauber konfigurierte Domäne schützt nicht vor ausnutzbaren Schwachstellen in Betriebssystemen, Anwendungen oder Netzwerkkomponenten.
Das Ziel sollte deshalb nicht sein, Active Directory isoliert „sicher“ zu machen. Sinnvoller ist ein Zusammenspiel aus sauberem Identitätsmanagement, möglichst kleinen Berechtigungsumfängen, sicherer Authentifizierung, geschützten Endpunkten, Überwachung und Wiederherstellungsfähigkeit.
Fazit: Active-Directory-Sicherheit beginnt mit bekannten Berechtigungen
Die meisten problematischen Konfigurationen entstehen nicht plötzlich. Sie sind das Ergebnis von Jahren des Wachstums: neue Anwendungen, Mitarbeiterwechsel, Migrationen, Ausnahmen und technische Übergangslösungen.
Gerade deshalb lohnt sich eine regelmäßige Bestandsaufnahme. Die wichtigsten Fragen sind vergleichsweise einfach: Wer hat privilegierte Rechte? Welche Dienstkonten existieren? Welche Richtlinien werden tatsächlich angewendet? Wo wird noch Legacy-Authentifizierung eingesetzt? Welche Konten und lokalen Administratoren werden nicht mehr benötigt?
Wer diese Fragen nachvollziehbar beantworten kann, schafft eine wesentlich bessere Grundlage für weitere Sicherheitsmaßnahmen.
Active-Directory-Hardening ist dabei kein einmaliges Projekt. Berechtigungen verändern sich, Anwendungen werden ersetzt und neue Systeme kommen hinzu. Eine regelmäßige Überprüfung sorgt dafür, dass Sicherheitsmaßnahmen nicht nur bei der ursprünglichen Einrichtung funktionieren, sondern auch in einer gewachsenen Unternehmensumgebung Bestand haben.
Häufig gestellte Fragen zu Active-Directory-Fehlkonfigurationen
Was ist eine Active-Directory-Fehlkonfiguration?
Eine Active-Directory-Fehlkonfiguration ist eine Einstellung, Berechtigungsvergabe oder Verwaltungsweise, die unnötige Sicherheitsrisiken erzeugt. Beispiele sind dauerhaft überprivilegierte Konten, unzureichend geschützte Service Accounts, veraltete Group Policies oder gemeinsam verwendete lokale Administratorkennwörter. Eine Fehlkonfiguration ist nicht automatisch eine Software-Schwachstelle und muss nicht durch eine CVE beschrieben sein.
Warum sind Domain-Admin-Konten besonders kritisch?
Domain-Admin-Konten besitzen sehr weitreichende Rechte innerhalb einer Active-Directory-Domäne. Deshalb sollte ihre Zahl möglichst begrenzt und ihre Verwendung auf administrative Aufgaben beschränkt werden. Separate Administratorkonten, Least Privilege, geeignete Überwachung und regelmäßige Berechtigungsprüfungen helfen dabei, die Risiken dauerhaft zu kontrollieren.
Wie erkennt man übermäßige Active-Directory-Berechtigungen?
Beginnen Sie mit einer Übersicht der privilegierten Gruppen und berücksichtigen Sie direkte sowie indirekte Mitgliedschaften. Anschließend sollten delegierte Berechtigungen, verschachtelte Gruppen und spezielle Kontorechte geprüft werden. Wichtig ist außerdem die fachliche Frage, ob eine Berechtigung noch benötigt wird. Eine reine Liste technischer Gruppenmitgliedschaften reicht deshalb nicht aus.
Warum sind Service Accounts ein Sicherheitsrisiko?
Service Accounts werden häufig dauerhaft von Anwendungen oder Diensten verwendet. Wenn sie unnötige Berechtigungen besitzen, alte Passwörter verwenden oder interaktive Anmeldungen ermöglichen, kann eine Kompromittierung größere Auswirkungen haben. Eine vollständige Inventarisierung, minimale Berechtigungen und geeignete verwaltete Dienstkonten wie gMSA verbessern die Kontrolle.
Ist Kerberos sicherer als NTLM?
Kerberos ist für viele Active-Directory-Szenarien das bevorzugte Authentifizierungsprotokoll und unterstützt eine integrierte domänenbasierte Authentifizierung. NTLM kann dagegen in bestimmten Konstellationen zusätzliche Sicherheitsrisiken verursachen. Daraus folgt jedoch nicht, dass jede NTLM-Nutzung automatisch unsicher ist. Entscheidend sind die konkrete Verwendung, die vorhandenen Schutzmaßnahmen und die Möglichkeit, Legacy-Abhängigkeiten zu beseitigen.
Warum sollte NTLM in Unternehmen überprüft werden?
NTLM kann in bestimmten Szenarien für Relay-Angriffe und andere Angriffswege relevant sein. Deshalb sollten Unternehmen zunächst feststellen, wo und warum NTLM noch verwendet wird. Anwendungen oder Geräte, die moderne Authentifizierung unterstützen, können anschließend umgestellt werden. Eine vollständige Abschaltung sollte erst nach einer Prüfung der technischen Abhängigkeiten erfolgen.
Was sollte bei LDAP in Active Directory geprüft werden?
Administratoren sollten prüfen, welche Anwendungen und Systeme LDAP verwenden und wie diese Verbindungen abgesichert sind. Besonders relevant sind die sichere Übertragung und geeignete Schutzmechanismen für Authentifizierung und Verzeichniszugriffe. Vor einer Änderung sollten Abhängigkeiten erfasst werden, damit ältere Anwendungen nicht unbeabsichtigt ausfallen.
Was ist Windows LAPS und warum ist es für Active Directory relevant?
Windows LAPS dient der zentralen Verwaltung lokaler Administratorpasswörter auf Windows-Systemen. Dabei können Passwörter individuell verwaltet und regelmäßig geändert werden. Das reduziert insbesondere das Risiko, dass dasselbe lokale Administratorkennwort auf vielen Geräten wiederverwendet wird. Zusätzlich muss der Zugriff auf gespeicherte Kennwörter angemessen eingeschränkt werden.
Wie sollte man inaktive Active-Directory-Konten behandeln?
Inaktive Konten sollten zunächst identifiziert und fachlich bewertet werden. Administratoren sollten klären, ob ein Konto tatsächlich nicht mehr benötigt wird, wer dafür verantwortlich ist und ob es privilegierte Rechte besitzt. Anschließend kann ein definierter Prozess zur Deaktivierung und späteren Entfernung greifen. Automatisches Löschen allein aufgrund eines Alterswerts ist nicht für jede Umgebung geeignet.
Wie häufig sollte Active Directory auf Fehlkonfigurationen geprüft werden?
Ein fester universeller Zeitraum existiert nicht. Änderungen an privilegierten Konten, Gruppen und wichtigen Sicherheitsrichtlinien sollten möglichst zeitnah überwacht werden. Zusätzlich ist eine regelmäßige strukturierte Prüfung sinnvoll, insbesondere nach Migrationen, größeren organisatorischen Veränderungen, neuen Anwendungen oder Änderungen an der Authentifizierungsarchitektur.
Was gehört zu einem guten Active-Directory-Hardening?
Zum Active-Directory-Hardening gehören unter anderem eine möglichst kleine Zahl privilegierter Konten, saubere Gruppenmitgliedschaften, kontrollierte Service Accounts, sichere Authentifizierung, angemessen konfigurierte Group Policies und eine kontrollierte Verwaltung lokaler Administratorpasswörter. Ergänzend sind Monitoring, Patchmanagement, Endpoint Security, MFA und Netzwerksegmentierung wichtig.
Ist eine sichere Active-Directory-Konfiguration allein ausreichend?
Nein. Active Directory ist eine wichtige Komponente der Identitäts- und Berechtigungsverwaltung, aber kein vollständiges Sicherheitskonzept. Endpoint-Schutz, MFA, Netzwerksegmentierung, Patchmanagement, Backups, Monitoring und Incident Response adressieren weitere Risiken. Eine gehärtete Domäne reduziert bestimmte Angriffsflächen, ersetzt aber keine mehrschichtige Sicherheitsarchitektur.
