Active Directory Authentifizierungsrichtlinien, Silos, Tier 0: Die Kerberos-Kontrolle, die kaum jemand einsetzt

Active Directory Authentifizierungsrichtlinien Silos Tier 0: Was sie wirklich sind

Active Directory Authentifizierungsrichtlinien Silos Tier 0-Schutz ist ein einzelnes Windows-Server-2012-R2-Feature, das die meisten Umgebungen selbst ein Jahrzehnt nach dessen Erscheinen noch nicht aktiviert haben. Ein Authentifizierungsrichtlinien-Silo ist ein AD-Container (objectClass msDS-AuthNPolicySilos), der die Benutzer-, Computer- und Dienstkonten zusammenfasst, die Sie schützen möchten. Eine Authentifizierungsrichtlinie (objectClass msDS-AuthNPolicies) ist das Regelwerk, das auf diesen Container angewendet wird — wie lange ein Kerberos-Ticket-Granting-Ticket (TGT) gültig sein kann, von welchen Geräten aus sich ein Konto überhaupt anmelden darf, und welche Prinzipale sich bei einem Dienst authentifizieren dürfen, der unter diesem Konto läuft.

Das Versprechen ist einfach: Ihre Domain Admins sollten sich ausschließlich von einer Handvoll Privileged Access Workstations (PAWs) und Domänencontrollern aus authentifizieren. Authentifizierungsrichtlinien und Silos sind der Mechanismus, der diese Annahme in etwas verwandelt, das der KDC tatsächlich durchsetzt — statt einer Regel, die nur in einem Onboarding-Dokument existiert.

Konten können genau einem Silo angehören. Nach der Zuweisung hängt der Domänencontroller bei der Anmeldung einen Authentication-Policy-Silo-Claim an das Kerberos-Ticket des Kontos an, den claims-fähige Ressourcen für eigene Zugriffsprüfungen nutzen können — zusätzlich zu dem, was die Richtlinie des Silos ohnehin schon einschränkt.

Microsofts eigenes Beispiel veranschaulicht die Absicht gut: Ein Silo „Forest Administrators" mit Enterprise-, Schema- und Domain-Admin-Konten wird angelegt, und eine Richtlinie sorgt dafür, dass eine kennwort- oder smartcard-basierte Anmeldung von jedem Gerät außer einem Domänencontroller oder einer festgelegten Admin-Konsole rundweg fehlschlägt. Dem Silo ist egal, wie die Anmeldedaten erlangt wurden — gephisht, per Replay wiederverwendet oder korrekt vom echten Administrator eingegeben —, es interessiert nur, ob das Quellgerät auf der Allow-List steht.

Ein einzelnes Silo kann alle drei Active-Directory-Kontoklassen aufnehmen — Benutzer-, Computer- und Managed-Service-Konten —, aber die Richtlinie verhält sich je Klasse unterschiedlich. Dienst- und Computerkonten sollten niemals der Gruppe Protected Users beitreten: Microsofts Begründung lautet, dass für diese Kontotypen jede eingehende Authentifizierung fehlschlägt, und die Mitgliedschaft bringt ohnehin keinen lokalen Schutz, weil das Kennwort oder Zertifikat immer auf dem Host vorhanden ist. Microsoft rät zudem grundsätzlich davon ab, für Computerkonten überhaupt eine TGT-Lebensdauer zu konfigurieren. Die Unterscheidung nach Kontotyp ist ebenso wichtig wie die Silo-Mitgliedschaft selbst.

Funktionsweise: TGT-Lebensdauer, Claims und die Armoring-Voraussetzung

Authentifizierungsrichtlinien greifen an zwei Punkten im Kerberos-Austausch: beim AS-Austausch (initiale Anmeldung, TGT-Ausstellung) und beim TGS-Austausch (Anfragen von Service-Tickets). Drei Dinge lassen sich einschränken:

