Kerberos Armoring (FAST): Shutting Down Kerberoasting and AS-REP Roasting at the Protocol Level

Most defenses against Kerberoasting and AS-REP roasting are reactive: rotate service account passwords, make them long and random, and hope your detection catches the ticket requests before someone cracks them offline. That works, but it treats the symptom. The disease is that classic Kerberos pre-authentication leaks material an attacker can grind offline at their leisure. Kerberos Armoring—the Windows implementation of RFC 6113's Flexible Authentication Secure Tunneling (FAST)—closes that gap at the protocol layer by wrapping the authentication exchange in an encrypted, integrity-protected channel keyed to the machine account.

What FAST actually changes on the wire

In a normal Kerberos exchange, the AS-REQ and its pre-authentication data (the timestamp encrypted with the user's password-derived key) travel in a form an eavesdropper can capture and attack. The AS-REP for a roastable account, or the TGS-REP ticket for a service, contains a blob encrypted with a key derived from a password—exactly the thing a cracker feeds to Hashcat.

FAST introduces an armor key. The client first obtains a TGT for its own machine account, then uses that ticket to establish an armored channel. The real user authentication is tunneled inside that channel, so:

• Pre-authentication data is encrypted with the armor key, not just the user's key—there is no cleartext-adjacent timestamp to attack.
• The KDC error and reply data are integrity-protected, which blocks the tampering that enables certain downgrade attacks.
• Because armoring requires a valid machine TGT, an attacker who only knows a username can no longer harvest an AS-REP for an account with pre-auth disabled—the request never completes unarmored when armoring is enforced.

Why this matters for the two most common Kerberos attacks

AS-REP roasting

AS-REP roasting targets accounts with DONT_REQ_PREAUTH set. Without pre-auth, anyone can ask the KDC for that account's AS-REP and crack the encrypted portion offline. Under enforced FAST, the KDC will not service an unarmored request, so a domain-joined machine is required and the roastable blob is protected inside the tunnel. Armoring is not a substitute for fixing the misconfiguration—you should still clear DONT_REQ_PREAUTH—but it removes the free-for-all.

Kerberoasting

Kerberoasting is harder to fully neutralize because any authenticated user can request a service ticket. FAST does not stop the request, but combined with group managed service accounts (gMSA) and AES-only encryption it collapses the attack's economics: gMSA passwords are 240-byte machine-generated secrets that are computationally infeasible to crack, and armoring removes the RC4 downgrade path attackers rely on to get a cheaper hash.

Deploying FAST without breaking authentication

Armoring is delivered through the Kerberos client support for claims, compound authentication and Kerberos armoring policy, applied both to domain controllers and to clients. Roll it out in stages:

1. Inventory first. FAST requires Windows domain controllers at a functional level that supports it and clients capable of armoring. Legacy or non-Windows Kerberos clients that cannot armor will fail if you jump straight to enforced.
2. Enable "Supported" on clients. Set the client-side policy to Supported so capable machines armor when the KDC offers it, without hard failures.
3. Set the KDC to "Supported," then "Fail unarmored authentication requests." Only after you have confidence every client can armor do you flip the DC policy to reject unarmored requests. This is the switch that actually delivers the security benefit.

The relevant policy paths, for reference:

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

Domain Controller policy:
  - KDC support for claims, compound authentication and armoring
      Options: "Supported" -> validate -> "Fail unarmored authentication requests"

Enforcing before your fleet is ready is the classic way to lock users out of Kerberos. Measure armoring coverage across every machine before you flip the KDC to fail-closed.

Verifying and monitoring coverage

The hard part of FAST is not enabling it on one machine—it is proving that every endpoint negotiates armoring so the fail-closed switch is safe, and staying that way as machines drift. This is where per-host auditing earns its keep.

WinSentinel audits the Kerberos client armoring policy state, the effective encryption types (flagging RC4/DES allowances that undercut FAST), and roastable-account indicators on each machine it runs on. On a single machine, WinSentinel Free gives you the full audit—all 33 modules, no limits—so you can confirm a workstation or DC is configured correctly and armoring-capable before you touch enforcement.

For organizations rolling this out across a domain, Pro's fleet orchestration turns that per-host truth into a rollout gate: the central node aggregates armoring-support status across every managed endpoint, ranks the stragglers that would break under fail-closed, and raises a drift alert when a machine that was armoring-capable regresses (a re-imaged box, a reverted GPO, an RC4 exception quietly re-added). That is the difference between "we enabled a GPO" and "we can prove 100% coverage before flipping the switch."

The bottom line

Kerberos Armoring is one of the few controls that attacks roasting at the protocol level rather than through password hygiene alone. Pair it with AES-only encryption, gMSA for service accounts, and elimination of DONT_REQ_PREAUTH, and you take Kerberoasting and AS-REP roasting from "cheap offline win" to "not worth the effort." Audit every host for armoring support first, stage the rollout, and only fail-closed once coverage is proven.