Kerberos Armoring (FAST): Active Directory Flexible Authentication Secure Tunneling ist standardmäßig deaktiviert

Kerberos Armoring, FAST, Active Directory Flexible Authentication Secure Tunneling

Kerberos Armoring, FAST, Active Directory Flexible Authentication Secure Tunneling — Microsoft stapelt all diese Namen auf ein einziges Feature, und in einer Standarddomäne ist dieses Feature deaktiviert. Beide Gruppenrichtlinien-Einstellungen, die es aktivieren, kommen als Not Configured (nicht konfiguriert) ausgeliefert. Dadurch durchläuft der Authentifizierungsaustausch, der aus dem Kennwort abgeleitetes Material transportiert, die Leitung ohne geschützten Kanal darum herum — obwohl jede unterstützte Windows-Server-Version es seit Windows Server 2012 armieren kann.

FAST ist in RFC 6113, A Generalized Framework for Kerberos Pre-Authentication definiert. Die IANA registriert dessen Pre-Authentication-Datentyp PA-FX-FAST als Padata-Typ 136, neben PA-FX-COOKIE (133), PA-FX-ERROR (137) und PA-ENCRYPTED-CHALLENGE (138). Microsofts eigene Beschreibung der Windows-Implementierung ist kurz und präzise: „Flexible Authentication Secure Tunneling (FAST) stellt einen geschützten Kanal zwischen dem Kerberos-Client und dem KDC bereit. FAST ist in Windows Server 2012 als Kerberos-Armoring implementiert und nur für Authentication-Service(AS)- und Ticket-Granting-Service(TGS)-Austausche verfügbar."

Microsoft nennt drei Vorteile für domänenbeigetretene Systeme, und der erste ist der Grund, warum dieser Artikel existiert:

• Schutz vor Offline-Dictionary-Angriffen. „Kerberos-Armoring schützt die Pre-Authentication-Daten des Benutzers, die anfällig für Offline-Dictionary-Angriffe sind, wenn sie aus einem Kennwort erzeugt werden."
• Authentifizierte Kerberos-Fehler. Armoring „schützt Kerberos-Authentifizierungen von Benutzern vor KDC-Kerberos-Fehler-Spoofing, das ein Downgrade auf NTLM oder schwächere Kryptografie ermöglichen kann."
• Compound Authentication, die Geräte-Identitäts-Erweiterung, die von Dynamic Access Control verwendet wird.

Quelle: What's New in Kerberos Authentication, Microsoft Learn.

Wie Kerberos-Armoring funktioniert

FAST verpackt die eigentliche Anfrage in einen äußeren Austausch, der mit einem Armor-Key verschlüsselt ist. RFC 6113 stellt in den ASN.1-Definitionen sowohl der armierten Anfrage als auch der armierten Antwort unmissverständlich fest, dass „der Verschlüsselungsschlüssel der Armor-Key ist". Ein Beobachter im Netzwerk sieht den armierten Umschlag, nicht die darin enthaltenen Pre-Authentication-Daten.

Welche Austausche tatsächlich armiert werden

Woher der Armor-Key stammt, ist der Teil, der die meisten Leute stolpern lässt. Microsoft: „Kerberos-Armoring verwendet ein Ticket-Granting-Ticket (TGT) für das Gerät, um Authentication-Service-Austausche mit dem KDC zu schützen, sodass der Authentication-Service-Austausch des Computers nicht armiert wird. Das TGT des Benutzers wird verwendet, um dessen TGS-Austausche mit dem KDC zu schützen."

Lesen Sie das zweimal, denn es definiert die Grenze dieser Kontrolle:

Die eigene initiale Authentifizierung der Maschine kann nicht armiert werden, weil der Armor-Key genau das ist, was sie erst noch erhalten will. Jede darauffolgende Benutzeranmeldung auf dieser Maschine kann es sein.

RFC 6113 ist explizit, welchen Angriff das ausschließt: „Die in diesem Abschnitt definierten Kerberos-FAST-Pre-Authentication-Padata bieten ein Werkzeug, um die Anfälligkeit für Offline-Dictionary-Angriffe erheblich zu reduzieren. In Kombination mit Encrypted Challenge zwingt FAST einen Angreifer, einen erfolgreichen Man-in-the-Middle-Angriff durchzuführen, um Chiffretext zu beobachten."

