
AD-Tiering beginnt mit einer Abhängigkeitsfrage: Welche Identität kann welches System kontrollieren, und auf welchen Geräten wird sie verwendet? Drei Gruppen mit den Namen Tier 0, Tier 1 und Tier 2 sind noch keine wirksame Trennung. Entscheidend sind die tatsächlich erlaubten Administrationswege und die Dienste, über die diese Grenzen überschritten werden könnten.
Aha-Moment
Ein getrenntes Administratorkonto hilft wenig, wenn seine Anmeldedaten anschließend auf einem weniger vertrauenswürdigen Server verwendet werden.
Die Ebenen nachvollziehbar festlegen
Microsoft beschreibt für AD DS drei Vertrauensebenen. Tier 0 umfasst insbesondere die Kontrolle über Identitäten, Tier 1 die Server- und Anwendungsebene und Tier 2 die Arbeitsplatzebene. Abhängigkeiten sind dabei mit zu berücksichtigen: Eine Plattform, die höher eingestufte Systeme administrieren kann, darf nicht allein wegen ihrer Produktbezeichnung niedriger bewertet werden. AD-Tiering ist ein Bestandteil des weiter gefassten Enterprise Access Model. Microsoft: Tier-Modell für AD DS.
Für die Einführung empfehlen wir eine Tabelle je Verwaltungsaufgabe:
| Verwaltungsaufgabe | Identität | Ausgangssystem | Ziel | Nachweis |
|---|---|---|---|---|
| Domänenverwaltung | Separates privilegiertes Konto | Vorgesehener Admin-Arbeitsplatz | Freigegebene Identitätssysteme | Erlaubte und untersagte Anmeldewege getestet |
| Anwendungswartung | Aufgabenbezogenes Konto | Freigegebener Wartungsweg | Benannte Server | Rechte und Laufzeit dokumentiert |
| Arbeitsplatzverwaltung | Dafür vorgesehenes Konto | Verwalteter Administrationsweg | Freigegebene Clients | Keine unnötigen Rechte auf höheren Ebenen |
Diese Tabelle ist eine Planungshilfe, keine fertige Berechtigungsrichtlinie für jede Umgebung.
Vor einer Richtlinie die tatsächlichen Wege erfassen
Untersuchen Sie interaktive Anmeldung, Remotedesktop, Verwaltungsschnittstellen, geplante Aufgaben und Dienstidentitäten getrennt. Erfassen Sie außerdem Gruppenverschachtelungen. Ein Konto kann über eine unscheinbare Untergruppe Rechte erhalten, die im direkten Mitgliedschaftsbild nicht auffallen.
Zu jedem Weg gehört eine betriebliche Begründung. „Wird vielleicht irgendwann gebraucht“ ist kein belastbarer Freigabegrund. Gibt es einen wiederkehrenden Wartungsfall, erhält er einen definierten Ablauf. Gibt es eine Altanwendung mit einer zwingenden Einschränkung, braucht sie eine dokumentierte Ausnahme mit Verantwortlichem und Überprüfungstermin.
Anmeldebeschränkungen gezielt entwerfen
Eine geplante Matrix unterscheidet erlaubte Identitäten, Ausgangsgeräte, Zielsysteme und Anmeldearten. Erst danach werden passende technische Regeln ausgewählt. Authentifizierungsrichtlinien und Silos können unter ihren jeweiligen Voraussetzungen Anmeldungen eingrenzen; sie sind nicht mit einer beliebig benannten AD-Gruppe gleichzusetzen. Microsoft: Authentifizierungsrichtlinien und Silos.
Es ist gefährlich, nur den erfolgreichen Administratorzugang zu testen. Prüfen Sie auch den Weg, der nach dem Konzept ausdrücklich nicht mehr möglich sein soll. Eine Negativprüfung bedeutet hier einen abgestimmten Anmeldeversuch mit Testkonten, nicht den Versuch, die Umgebung anzugreifen.
Dienstkonten sind Teil des Modells
Listen Sie für jeden Dienst das verwendete Konto und die beteiligten Hosts auf. Ein gemeinsames Konto auf unterschiedlich vertrauenswürdigen Systemen schafft eine Verbindung, die in einer reinen Benutzerübersicht leicht fehlt. Persönliche Tiering-Administratorkonten sollten nicht beiläufig zur Daueridentität einer Anwendung werden.
Bei einer Änderung muss deshalb nicht nur die Mitgliedschaft betrachtet werden. Relevant sind auch der Start des Dienstes, der Zugriff auf nachgelagerte Ressourcen und die Wiederanmeldung nach einem Neustart. Ein weiterhin laufender Prozess beweist nicht, dass die neue Konfiguration einen erneuten Start übersteht.
Einführung und Abnahme
Beginnen Sie mit einer kleinen, repräsentativen Systemgruppe. Halten Sie den Ausgangszustand fest und vereinbaren Sie, wer eine fehlerhafte Änderung zurücknimmt. Testen Sie den normalen Administrationsweg, einen untersagten Weg, den Dienstneustart und die Übergabe an eine zweite berechtigte Person.
Zur Abnahme gehören Datum, betroffene Systeme, Richtlinienstand, Testidentität und Ergebnis. „Tiering eingerichtet“ ist dafür zu ungenau. Ein brauchbarer Nachweis benennt, welche Grenze geprüft wurde und welche Bereiche noch offen sind.
Ergänzend behandelt unser technischer IT-Audit die Gesamtprüfung. Windows LAPS ist ein ergänzender Baustein für lokale Administratorkennwörter, ersetzt aber kein Tiering-Konzept.
Technische Prüfung mit Hamburger IT-Service abstimmen. Fachlicher Stand: 25. September 2026.
