Privilegierter Zugriff: Tiering und Credential-Hygiene
Einführung · 8 Abschnitte · ~6 Min Lesezeit · Stand
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.
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.
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.