1. TGT-Lebensdauer — auf einen kürzeren, nicht verlängerbaren Wert als den Domänenstandard gesetzt (4 Stunden erhalten Mitglieder der Protected-Users-Gruppe automatisch). Ein Tier-0-Konto mit einem einstündigen, nicht verlängerbaren TGT bietet einem Angreifer, der ein Ticket stiehlt, ein deutlich kleineres Zeitfenster.
2. AllowedToAuthenticateFrom — die Menge der Geräte, von denen aus sich ein Benutzer anmelden kann. Wird beim AS-Austausch durchgesetzt.
3. AllowedToAuthenticateTo — die Menge der Prinzipale, die sich bei einem Dienst authentifizieren dürfen, der unter diesem Konto läuft. Wird beim TGS-Austausch durchgesetzt.

An den Geräteeinschränkungen bleiben die meisten Rollouts hängen. Die Prüfung von AllowedToAuthenticateFrom erfordert Kerberos Armoring (FAST): Der KDC benötigt das eigene TGT des anfragenden Geräts, um dessen Identität zu bestätigen, bevor er entscheiden kann, ob dieses Gerät auf der Allow-List steht. Die beiden Gruppenrichtlinien-Einstellungen, die Armoring aktivieren, sind in einer Standarddomäne Not Configured — dieser Lücke haben wir einen eigenen Artikel gewidmet —, sodass die Anmeldeeinschränkung in einer unveränderten Domäne stillschweigend nicht funktioniert, während die TGT-Lebensdauer-Einschränkung weiterhin greift. Das ist hier eine Voraussetzung, kein optionales Extra-Hardening.

Jedes Authentifizierungsrichtlinien-Silo startet im reinen Audit-Modus — das PowerShell-Äquivalent zu -WhatIf. Der Audit-Modus protokolliert, was fehlschlagen würde, ohne irgendetwas zu blockieren — so ist es vorgesehen, eine Richtlinie einzufahren, bevor sich ein Administrator selbst aus der eigenen Domäne aussperrt.

Warum diese Kontrolle in den meisten Tier-0-Umgebungen ungenutzt bleibt

Drei Reibungspunkte erklären, warum Authentifizierungsrichtlinien und Silos das Pilotstadium selten verlassen — selbst in Umgebungen, die Tiered Administration ansonsten ernst nehmen.

Die Domänenfunktionsebene, die niemand noch einmal prüft

Individuelle TGT-Lebensdauern benötigen die Domänenfunktionsebene Windows Server 2012 R2 in der Konten-Domäne. Die Einschränkung der Benutzeranmeldung benötigt dieselbe DFL in der Konten-Domäne mit Unterstützung für Dynamic Access Control, plus Client-Geräte, die Dynamic Access Control selbst unterstützen. Die Einschränkung der Service-Ticket-Ausstellung ist eine Anforderung an die Ressourcen-Domäne, die für sich genommen ebenfalls auf 2012-R2-DFL stehen muss — ein domänenübergreifendes Tier-0-Setup hat also zwei Funktionsebenen zu prüfen, nicht nur eine. Viele Domänen haben ihre DFL vor Jahren aus einem ganz anderen Grund angehoben — eine Forest-Trust-Migration, eine Schema-Erweiterung für ein anderes Projekt — und nie wieder nachgesehen, was diese Funktionsebene sonst noch freischaltet. Authentifizierungsrichtlinien-Silos bleiben auf dieser Liste ungenutzt, weil nichts einen Administrator dazu veranlasst, danach zu suchen.

Kein Override, keine Ausnahmen

Sobald ein Konto die Authentifizierungseinschränkungen trifft, gibt es keinen Workaround — ein Domain Admin, der durch ein erzwungenes Silo ausgesperrt wird, ist ausgesperrt, ohne Wenn und Aber (RID 500 ausgenommen). Microsoft formuliert diese unverblümte Warnung zur Gruppe Protected Users, nicht zu Silos, aber der Fehlermodus ist derselbe: Die Authentifizierungseinschränkungen kennen keinen Workaround, Enterprise Admins und Domain Admins unterliegen ihnen wie jeder andere, und die gleichzeitige Aufnahme aller Mitglieder dieser Gruppen kann sie alle aussperren — einschließlich der Konten, die das Problem normalerweise beheben würden. Microsofts separate Anleitung zu Authentifizierungsrichtlinien und Silos ist eher prozedural als beruhigend: Clients und Domänencontroller im Netzwerk halten, die Kennwörter geschützter Konten anschließend rotieren und Cached Logon deaktivieren, wo möglich. Dieses Risikoprofil reicht aus, damit die meisten Teams bei einem Pilotprojekt mit einem oder zwei Testkonten stehen bleiben und nie darüber hinauskommen.

