Active Directory absichern: Tier-Modell, privilegierte Konten und saubere Delegierung

Vom Tier-Modell zum Enterprise Access Model

Das Tier-Modell ist die ältere und im Windows-Umfeld bekanntere Fassung. Es ordnet Systeme und Konten drei Ebenen zu: Tier 0 für die Kontrolle über Identitäten, Tier 1 für Server und Anwendungen, Tier 2 für Arbeitsplätze. Die Regel dahinter ist eine einzige: Ein Konto einer höheren Ebene darf sich niemals an einem System einer niedrigeren anmelden, weil dort seine Zugangsdaten liegen bleiben und von jemandem eingesammelt werden können, der dieses System kontrolliert.

Microsoft hat dieses Modell inzwischen in ein umfassenderes überführt, das Enterprise Access Model. Es baut ausdrücklich auf dem Tier-Modell auf, das sich auf die Eindämmung unerlaubter Rechteausweitung in einer lokalen Windows-Umgebung konzentrierte, und ergänzt es um die Zugriffsanforderungen eines Unternehmens, das mit lokalen Systemen, mehreren Clouds sowie internen und externen Personen gleichzeitig arbeitet. Tier 0 wird dabei zur Steuerungsebene erweitert und deckt alle Aspekte der Zugriffskontrolle ab. Was Tier 1 war, teilt sich in eine Verwaltungsebene für unternehmensweite IT-Aufgaben und eine Ebene für einzelne Anwendungen und ihre Daten. Was Tier 2 war, teilt sich in Benutzerzugriff und Anwendungszugriff auf, um auch Schnittstellen und externe Zugriffe abzudecken.

Für die tägliche Arbeit an einem lokalen Active Directory ändert das weniger, als die neuen Begriffe vermuten lassen. Die Kernregel bleibt dieselbe, und der erste Schritt bleibt derselbe: Schreib auf, was zu Tier 0 gehört. Der Nutzen des neueren Modells liegt darin, dass es die Frage nach der Cloudseite und nach externen Zugriffen von Anfang an mitstellt, statt sie als Sonderfall nachzureichen. Wer heute anfängt, sollte in dieser Sprache planen, auch wenn die Umsetzung im Verzeichnis mit denselben Gruppenrichtlinien beginnt wie vor zehn Jahren.

Was die Gruppe Protected Users tatsächlich abschaltet

Protected Users ist eine globale Sicherheitsgruppe im Verzeichnis, die für ihre Mitglieder eine Reihe fest eingebauter Schutzmaßnahmen auslöst. Der entscheidende Punkt ist, dass diese Maßnahmen nicht konfigurierbar sind: Sie lassen sich nicht übersteuern, solange das Konto Mitglied ist. Auf dem Gerät, an dem sich ein Mitglied anmeldet, werden Zugangsdaten für die Weitergabe über CredSSP nicht im Klartext zwischengespeichert, auch dann nicht, wenn die entsprechende Richtlinie das erlauben würde. Windows Digest speichert ebenfalls keine Klartextdaten mehr, NTLM speichert weder Klartext noch den abgeleiteten Wert, und Kerberos erzeugt keine Schlüssel mit DES oder RC4 und speichert nach dem Erhalt des ersten Tickets keine langfristigen Schlüssel. Zusätzlich wird kein zwischengespeicherter Prüfwert für die Anmeldung angelegt, weshalb die Anmeldung ohne Verbindung zum Verzeichnis nicht mehr funktioniert.

Auf der Seite der Domänencontroller kommen weitere Einschränkungen hinzu, sobald die Domänenfunktionsebene mindestens Windows Server 2012 R2 ist. Mitglieder können sich dann nicht mehr über NTLM anmelden, keine Verschlüsselung mit DES oder RC4 in der Kerberos-Vorauthentifizierung verwenden, weder mit eingeschränkter noch mit uneingeschränkter Delegierung weitergereicht werden und ihr Ticket nicht über die anfängliche Gültigkeit von vier Stunden hinaus erneuern. Diese vier Stunden sind fest verdrahtet, konkret setzt die Gruppe die beiden zugehörigen Werte auf zweihundertvierzig Minuten.

Genau hier liegen die Fallstricke. Mitglieder müssen sich über Kerberos mit AES anmelden können, also müssen für das Konto im Verzeichnis AES-Schlüssel vorliegen. Das eingebaute Administratorkonto besitzt keinen solchen Schlüssel, solange sein Kennwort nicht auf einem hinreichend neuen Domänencontroller geändert wurde, und Konten, deren Kennwort zuletzt auf einem älteren Domänencontroller gesetzt wurde, können sich anschließend nicht mehr anmelden. Microsoft empfiehlt deshalb ausdrücklich, für jedes Konto vor der Aufnahme das Kennwort zu ändern. Ebenso ausdrücklich warnt Microsoft davor, Konten für Dienste und Computer aufzunehmen, weil die Gruppe dort keinen lokalen Schutz bietet: Kennwort oder Zertifikat liegen auf dem jeweiligen Host ohnehin vor.