Warum unarmierte Pre-Authentication abschöpfbar ist

Ohne FAST ist der Standard-Windows-Pre-Authentication-Ablauf PA-ENC-TIMESTAMP — Pre-Authentication-Typ 2, den Microsoft als „normalen Typ für die Standard-Kennwortauthentifizierung" dokumentiert. Der Client weist die Kenntnis des Kennworts nach, indem er einen Zeitstempel mit einem aus diesem Kennwort abgeleiteten Schlüssel verschlüsselt, und der KDC gibt eine AS-REP zurück, deren verschlüsselter Teil durch denselben kennwortabgeleiteten Schlüssel geschützt ist.

Beide Hälften sind kennwortabgeleiteter Chiffretext, und RFC 6113 beschreibt die Konsequenz direkt: „Ein Angreifer kann eine AS-REP anfordern und verschiedene Kennwörter ausprobieren, um zu sehen, ob sie das resultierende Ticket entschlüsseln können."

Trimarc Securitys Analyse von Kerberos-Armoring (veröffentlicht im Juli 2024) macht denselben Punkt zur Ökonomie: „Der Vorgang, ein Kennwort mit einer dieser Methoden zu knacken, läuft vollständig offline ab, das heißt, ein Angreifer kann sich so viel Zeit nehmen, wie er braucht."

Hier hört die übliche Remediation-Empfehlung zu früh auf. Die Standardfixes für AS-REP-Roasting und Kerberoasting — längere Kennwörter, Group Managed Service Accounts, RC4-Fallback entfernen — machen das Knacken alles schwerer. Keiner davon verhindert, dass Material gesammelt wird. FAST setzt stattdessen am Sammelschritt an, indem es den Austausch in einen Kanal legt, den der Sammler nicht lesen kann.

Was Armoring strukturell verändert, ist die Position des nicht authentifizierten Sammlers. Wenn der KDC so konfiguriert ist, dass er unarmierte Kerberos-Nachrichten ablehnt, kann eine AS-REQ, die von einem Tool ohne Geräte-TGT erzeugt wurde, nicht armiert werden — und wird deshalb abgelehnt, bevor überhaupt eine AS-REP zurückgegeben wird. Dieses Verhalten folgt direkt aus der dokumentierten Option „Fail unarmored authentication requests", die weiter unten beschrieben wird.

Die Gruppenrichtlinien-Einstellungen, die standardmäßig deaktiviert sind

Drei Einstellungen steuern das, verteilt auf zwei Administrative-Templates-Knoten. Alle drei sind ab Werk Not Configured.

Registrierungspfade, Anzeigenamen und zitierte Beschreibungen stammen aus den Referenzen ADMX_kdc und Kerberos der Policy CSP.

Die vier KDC-Optionen

Die KDC-Einstellung hat vier Optionen, und die Unterschiede sind nicht kosmetisch:

Zwei Konsequenzen gehören auf einen Klebezettel, bevor jemand die Domain Controllers OU anfasst:

🚨 Gefahr: Microsofts eigene Warnung zur KDC-Richtlinie — „Wenn 'Fail unarmored authentication requests' gesetzt ist, können sich Client-Computer, die Kerberos-Armoring nicht unterstützen, nicht mehr beim Domänencontroller authentifizieren." Jeder Kerberos-Client, der nicht armieren kann — Appliances, Nicht-Windows-Hosts, eingebettete Systeme, alles älter als Windows 8 / Windows Server 2012 — hört auf, sich zu authentifizieren. Inventarisieren Sie, bevor Sie erzwingen, nicht danach.

Der zweite: Die beiden strikten Optionen tun unterhalb der Windows-Server-2012-Domänenfunktionsebene stillschweigend nichts. Microsoft stellt fest, dass beide Optionen „bei jedem Domänencontroller, der nicht unter Windows Server 2012 läuft, zeitweise Authentifizierungs- oder Zugriffskontrollfehler in der Domäne verursachen. Deshalb greifen diese beiden Optionen erst, wenn die Domäne auf die Windows-Server-2012-Funktionsebene gesetzt ist. Bis dahin verhalten sich unter Windows Server 2012 laufende Domänencontroller so, als sei die Option Supported konfiguriert." Eine Domäne, die noch auf der Funktionsebene 2008 R2 sitzt, kann „Fail unarmored" konfigurieren und bekommt stattdessen das Verhalten von Supported: Armoring wird Clients angeboten, die es anfordern, nichts wird erzwungen.