Die Abhängigkeit von Armoring

Um aus den Geräteeinschränkungen echten Nutzen zu ziehen, muss Kerberos Armoring bereits funktionieren — und Armoring selbst ist eine eigene GPO-Änderung auf Domänencontrollern und Clients, die die meisten Teams noch nicht vorgenommen haben, siehe die Voraussetzung oben. Wer Authentifizierungsrichtlinien pilotiert, ohne vorher Armoring einzuführen, pilotiert ein Feature, das stillschweigend nur die Hälfte dessen tut, was es soll.

Keiner dieser Punkte ist ein Grund, die Kontrolle auszulassen. Ein verkürztes, nicht verlängerbares TGT auf Tier-0-Konten verkleinert direkt das Zeitfenster für ein gestohlenes Ticket — den Pass-the-Ticket-Fall, bei dem ein Angreifer ein gültiges TGT aus dem Speicher ausliest und es wiederverwendet, solange es noch gültig ist.

Seien Sie präzise, was die Kontrolle NICHT abdeckt. Eine Authentifizierungsrichtlinie prägt das Ticket, das der KDC ausstellt: Der Domänencontroller liefert bei der Beantwortung einer AS-Anfrage ein nicht verlängerbares TGT mit der konfigurierten Lebensdauer und prüft die Anmeldeeinschränkung gegen die armierte AS-REQ. Ein Golden Ticket wird offline mit dem krbtgt-Schlüssel gefälscht und durchläuft überhaupt keinen AS-Austausch — es trägt also welche Lebensdauer und welche Identität auch immer der Angreifer gewählt hat; die TGT-Lebensdauer und die Anmeldeeinschränkung des Silos haben keinen Zugriff darauf. Was einem gefälschten Ticket trotzdem gefährlich werden kann, ist die TGS-seitige Prüfung: Ein Dienst, dessen Konto eine AllowedToAuthenticateTo-Bedingung trägt, wird geprüft, wenn das Service-Ticket angefordert wird, nicht als das TGT ausgestellt wurde. Selbst das hat eine Grenze — es bleibt eine KDC-seitige Prüfung, und ein Silver Ticket wird gegen den eigenen Schlüssel des Dienstes gefälscht und direkt beim Host präsentiert, ohne dass der Domänencontroller je gefragt wird — sodass keine Authentifizierungsrichtlinie es jemals zu sehen bekommt.

Ein Authentifizierungsrichtlinien-Silo konfigurieren

Die vollständige Anleitung findet sich in Microsofts Guide zum Konfigurieren geschützter Konten; die Grundform:

1. Kerberos Armoring aktivieren

Per Gruppenrichtlinie, auf Domänencontrollern und Clients:

Computer Configuration > Administrative Templates > System > KDC
  "Key Distribution Center (KDC) client support for claims,
   compound authentication and Kerberos armoring" → Enabled, "Always provide claims"

Computer Configuration > Administrative Templates > System > Kerberos (clients)
  "Kerberos client support for claims, compound authentication
   and Kerberos armoring" → Enabled

Bestätigen Sie dies mit einer Test-Anmeldung von einem domänenbeigetretenen Client, bevor Sie irgendeine Richtlinie anfassen — Armoring-Fehler sind sonst stumm, und Sie wollen nicht zwei neue Features gleichzeitig debuggen.

2. Die Authentifizierungsrichtlinie erstellen

TGT-Lebensdauer in Minuten festlegen:

New-ADAuthenticationPolicy -Name "Tier0-AdminPolicy" `
  -UserTGTLifetimeMins 60 `
  -Description "Tier 0 admin accounts - 1h non-renewable TGT"

3. Das Silo erstellen — standardmäßig nicht erzwungen

New-ADAuthenticationPolicySilo -Name "Tier0-Silo"

Jedes neue Silo startet im Audit-Modus. Fügen Sie -Enforce erst hinzu, wenn die Audit-Phase sauber verläuft — das ist das eingebaute Äquivalent zu -WhatIf und existiert genau deshalb, damit ein Tippfehler in einer Zugriffskontrollbedingung nicht das Konto aussperrt, das den Fehler eigentlich beheben würde.