Die zweite Warnung betrifft die hoch privilegierten Gruppen. Für Mitglieder von Enterprise Admins oder Domain Admins gelten dieselben Einschränkungen ohne jede Umgehungsmöglichkeit. Wer sämtliche Mitglieder dieser Gruppen auf einen Schlag aufnimmt, riskiert, dass sich alle diese Konten gleichzeitig aussperren. Der gangbare Weg ist ein einzelnes Testkonto, danach die reinen Tier-0-Konten und erst am Ende der Rest. Zur Fehlersuche gibt es zwei Protokolle unterhalb von Anwendungs- und Dienstprotokolle, Microsoft, Windows, Authentication, die standardmäßig abgeschaltet sind und vor dem Test eingeschaltet gehören.

Authentifizierungsrichtlinien: das Gerät wird Teil der Anmeldung

Protected Users ist bewusst nicht konfigurierbar, und genau deshalb reicht die Gruppe nicht für alles. Authentifizierungsrichtlinien ergänzen sie um einstellbare Einschränkungen und decken zusätzlich Konten für Dienste und Computer ab, die nicht Mitglied von Protected Users sein dürfen. Sie greifen an zwei Stellen im Kerberos-Ablauf: beim ersten Ticket und bei der Anforderung eines Diensttickets. Für das erste Ticket lassen sich eine eigene Gültigkeitsdauer und Bedingungen festlegen, die das Gerät erfüllen muss, von dem die Anfrage kommt. Für Diensttickets lassen sich Bedingungen an den Aufrufer und an dessen Gerät knüpfen.

Ein Authentifizierungssilo verbindet Benutzer-, Computer- und Dienstkonten zu einer Einheit, und ein Konto kann nur genau einem Silo angehören. Damit lässt sich die Aussage treffen, dass ein bestimmtes Verwaltungskonto sich ausschließlich an bestimmten Verwaltungsarbeitsplätzen anmelden kann. Konten in einem Silo tragen zusätzlich eine Kennzeichnung, auf die Dienste wie Dateiserver bei der Zugriffsentscheidung reagieren können.

Die Voraussetzungen sind überschaubar, aber sie müssen stimmen. Für eigene Ticketlaufzeiten braucht die Kontodomäne die Domänenfunktionsebene Windows Server 2012 R2. Für die Einschränkung, von welchen Geräten aus eine Anmeldung erlaubt ist, kommt die Unterstützung für Dynamic Access Control dazu, auf der Seite der Domänencontroller wie auf der Seite der Geräte. Und der Schalter im Domänencontroller-Regelwerk, mit dem sich Anfragen ohne Armoring abweisen lassen, führt bei jedem Betriebssystem ohne Kerberos-Armoring zu Anmeldefehlern. Das ist genau der Punkt, an dem alte Systeme aus dem Netz fallen.

Der wichtigste praktische Hinweis betrifft den Einstieg. Ein neu angelegtes Silo prüft seine Regeln zunächst nur und wendet sie nicht an, was dem Verhalten des WhatIf-Schalters in PowerShell entspricht, und dabei entstehen Meldungen darüber, was bei einer Durchsetzung fehlgeschlagen wäre. Bleib in diesem Zustand, bis über mehrere Wochen keine unerwarteten Meldungen mehr auflaufen. Zur Auswertung gibt es ein eigenes Protokoll für fehlgeschlagene Authentifizierungsrichtlinien unterhalb von Anwendungs- und Dienstprotokolle, Microsoft, Windows, Authentication, das ebenfalls erst eingeschaltet werden muss. Eine Besonderheit ist noch zu beachten: Das eingebaute Administratorkonto der Domäne ist von Authentifizierungsrichtlinien immer ausgenommen, auch wenn es einem Silo zugewiesen ist.

Lokale Administratorkennwörter und der Weg über Windows LAPS

Windows LAPS verwaltet das Kennwort eines lokalen Administratorkontos auf Geräten, die einer Active-Directory-Domäne oder Microsoft Entra ID beigetreten sind, sichert es an der jeweiligen Stelle und wechselt es regelmäßig. Auf Domänencontrollern kann derselbe Mechanismus zusätzlich das Kennwort für den Verzeichnisdienst-Wiederherstellungsmodus verwalten, und berechtigte Personen können es dort abrufen.