Erkennung

Der Armoring-Status lässt sich aus drei unabhängigen Blickwinkeln messen: Konfiguration, Live-Authentifizierungs-Telemetrie und KDC-Health-Events.

Indikatoren, die den Armoring-Zustand offenlegen

Die Pre-Authentication-Typ-Tabelle und die Überwachungsempfehlungen stammen aus Microsofts Referenz zu 4768(S, F) A Kerberos authentication ticket (TGT) was requested, die empfiehlt, zu alarmieren, wenn der „Wert nicht 138 ist, obwohl Kerberos-Armoring für die gesamte Kerberos-Kommunikation der Organisation aktiviert ist." Events 33 und 34 sowie die FAST-Leistungsindikatoren sind in What's New in Kerberos Authentication dokumentiert.

Prüfen, ob die Richtlinien konfiguriert sind

Beginnen Sie mit dem Konfigurationszustand. Führen Sie auf einem Domänencontroller aus:

# Enforcement-Optionen benötigen mindestens die Windows-Server-2012-Domänenfunktionsebene
Get-ADDomain | Select-Object DNSRoot, DomainMode

# KDC-Seite: kein Rückgabewert bedeutet, die Richtlinie ist Not Configured
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\KDC\Parameters' `
                 -Name EnableCbacAndArmor -ErrorAction SilentlyContinue

Dann die Client-Seite, auf einer Workstation oder einem Member-Server:

Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters' `
                 -Name EnableCbacAndArmor, RequireFast -ErrorAction SilentlyContinue

Messen, wie viele Anmeldungen tatsächlich armiert sind

Die Konfiguration verrät nur die Absicht. Um zu messen, was tatsächlich passiert, gruppieren Sie live erfasste TGT-Anfragen auf einem Domänencontroller nach Pre-Authentication-Typ:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4768 } -MaxEvents 5000 |
    ForEach-Object {
        $x = [xml]$_.ToXml()
        [pscustomobject]@{
            PreAuthType = ($x.Event.EventData.Data |
                Where-Object { $_.GetAttribute('Name') -eq 'PreAuthType' }).'#text'
        }
    } |
    Group-Object PreAuthType |
    Sort-Object Count -Descending |
    Format-Table Count, Name -AutoSize

Das Feld über sein Name-Attribut auszuwählen statt über einen Positionsindex ist wichtig: Microsoft hat mit dem kumulativen Update vom Januar 2025 für Windows Server 2016 und neuer eine aktualisierte Version von Event 4768 mit zusätzlichen Feldern ausgeliefert, sodass sich die Feldpositionen zwischen den Event-Versionen unterscheiden.

Um ausschließlich die unarmierten Anfragen zu ziehen:

Get-WinEvent -LogName Security -MaxEvents 50 -FilterXPath @"
*[System[EventID=4768] and EventData[Data[@Name='PreAuthType'] != '138']]
"@

Speisen Sie denselben 4768-Stream in das ein, was Sie bereits für die Active-Directory-Ereignisüberwachung verwenden. Das Verhältnis von Typ 138 zu allem anderen ist die eine Zahl, die zeigt, wie weit ein Rollout tatsächlich fortgeschritten ist.

Remediation

Der stufenweise Rollout

Rollen Sie in dieser Reihenfolge aus. Trimarcs Empfehlung zur Reihenfolge ist eindeutig: „Stellen Sie sicher, dass Kerberos-Armoring zuerst für Clients aktiviert wird … Diese Änderung muss auf allen Clients angewendet werden, bevor sie auf Domänencontrollern konfiguriert wird."

1. Bestätigen Sie die Domänenfunktionsebene. Get-ADDomain | Select-Object DomainMode muss Windows Server 2012 oder höher melden, bevor die erzwingenden Optionen überhaupt etwas bewirken. Ist die Domäne noch darunter, wird das zuerst zu einem Projekt zur Anhebung der Funktionsebene.

