Privilegierter Zugriff: Tiering und Credential-Hygiene

Warum privilegierter Zugriff das eigentliche Kronjuwel ist

Ein Angreifer will selten „einen Server“ — er will Kontrolle über die Identität. Wer Domain Admins oder einen Domain-Controller kontrolliert, kontrolliert jedes Konto, jede Gruppe, jede Anmeldung im Forest. Deshalb dreht sich moderne AD-Sicherheit nicht um „starke Passwörter“, sondern um eine Frage: Wo dürfen privilegierte Credentials überhaupt auftauchen — und wo nie?

Der klassische Angriffsweg heißt Lateral Movement: Der Angreifer landet auf einer beliebigen Workstation, stiehlt dort ein Credential und hangelt sich Host für Host nach oben, bis er ein Tier-0-Credential erwischt. Das Tier-Modell ist genau die Gegenstrategie: Es macht diesen Weg strukturell unmöglich, statt auf Glück zu hoffen.

Das Tier-Modell (Tier 0 / 1 / 2)

Microsoft strukturiert privilegierten Zugriff in Tiers (im heutigen „Enterprise Access Model“ als Kontrollebenen fortgeführt). Ein Tier ist eine Vertrauensgrenze: Konten und Systeme eines Tiers dürfen nur innerhalb ihres Tiers oder auf tiefere Tiers wirken — nie kontrolliert ein tieferes Tier ein höheres.

Tier 0

Kontrolle über die Identität: Domain-Controller, Domain Admins, die AD-Datenbank, PKI/AD CS, Entra-Connect-/Azure-AD-Connect-Server.

Tier 1

Server und Anwendungen: Member-Server, Fileserver, Datenbanken und die Konten, die sie administrieren.

Tier 2

Workstations und User: Client-Rechner, Endnutzer und Helpdesk-Konten, die Endgeräte betreuen.

Die Faustregel für die Einordnung: Alles, was die Identität kontrollieren oder kompromittieren kann, ist Tier 0. Ein Enterprise-CA-Server gehört dazu, weil er Zertifikate ausstellt, mit denen man sich als beliebiges Konto authentifizieren kann. Ein Entra-Connect-Server gehört dazu, weil er synchronisationsprivilegierte Credentials hält.

Kein Credential-Downgrade

Die zentrale Regel des Modells: Ein Tier-0-Credential darf nie auf einem Tier-1- oder Tier-2-Host exponiert werden. Der Grund ist technisch, nicht organisatorisch: Meldest du dich interaktiv (oder per RDP, RunAs, geplantem Task, Dienst) an einem Host an, landen verwertbare Authentifizierungs-Geheimnisse im Speicher des LSASS-Prozesses dieses Hosts.

Ist dieser Host kompromittiert — was bei einer Workstation die realistische Annahme ist — liest der Angreifer diese Geheimnisse aus und nutzt sie mit Pass-the-Hash oder Ticket-Diebstahl weiter. Ein einziger Domain-Admin-Login auf einer infizierten Workstation reicht, um den gesamten Forest zu verlieren.

Clean Source und Privileged Access Workstations (PAW)

Aus „kein Downgrade“ folgt das Clean-Source-Prinzip: Ein Objekt darf nur von einer Quelle verwaltet werden, die gleich oder höher vertrauenswürdig ist als das Objekt selbst. Verwaltest du ein Tier-0-System von einem weniger vertrauenswürdigen Host aus, wird die Sicherheit des Ziels von der Sicherheit der Quelle abhängig — du hast Tier 0 auf das Niveau der Quelle abgesenkt.

Die praktische Umsetzung ist eine Privileged Access Workstation (PAW): ein gehärteter, dedizierter Rechner, der ausschließlich der Administration eines Tiers dient — kein E-Mail, kein Web-Browsing, keine beliebige Software. Genau diese Alltagsaktivitäten sind die üblichen Einfallstore, und eine PAW entfernt sie aus der Verwaltungskette.

Praktisch scheitert Clean Source selten an der Einsicht und fast immer an einer Kleinigkeit: Der administrative Arbeitsplatz hat keinen Zugriff auf das Ticketsystem, die Dokumentation oder das Kennwortdepot — also wechselt man doch wieder zum Alltagsrechner. Die Frage beim Entwurf lautet deshalb nicht nur „was darf die Arbeitsstation nicht“, sondern ebenso: Was braucht sie, damit dort tatsächlich gearbeitet werden kann? Eine PAW ohne Zugriff auf die Werkzeuge des Alltags wird umgangen, und zwar von genau den Leuten, die sie schützen soll.

Credential-Theft-Abwehr: Protected Users

Tiering begrenzt, wo Credentials auftauchen. Ergänzend härtet die Gruppe Protected Users die privilegierten Konten selbst: Mitglieder können sich nicht per NTLM authentifizieren, nutzen in Kerberos kein DES/RC4 und — entscheidend — es werden keine langlebigen Geheimnisse (Klartext, NTLM-Hash, langfristige Kerberos-Schlüssel) auf den Hosts zwischengespeichert.

Das reduziert die Beute, die ein Pass-the-Hash-Angriff aus LSASS ziehen kann. Protected Users ist aber kein Ersatz für Tiering: Es macht ein exponiertes Credential schwerer verwertbar, verhindert die Exposition selbst nicht. Beide Maßnahmen wirken zusammen — die eine begrenzt die Verwertbarkeit, die andere die Angriffsfläche.

LAPS: eindeutige lokale Admin-Passwörter

Ein zweiter Lateral-Movement-Pfad läuft über lokale Admin-Konten. Ist das lokale Administrator-Passwort auf allen Rechnern gleich, genügt ein einziger geknackter Hash, um sich per Pass-the-Hash auf jeden Rechner mit demselben Passwort zu bewegen — ein klassischer Domino-Effekt.

