Active Directory Tiered Admin Model: So halten Ihre Tiers wirklich stand (von ESAE zu RAMP)

Was ist das Active Directory Tiered Admin Model

Das Active Directory Tiered Admin Model ist die Sicherheitsarchitektur, die verhindert, dass ein Angreifer, der einen Helpdesk-Laptop kompromittiert hat, direkt zum Domain Admin durchmarschiert. Es teilt jede Identität, jede Workstation und jeden Server in Vertrauensstufen (Tiers) ein — Tier 0 (die Identitäts-Kontrollebene selbst), Tier 1 (Server und Business-Anwendungen) und Tier 2 (Endnutzer-Workstations und Standardkonten) — und erzwingt in beide Richtungen dieselbe Regel: Anmeldeinformationen einer höheren Tier dürfen niemals einer niedrigeren Tier ausgesetzt werden, und Anmeldeinformationen einer niedrigeren Tier dürfen niemals eine höhere Tier kontrollieren können (Microsoft Learn, AD DS Tier Model).

Die meisten Umgebungen, die behaupten, ein gestuftes Modell zu betreiben, setzen es in der Praxis nicht wirklich durch. Domain Admins verbinden sich per RDP mit Member-Servern, um „nur kurz etwas zu prüfen". Eine Tier-1-GPO des Service Desks wird eine OU zu hoch verknüpft und landet auf der OU der Domain Controller. Ein Break-Glass-Konto steht außerhalb der Protected Users, weil niemand daran gedacht hat, es hinzuzufügen. Jeder dieser Fälle ist für sich genommen klein; zusammen lassen sie die Tier-Grenze zusammenbrechen, die das Modell eigentlich schützen soll — und genau das ist die Art von Privileged-Access-Drift, die sich nach einer Härtungsmaßnahme wieder einschleicht, wenn niemand kontinuierlich nachprüft.

Die Grenze falsch zu ziehen ist teuer, weil eine Tier-0-Kompromittierung kein lokal begrenzter Vorfall ist — sie ist total. Ein Angreifer, der ein Tier-0-Credential erbeutet (über eine Cross-Tier-Anmeldung, eine falsch verknüpfte GPO oder ein Konto, das nicht in Protected Users aufgenommen wurde), kann in der Regel per DCSync das gesamte Verzeichnis auslesen und Kerberos-Tickets für jede Identität in der Domäne fälschen. Das gestufte Modell existiert genau deshalb, um dieses Ergebnis auf eine Tier-0-Kompromittierung zu begrenzen, statt zuzulassen, dass eine einzelne kompromittierte Helpdesk-Workstation in eine solche eskaliert.

Von OUs zur Durchsetzung: Wie Tiering wirklich funktioniert

Tiering ist kein Diagramm — es ist eine OU-Struktur, ein Satz gezielt verknüpfter GPOs und eine harte Grenze dafür, wo sich privilegierte Konten interaktiv anmelden dürfen.

OU-Struktur

Tier-0-Assets (Domain Controller, AD FS, PKI/ADCS-Server, Backup-Infrastruktur, die einen DC wiederherstellen kann, sowie die Konten/Gruppen, die eines davon administrieren) liegen in einem dedizierten Tier-0-OU-Baum, getrennt von Tier-1-Servern und Tier-2-Workstations. Delegation und GPO-Verknüpfungen folgen derselben Grenze — eine GPO zur Härtung von Tier-2-Workstations sollte niemals in der Nähe der Tier-0-OU verknüpft werden, und umgekehrt (Microsoft Community Hub, Initially Isolate Tier 0 Assets with Group Policy).

Privileged Access Workstations (PAWs)

Tier-0-Admin-Konten sollten sich interaktiv nur an einer kleinen, dedizierten Menge von Tier-0-Geräten anmelden können — PAWs, die einer eigenen OU angehören, mit Härtungs-GPOs (kein Internet-Browsing, keine E-Mail, Application-Allowlisting), die ausschließlich auf diese OU beschränkt sind (Microsoft Learn, PAW Legacy Guidance). Das ist die praktische Durchsetzung von Regel Nr. 1: Wenn sich ein Tier-0-Credential an einem Tier-1- oder Tier-2-Gerät authentifizieren kann, ist die Grenze bereits gebrochen — unabhängig davon, was das Organigramm oder das Wiki-Diagramm behauptet.

GPO-Scoping-Disziplin

Sicherheits-Härtungs-GPOs nur auf der jeweils passenden Tier-OU verknüpfen — niemals auf Domain-Root-Ebene, niemals auf der Default Domain Policy. Eine GPO über Tier-OUs hinweg zu verknüpfen ist einer der häufigsten Wege, auf denen Tier-Grenzen über Monate hinweg lautlos erodieren, weil niemand eine hinzugefügte Verknüpfung so bemerkt wie ein neues Admin-Konto.

Erkennung: Tier-Verstöße aufspüren, bevor sie ausgenutzt werden