2. Aktivieren Sie die Client-Richtlinie auf allen Clients. Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring → Enabled. Verknüpfen Sie sie mit den OUs für Workstations und Member-Server, nicht nur mit einer Pilotgruppe. Prüfen Sie, ob die Richtlinie tatsächlich angewendet wurde — ein fehlerhaft konfiguriertes oder falsch zugewiesenes GPO ist der häufigste Grund, warum ein Rollout still zum Stillstand kommt:

gpupdate /force
gpresult /h C:\Temp\kerberos-armoring.html

3. Setzen Sie die KDC-Richtlinie auf der Domain Controllers OU auf Supported. Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring → Enabled, Option Supported. Protokolliert ein Domänencontroller danach das System-Event 33, lautet Microsofts dokumentierte Lösung, gpupdate /force auf einem Domänencontroller auszuführen.

4. Messen, bevor Sie erzwingen. Beobachten Sie die Leistungsindikatoren KDC AS Requests with FAST und KDC armored TGS Requests sowie die Verteilung der Pre-Authentication-Typen in 4768. Jedes Prinzipal, das noch Typ 2 zeigt, ist ein Client, der bei einer Erzwingung ausfallen wird.

5. Inventarisieren Sie die Clients, die nicht armieren können. Armoring-Unterstützung beginnt bei Windows-8- und Windows-Server-2012-Clients. Appliances, Linux- und UNIX-Hosts, Netzwerkgeräte und Legacy-Kerberos-Stacks brauchen jeweils eine explizite Entscheidung: aktualisieren, per OU-Scoping ausnehmen, oder akzeptieren, dass die Erzwingung sie aussperren wird.

6. Erst danach erzwingen. Auf der KDC-Seite zu Fail unarmored authentication requests wechseln. Auf der Client-Seite Fail authentication requests when Kerberos armoring is not available aktivieren. Tun Sie dies nacheinander, mit einem Rollback-Plan, und niemals beides im selben Change-Fenster.

Kapazität und Kosten, bevor Sie erzwingen

Stellen Sie genügend armoring-fähige Domänencontroller bereit, um die Last zu tragen, bevor Sie erzwingen. Die ADMX_kdc-Referenz warnt, dass eine „unzureichende Anzahl von Domänencontrollern, die diese Richtlinie unterstützen, zu Authentifizierungsfehlern führt, sobald Dynamic Access Control oder Kerberos-Armoring erforderlich ist."

Kalkulieren Sie schließlich die Kosten ein. Microsoft ist in derselben Referenz unverblümt: „Kerberos-Armoring verschlüsselt Kerberos-Nachrichten vollständig und signiert Kerberos-Fehler, was die Verarbeitungszeit erhöht, aber die Größe des Service-Tickets nicht verändert." Ticket-Aufblähung ist hier nicht das Problem; die DC-CPU-Last ist es.

Wie EtcSec das erkennt

Der Vulnerability-Katalog von EtcSec führt diese Kontrolle als zwei separate Prüfungen, weil die Client-Hälfte und die KDC-Hälfte unabhängig voneinander fehlschlagen können und eine Domäne leicht die eine ohne die andere haben kann:

• KERBEROS_ARMORING_DC_DISABLED — Kerberos Armoring (FAST) Not Enforced on DCs
• KERBEROS_ARMORING_CLIENT_DISABLED — Kerberos Armoring (FAST) Not Required on Clients
• ANSSI_R27_KERBEROS_PREAUTH_NOT_FAST — die compliance-orientierte Sicht auf dieselbe Kontrolle

Diese Prüfungen werden mit den Angriffsflächen-Einträgen korreliert, die sie tatsächlich mindern — ASREP_ROASTING_RISK, KERBEROASTING_RISK und KERBEROS_RC4_FALLBACK —, sodass ein Report sowohl die Konten zeigt, die Offline-Cracking ausgesetzt sind, als auch, ob die Kontrolle auf Protokollebene, die das Abschöpfen begrenzt, eingeschaltet ist. Genau diese Verknüpfung ist der Punkt: Ein Audit, das roastbare Konten meldet, ohne den Armoring-Status zu melden, beschreibt nur die halbe Geschichte. Wenn Sie an einem umfassenderen Review arbeiten, gehört diese Kontrolle natürlich neben den Rest eines Active-Directory-Sicherheitsaudits.