Tier-0 in fünf Fragen: Wo Ihr Active Directory wirklich verwundbar ist

Tier-0 wird in Gesprächen fast automatisch mit Domain Admins gleichgesetzt, und das greift deutlich zu kurz. Zu Tier-0 gehört letztlich alles, was die Identitätsinfrastruktur direkt oder indirekt kontrollieren kann – Microsoft zählt dazu neben den Domain Controllern selbst auch AD CS, Entra Connect sowie Backup-, Monitoring-, Patch- und Hypervisor-Systeme oder Sicherheitssoftware, sofern sie Kontrolle über Tier-0-Systeme besitzt. Die Frage, die am Anfang jeder ernsthaften Betrachtung stehen sollte, lautet deshalb nicht, wer Domain Admin ist, sondern wer oder was Domain Admin werden, dessen Zugangsdaten erhalten oder die Systeme manipulieren kann, auf denen diese Identität verwendet wird. Fünf Fragen reichen aus meiner Erfahrung, um eine Umgebung erstaunlich zuverlässig einzuordnen.

Frage 1: Wer kann Tier-0 wirklich kontrollieren?

Der Einstieg sollte nicht bei den Domain Admins liegen, sondern beim Kontrollpfad. Dazu gehören Enterprise Admins, Domain Admins, Administratoren, Backup Operators, delegierte AD-Berechtigungen, die GPO-Verwaltung, PKI-Administratoren, die Hypervisor-Administratoren der Domain Controller, Backupadministratoren, Softwareverteilung, EDR- und Monitoring-Systeme, Automatisierungskonten, die Identitätssynchronisation und Dienstkonten – eine Liste, die auf den ersten Blick lang wirkt, aber genau deshalb so wichtig ist. Microsoft weist ausdrücklich darauf hin, dass ein System zu Tier-0 wird, sobald es Tier-0-Systeme betreiben oder kontrollieren kann, und ein Jump Host, auf dem Tier-0-Anmeldedaten verwendet werden, übernimmt dieses Vertrauensniveau ganz automatisch mit.

Daraus folgt eine Einsicht, die ich in Projekten immer wieder erklären muss: Tier-0 ist keine Serverliste, sondern eine Vertrauensgrenze. Wer das als Liste denkt, wird die Hälfte der eigentlichen Kontrollpfade übersehen.

Frage 2: Wo melden sich privilegierte Konten an?

Ein sauber getrenntes Administratorkonto bringt herzlich wenig, wenn es an einem ganz normalen Arbeitsplatzrechner benutzt wird – denn der Rechner, auf dem sich ein privilegiertes Konto anmeldet, wird damit selbst zum potenziellen Angriffspunkt für diese Identität. Deshalb muss nachvollziehbar sein, wo Tier-0-Konten überhaupt interaktiv verwendet werden dürfen: Gibt es dedizierte PAWs, können diese Konten sich auch auf normalen Clients anmelden, werden Tier-0- und Tier-1-Konten sauber getrennt, sind die RDP-Sprungserver korrekt klassifiziert, gibt es gemeinsam genutzte Administrationsserver, und werden unterschiedliche Vertrauensstufen versehentlich mit demselben Konto administriert?

Das AD-Tiermodell von Microsoft trennt administrative Identitäten, Arbeitsstationen und Ressourcen genau aus diesem Grund in unterschiedliche Vertrauensstufen. Ein Muster, das mir dabei besonders häufig unterkommt und das ich für eines der problematischsten halte, sind gemeinsam verwendete Dienstkonten über mehrere Tiers hinweg – wenn dasselbe Konto auf Tier-0 und gleichzeitig auf einem weniger vertrauenswürdigen System eingesetzt wird, entsteht damit eine direkte Brücke zwischen zwei Sicherheitszonen, die eigentlich getrennt sein sollten.

Frage 3: Können andere Managementsysteme Tier-0 beeinflussen?

Das ist in den meisten Umgebungen die unangenehmste Frage, weil ein Domain Controller perfekt gehärtet sein kann und trotzdem von einem deutlich weniger geschützten System aus kontrollierbar bleibt. Die Virtualisierungsplattform, Backup, Patchmanagement, Softwareverteilung, Monitoring, EDR, zentrale Automatisierung, ein Passwort- oder PAM-System und Configuration Management sind die typischen Kandidaten. Wer den Hypervisor eines virtuellen Domain Controllers administriert, besitzt damit auch eine erhebliche Kontrolle über genau diesen Domain Controller – und wer Software mit SYSTEM-Rechten auf Domain Controllern verteilen kann, ebenso.