LAPS (Local Administrator Password Solution) löst das: Es vergibt je Rechner ein eindeutiges, zufälliges lokales Admin-Passwort, rotiert es automatisch und speichert es geschützt in AD/Entra, sodass nur berechtigte Konten es auslesen können. Ein kompromittiertes lokales Passwort öffnet dann genau einen Rechner.

Gruppen-Verschachtelung als Eskalationspfad

Tier-Grenzen leben nicht nur zwischen Hosts, sondern auch innerhalb der Gruppenstruktur. AD wertet Gruppenmitgliedschaft transitiv aus: Ist eine niedrig-privilegierte Gruppe Mitglied einer Tier-0-Gruppe, erhält jedes Mitglied der niedrigen Gruppe — auch verschachtelt über mehrere Ebenen — die vollen Tier-0-Rechte.

Das ist tückisch, weil ein Blick auf die direkten Mitglieder der Tier-0-Gruppe sauber aussehen kann, während die eigentliche Eskalation zwei Ebenen tiefer verschachtelt liegt. Deshalb zählt beim Audit die effektive (transitive) Mitgliedschaft, nicht die direkte — und Verschachtelung darf Tier-Grenzen nie überschreiten.

Was alles Tier 0 ist — die unbequeme Liste

Die Faustregel „alles, was die Identität kontrollieren kann, ist Tier 0“ klingt handlich und wird beim ersten Anwenden unbequem. Denn sie zieht Systeme herein, die im Organigramm woanders stehen und deren Betreiber sich als Tier 1 verstehen.

Domain Controller

Offensichtlich — und der einzige Fall, den alle sofort nennen.

Der Virtualisierungs-Host

Wer die virtuelle Maschine eines DCs kontrolliert, kontrolliert den DC: Arbeitsspeicher auslesen, Datenträger einhängen, Prüfpunkte setzen. Der Host ist Tier 0, auch wenn er in der Server-Abteilung steht.

Der Sicherungsserver

Er liest den Systemstatus jedes DCs und kann ihn zurückspielen. Damit kommt er an dieselben Geheimnisse — ohne je einen DC zu betreten.

Die Enterprise-CA

Sie kann Zertifikate ausstellen, mit denen sich jemand als beliebiges Konto authentifiziert. Das ist Identitätskontrolle über einen Umweg.

Verwaltungs- und Überwachungsagenten auf DCs

Ein Agent mit lokalen Administratorrechten auf einem Domain Controller ist ein Tier-0-Zugang — und seine Verwaltungskonsole ebenfalls.

Wer GPOs für DCs bearbeiten darf

Eine Richtlinie, die auf Domain Controller wirkt, führt dort Code aus. Das Recht dazu ist Tier 0, unabhängig davon, wer es bekommen hat.

AdminSDHolder: warum Rechte an privilegierten Konten verschwinden

Ein Administrator delegiert einem privilegierten Konto ein Sonderrecht. Es funktioniert. Eine Stunde später ist es weg, ohne dass jemand etwas geändert hätte. Das ist kein Fehler, sondern ein Schutzmechanismus — und wer ihn nicht kennt, delegiert dasselbe Recht immer wieder neu.

AdminSDHolder — Ein Objekt unter CN=AdminSDHolder,CN=System,… in jeder Domäne, dessen Berechtigungen als Vorlage für alle geschützten Konten und Gruppen dienen — also für die privilegierten Gruppen und ihre Mitglieder.

Die richtige Schlussfolgerung ist nicht, den Mechanismus zu umgehen — etwa indem man das Intervall verstellt oder die Vorlage aufweicht. Sie lautet: Wenn ein privilegiertes Konto ein Sonderrecht braucht, ist entweder das Recht falsch gewählt oder das Konto zu privilegiert für die Aufgabe. Eine Änderung an AdminSDHolder wirkt auf alle geschützten Objekte der Domäne gleichzeitig und ist deshalb die weitreichendste Berechtigungsänderung, die man in einer Domäne vornehmen kann.

Warum das Modell in der Praxis scheitert

Das Tier-Modell ist unstrittig richtig und wird trotzdem selten sauber betrieben. Die Gründe sind fast nie fachlich — sie sind operativ, und wer sie nicht vorher benennt, baut ein Modell, das nach sechs Monaten auf dem Papier steht und in der Praxis umgangen wird.

• Der Zweitrechner nervt. Wer für jede administrative Handlung an ein anderes Gerät wechseln muss, sucht Abkürzungen — und findet sie.
• Der Notfall bricht die Regel. Um drei Uhr nachts zählt Wiederherstellung mehr als Tiering. Ohne vorbereiteten, protokollierten Notfallweg entsteht ein improvisierter.
• Werkzeuge sind nicht tierfähig. Eine Verwaltungskonsole, die Tier 0 und Tier 1 gemeinsam bedient, hebt die Trennung faktisch auf.
• Dienstleister und Agenten bekommen Rechte, die niemand einem Menschen geben würde — weil sie als Software nicht als Zugang wahrgenommen werden.

Durchgerechnet: der Weg von der Workstation zum Domain Admin

Gleich entscheidest du diese Achsen selbst

In den folgenden Checks ordnest du Systeme und Konten den richtigen Tiers zu, entscheidest über zulässige Anmeldungen und Verwaltungswege (Clean Source), wählst die passende Credential-Theft-Abwehr (Protected Users, LAPS) und erkennst eine Eskalation durch Gruppen-Verschachtelung. Achte jeweils darauf, wo ein Credential exponiert würde — das ist fast immer der entscheidende Hebel.