4. Zugriff gewähren und Konten zuweisen

Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account "da-jsmith"

Get-ADUser -Filter 'Name -like "da-*"' |
  Set-ADAccountAuthenticationPolicySilo -AuthenticationPolicySilo "Tier0-Silo" `
    -AuthenticationPolicy "Tier0-AdminPolicy"

Ein Konto muss sowohl Zugriff auf das Silo erhalten als auch das Silo/Richtlinien-Paar zugewiesen bekommen — Zugriff allein meldet das Konto noch nicht an.

5. Einfahren, dann erzwingen

Set-ADAuthenticationPolicySilo -Identity "Tier0-Silo" -Enforce $true
Set-ADAuthenticationPolicy -Identity "Tier0-AdminPolicy" -Enforce $true

Sowohl das Silo als auch die Richtlinie tragen ein eigenes Enforce-Flag — wird nur eines von beiden umgeschaltet, bleibt das andere im Audit-Modus, was während des Rollouts eine häufige Quelle für die Verwirrung „warum hat das nichts blockiert" ist.

Erkennung

Die Events liegen in einem standardmäßig deaktivierten operativen Log — dessen Aktivierung ist Schritt null, damit hiervon überhaupt etwas sichtbar wird:

Event Viewer > Applications and Services Logs > Microsoft > Windows >
Authentication > AuthenticationPolicyFailures-DomainController → Enable Log

Ein Anstieg von 105/106, nachdem ein Silo von Audit auf erzwungen umgestellt wurde, ist entweder eine legitime Aussperrung, die Sie beheben müssen (eine PAW, die noch nicht auf der Allow-List steht), oder ein echter Versuch, Tier-0-Anmeldedaten von einem nicht zulässigen Ort aus zu verwenden — beides ist einen Alarm wert.

Remediation

1. Tier-0-Konten inventarisieren sowie die exakte Menge der Hosts, von denen aus sie sich jemals authentifizieren sollen (PAWs, Domänencontroller — sonst nichts).
2. Kerberos Armoring per GPO auf Domänencontrollern und Tier-0-fähigen Clients aktivieren; vor dem Anfassen irgendeiner Richtlinie mit einer Test-Anmeldung bestätigen.
3. Die Authentifizierungsrichtlinie und das Silo im Audit-Modus erstellen; mindestens einen vollständigen Betriebszyklus lang nicht erzwingen.
4. Das Log AuthenticationPolicyFailures-DomainController aktivieren und die Events 305/306 auf False Positives prüfen — fehlende PAWs, vergessene Jump-Hosts.
5. Silo und Richtlinie erzwingen. Unmittelbar danach die Kennwörter aller aufgenommenen Konten rotieren.
6. Kombinieren Sie dies mit der Mitgliedschaft in der Protected-Users-Gruppe für Konten, die keine Kerberos-Delegation benötigen — Protected Users blockiert zusätzlich NTLM, DES/RC4-Preauth sowie sowohl constrained als auch unconstrained Delegation rundweg. Fügen Sie niemals Dienst- oder Computerkonten zu Protected Users hinzu; für diese Kontotypen schlägt jede eingehende Authentifizierung rundweg fehl.

Wie EtcSec das erkennt

Das Active-Directory-Audit von EtcSec markiert das Fehlen dieser Kontrolle aus mehreren Blickwinkeln statt mit einer einzelnen Prüfung: NOT_IN_PROTECTED_USERS erfasst privilegierte Konten, die nicht in der Protected-Users-Gruppe sind, WEAK_KERBEROS_POLICY markiert eine Domäne, deren maximale Ticket-Lebensdauer noch über 10 Stunden oder deren Verlängerungsfenster über 7 Tage liegt, FGPP_NOT_CONFIGURED markiert eine Domäne ganz ohne Fine-Grained-Password-Policy, und die ANSSI-orientierten Prüfungen ANSSI_R40_NO_PSO_TIER0 und ANSSI_R82_R83_ADMIN_ARCHITECTURE markieren gezielt Tier-0-Admin-Gruppen, die weder durch eine dedizierte Fine-Grained-Policy noch durch eine Anmelde-Einschränkungskontrolle abgedeckt sind.