Microsoft zählt solche Kontrollsysteme deshalb ausdrücklich zur Identitätskontrollebene, sofern sie Tier-0 unmittelbar steuern können. Diese Abhängigkeiten werden in Tier-0-Projekten erfahrungsgemäß erst dann sichtbar, wenn man aufhört, in Organigrammen zu denken, und anfängt, in Kontrollpfaden zu denken.

Frage 4: Welche alten Protokolle und Ausnahmen existieren noch?

Ein Tier-Modell allein härtet noch kein Active Directory, danach beginnt erst die eigentliche technische Arbeit. Zu untersuchen sind unter anderem die NTLM-Nutzung, LDAP Signing und LDAP Channel Binding, die SMB-Sicherheit, die Kerberos-Konfiguration, alte Verschlüsselungsverfahren, unkontrollierte Delegationen, lokale Administratorrechte, veraltete Dienstkonten und ungeschützte administrative Schnittstellen. Gerade bei privilegierten Konten, Gruppen und Rollen erleichtert ein konsistentes Namenskonzept zusätzlich Betrieb, Review und Automatisierung.

Nicht alles davon lässt sich sofort abschalten, und gerade ältere Fachverfahren erzeugen dabei Abhängigkeiten, die man nicht unterschätzen sollte. Eine Härtung, die aus einer Liste von Registry-Werten besteht, die man an einem Nachmittag durchklickt, hat in meiner Erfahrung selten Bestand – der bessere Weg führt über eine saubere Ist-Aufnahme, Protokollierung, eine Auswirkungsanalyse, eine Pilotierung, die kontrollierte Umsetzung und anschließende Überwachung. Ein Sicherheitswert, der nach drei Tagen wegen Produktionsproblemen wieder zurückgenommen werden muss, hat am Ende nichts gewonnen.

Frage 5: Können Sie Ihr Active Directory wiederherstellen?

Die letzte Frage hat mit Prävention auf den ersten Blick wenig zu tun und gehört trotzdem untrennbar zu Tier-0. Wenn die Identitätskontrollebene kompromittiert oder zerstört wurde, entscheidet allein die Wiederherstellbarkeit darüber, ob eine Organisation überhaupt wieder handlungsfähig wird. Microsoft empfiehlt ausdrücklich, einen individuellen Forest-Recovery-Plan zu erstellen und den Wiederanlauf regelmäßig praktisch zu testen – nicht nur zu dokumentieren.

Deshalb sollte jede Umgebung beantworten können, welcher Domain Controller zuerst wiederhergestellt wird, welches Backup als vertrauenswürdig gilt und wie alt es sein darf, wie der Forest isoliert wiederhergestellt wird, wo die DSRM-Zugangsdaten liegen, wie DNS bereitgestellt wird, wie SYSVOL wiederhergestellt wird, was mit den Vertrauensstellungen geschieht, wie mit den krbtgt-Kennwörtern umgegangen wird, und in welcher Reihenfolge die übrigen Systeme danach wieder angebunden werden. Wenn diese Antworten erst während eines laufenden Angriffs gesucht werden müssen, existiert faktisch kein Disaster-Recovery-Konzept, egal was auf dem Papier steht.

Fünf Fragen, ein Ergebnis

Für eine erste Einschätzung braucht eine Organisation keine dreihundert Kontrollen, sondern genau diese fünf Fragen: Wer kann Tier-0 kontrollieren? Wo werden Tier-0-Identitäten verwendet? Welche anderen Systeme können Tier-0 beeinflussen? Welche technischen Altlasten unterlaufen die Trennung? Und können wir die Identitätskontrollebene nach einem Totalausfall wieder aufbauen?

Wer diese Fragen belastbar beantworten kann, hat einen guten Ausgangspunkt. Wer sie nicht beantworten kann, weiß immerhin, wo die nächste Analyse anfangen sollte – und das ist in meiner Erfahrung schon mehr, als die meisten Umgebungen am Anfang eines Projekts wissen. Tier-0 ist keine Gruppe im Active Directory, sondern die Menge aller Wege, über die sich Ihre Identitätsinfrastruktur kontrollieren lässt.

Microsoft selbst verwendet heute mit dem Enterprise Access Model einen weiter gefassten Rahmen, in dem Tier-0 in einer umfassenderen Control Plane aufgeht. Für reine oder stark on-premises geprägte AD-Umgebungen bleibt das klassische Tiermodell trotzdem ein sehr brauchbares Sicherheitsmodell – und in genau solchen Umgebungen arbeite ich am häufigsten.