Der wichtigste Unterschied zum alten Produkt ist, dass Windows LAPS Bestandteil von Windows ist und nichts nachinstalliert werden muss. Es ist ab Windows Server 2025 sowie in der jährlichen Auslieferung für Container ab 23H2 enthalten und wurde für Windows Server 2019 und 2022 mit dem Update vom 11. April 2023 nachgeliefert, ebenso für Windows 10 und Windows 11. Das ältere Microsoft-LAPS-Produkt ist ab Windows 11 23H2 abgekündigt, die Installation des zugehörigen Pakets wird auf neueren Betriebssystemversionen blockiert, und Microsoft nimmt dafür keine Codeänderungen mehr vor. Für den Übergang gibt es einen Betriebsmodus, der das alte Verhalten nachbildet.

Für die Ablage gilt eine klare Regel, die vor der Einführung feststehen muss: Geräte, die nur Microsoft Entra ID beigetreten sind, können ihr Kennwort ausschließlich dorthin sichern, Geräte, die nur der Domäne beigetreten sind, ausschließlich ins Verzeichnis. Geräte mit beidem können sich für eine der beiden Ablagen entscheiden, aber nicht für beide gleichzeitig. Die Funktion selbst ist in allen unterstützten Windows-Plattformen kostenfrei, die Sicherung ins lokale Verzeichnis stellt keine weiteren Lizenzanforderungen, und für die Sicherung nach Microsoft Entra ID genügt die kostenfreie Stufe.

Der Nutzen ist gerade für die Kette aus dem ersten Abschnitt groß. Sobald jeder Rechner ein eigenes, zufälliges Kennwort für sein lokales Administratorkonto hat, endet die seitliche Bewegung über dieses Konto sofort. Microsoft führt genau das als ersten Vorteil auf, nämlich den Schutz vor Angriffen mit weitergegebenen Hashwerten und vor seitlicher Bewegung im Netz. Ergänzend lassen sich die Kennwörter im Verzeichnis verschlüsselt ablegen und ein Verlauf mitführen.

Was Windows Server 2025 an dieser Stelle mitbringt

Ein Teil der Arbeit, die früher von Hand konfiguriert werden musste, ist inzwischen Voreinstellung. Credential Guard ist ab Windows Server 2025 auf Geräten, die die Voraussetzungen erfüllen, standardmäßig eingeschaltet. Neue Active-Directory-Bereitstellungen verlangen für die gesamte LDAP-Kommunikation nach einer Bindung über SASL standardmäßig eine Signierung und Versiegelung. Domänencontroller und AD-LDS-Instanzen erlauben Operationen mit vertraulichen Attributen nur noch über verschlüsselte Verbindungen.

Bei den Verschlüsselungsverfahren zieht Microsoft nach. Das Schlüsselverteilungszentrum stellt keine Ticket-Granting-Tickets mehr mit RC4 aus, und die Verwendung von RC4 im Kerberos-Protokoll ist ausdrücklich als nicht mehr weiterentwickelt eingestuft, mit dem Hinweis auf stärkere Verfahren. Der alte Registrierungswert für die unterstützten Verschlüsselungsarten wird nicht mehr beachtet, Microsoft verweist stattdessen auf die entsprechende Gruppenrichtlinie. Wer noch Systeme betreibt, die zwingend RC4 brauchen, findet sie über diese Umstellung zuverlässig.

Auch beim Kennwortwechsel über die alte Schnittstelle des Sicherheitskontenverwalters hat sich etwas getan. Auf Domänencontrollern wird die aktuelle Methode mit AES bei einem Aufruf über das Netz standardmäßig akzeptiert, während drei ältere Methoden standardmäßig blockiert sind. Für Konten, die Mitglied von Protected Users sind, und für lokale Konten auf Domänenmitgliedern werden alle Kennwortwechsel über diese alte Schnittstelle blockiert, auch die aktuelle Methode. Steuern lässt sich das über eine eigene Richtlinie unterhalb von Computerkonfiguration, Administrative Vorlagen, System, Sicherheitskontenverwalter.

Für neu angelegte Computerkonten verwendet Active Directory jetzt zufällig erzeugte Standardkennwörter, und Domänencontroller unter Windows Server 2025 verhindern, dass ein Computerkontokennwort auf den Kontonamen gesetzt wird. Wer den ganzen Sprung noch vor sich hat, sollte diese Punkte in die Planung der Umstellung aufnehmen, denn sie sind fachlich sinnvoll, verändern aber das Verhalten bestehender Abläufe. Und weil der Umstieg auf die neue Funktionsebene Voraussetzung für die neue Datenbankseitengröße von zweiunddreißig Kilobyte ist, hängt an dieser Entscheidung mehr als nur ein Versionsstand.