Ein Tier-Verstoß ist kein einzelnes Ereignis — er ist ein Muster, bei dem eine privilegierte Identität oder eine GPO-Verknüpfung dort auftaucht, wo sie nicht hingehört. Bauen Sie Erkennungen um folgende Signale herum auf:

Warum Event-ID 4672 das hochwertige Signal ist

Event-ID 4672 („Sonderrechte einer neuen Anmeldung zugewiesen") wird unmittelbar nach einem erfolgreichen 4624 für jedes Konto mit adminäquivalenten Rechten ausgelöst, und seine Logon-ID ist der Verknüpfungsschlüssel über den gesamten Session-Lebenszyklus hinweg — 4624 → 4672 → Aktivität → 4634/4647 (Microsoft Learn, Event 4672). Auf einer Workstation, an der sich ein Domain Admin niemals interaktiv anmelden sollte, ist ein einzelnes 4672 für dieses Konto ein hochwertiger Alarm mit geringem Aufwand — dafür braucht es keine UEBA-Tools, sondern nur die richtige Korrelationsregel im richtigen OU-Scope.

Remediation: Tiers aufbauen, die wirklich halten

1. Privilegierte Konten in eine dedizierte Tier-0-Admin-OU verschieben. Das ist der einzelne Check, den ANSSI direkt benennt — Konten mit adminCount=1, die außerhalb einer dedizierten, eng delegierten OU liegen, brechen die Segmentierung, auf der der Rest des Modells beruht (ANSSI-PA-099, „Recommandations relatives à l'administration sécurisée des systèmes d'information reposant sur Microsoft Active Directory", Okt. 2023).

2. Alle Tier-0-Konten zu Protected Users hinzufügen. Das blockiert NTLM-Authentifizierung, DES/RC4-Kerberos-Verschlüsselung, unconstrained/constrained Delegation und langlebige TGTs für diese Konten — und schließt damit mehrere der Credential-Theft-Pfade, die Delegation-Lücken sonst öffnen.

3. Eine Fine-Grained Password Policy für Tier-0-Gruppen erzwingen. Domain und Enterprise Admins sollten nicht die Standard-Domänen-Passwortrichtlinie erben; eine dedizierte PSO mit stärkeren Längen- und Rotationsanforderungen begrenzt den Blast Radius, falls ein Tier-0-Credential trotzdem exponiert wird.

4. Jede GPO strikt auf ihre Tier-OU scopen. Prüfen Sie bestehende GPO-Verknüpfungen auf alles, was sowohl eine Tier-0-OU als auch eine Tier-1/2-OU berührt, und trennen Sie diese. Fügen Sie niemals Tiering-Durchsetzungseinstellungen zur Default Domain Policy hinzu — erstellen Sie dedizierte GPOs und verknüpfen Sie sie nur mit der jeweils relevanten Tier-OU.

5. PAWs für die Tier-0-Interaktivanmeldung aufsetzen und dann technisch erzwingen. Nutzen Sie Anmelderechte-GPOs (Deny log on locally / Deny log on through Remote Desktop Services) auf Tier-1/2-Assets für Tier-0-Konten — nicht nur als Richtliniendokumentation, denn eine schriftliche Regel, die niemand technisch verletzen kann, übersteht keinen Vorfall.

6. Vierteljährlich neu baselinen, nicht nur einmal. Tier-Grenzen driften durch die routinemäßige Admin-Arbeit — ein neuer Server-Admin, der in die falsche Gruppe aufgenommen wird, eine während einer Migration neu verknüpfte GPO oder veraltete privilegierte Konten, die niemand aus Tier 0 entfernt hat. Ein einmaliges Tiering-Projekt ohne wiederkehrendes Audit verfällt innerhalb eines Jahres wieder zur flachen Administration; siehe den umfassenderen Leitfaden zu Härtungsprioritäten, wie das in eine breitere AD-Härtungssequenz passt, und die ANSSI-Empfehlungen in der Praxis für die vollständige, compliance-getriebene Checkliste, zu der dieses Modell gehört.

Wie EtcSec das erkennt

Das Active-Directory-Audit von EtcSec prüft direkt gegen Ihr Live-Verzeichnis auf Verstöße gegen das Tier-Modell: ANSSI_R15_TIER_MODEL_VIOLATION markiert privilegierte Konten außerhalb einer dedizierten Admin-OU, ANSSI_R40_NO_PSO_TIER0 markiert Tier-0-Gruppen ohne Fine-Grained Password Policy, ANSSI_R86_ADMIN_FOREST_SEGREGATION prüft die Trust-Segregation des Administrations-Forest, sofern einer im Einsatz ist, NOT_IN_PROTECTED_USERS markiert privilegierte Konten, die in der Protected-Users-Gruppe fehlen, und EXCESSIVE_PRIVILEGED_ACCOUNTS markiert Tier-Grenzen, die zu groß geworden sind, um sie manuell zu auditieren.