Kerberos Armoring (FAST): Active Directory Flexible Authentication Secure Tunneling Is Off by Default

Kerberos Armoring, FAST, Active Directory Flexible Authentication Secure Tunneling

Kerberos armoring, FAST, Active Directory Flexible Authentication Secure Tunneling — Microsoft stacks all of those names on one feature, and in a default domain that feature is off. Both Group Policy settings that switch it on arrive as Not Configured, so the authentication exchange that carries password-derived material crosses the wire with no protected channel around it, even though every supported version of Windows Server has been able to armor it since Windows Server 2012.

FAST is defined in RFC 6113, A Generalized Framework for Kerberos Pre-Authentication. IANA registers its pre-authentication data type PA-FX-FAST as padata type 136, alongside PA-FX-COOKIE (133), PA-FX-ERROR (137) and PA-ENCRYPTED-CHALLENGE (138). Microsoft's own description of the Windows implementation is short and precise: "Flexible Authentication Secure Tunneling (FAST) provides a protected channel between the Kerberos client and the KDC. FAST is implemented as Kerberos armoring in Windows Server 2012, and it is only available for authentication service (AS) and ticket-granting service (TGS) exchanges."

Microsoft lists three benefits for domain-joined systems, and the first one is the reason this article exists:

• Protection against offline dictionary attacks. "Kerberos armoring protects the user's preauthentication data, which is vulnerable to offline dictionary attacks when it is generated from a password."
• Authenticated Kerberos errors. Armoring "protects user Kerberos authentications from KDC Kerberos error spoofing, which can downgrade to NTLM or weaker cryptography."
• Compound authentication, the device-identity extension used by Dynamic Access Control.

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

How Kerberos Armoring Works

FAST wraps the real request inside an outer exchange encrypted under an armor key. RFC 6113 states plainly, in the ASN.1 definitions of both the armored request and the armored reply, that "the encryption key is the armor key." An observer on the network sees the armored envelope, not the pre-authentication data inside it.

Which exchanges are actually armored

Where the armor key comes from is the part that trips people up. Microsoft: "Kerberos armoring uses a ticket-granting ticket (TGT) for the device to protect authentication service exchanges with the KDC, so the computer's authentication service exchange is not armored. The user's TGT is used to protect its TGS exchanges with the KDC."

Read that twice, because it defines the boundary of the control:

The machine's own initial authentication cannot be armored, because the armor key is the thing it is trying to obtain. Every user logon on that machine afterwards can be.

RFC 6113 is explicit about the attack it removes: "The Kerberos FAST pre-authentication padata defined in this section provides a tool to significantly reduce vulnerability to offline dictionary attacks. When combined with encrypted challenge, FAST requires an attacker to mount a successful man-in-the-middle attack to observe ciphertext."

Why Unarmored Pre-Authentication Is Harvestable

Without FAST, the standard Windows pre-authentication flow is PA-ENC-TIMESTAMP — pre-authentication type 2, which Microsoft documents as "a normal type for standard password authentication." The client proves knowledge of the password by encrypting a timestamp with a key derived from that password, and the KDC returns an AS-REP whose encrypted part is protected by the same password-derived key.

Both halves are password-derived ciphertext, and RFC 6113 describes the consequence directly: "An attacker can request an AS-REP and try various passwords to see if they can decrypt the resulting ticket."

Trimarc Security's analysis of Kerberos armoring (published July 2024) makes the same point about the economics: "The process of attempting to crack a password using one of these methods is completely offline, meaning an attacker can take as much time as needed."

This is where the usual remediation advice stops short. The standard fixes for AS-REP roasting and Kerberoasting — longer passwords, group managed service accounts, removing RC4 fallback — all make the cracking harder. None of them stop material from being collected. FAST attacks the collection step instead, by putting the exchange inside a channel the collector cannot read.

What armoring does change structurally is the position of the unauthenticated collector. When the KDC is configured to reject unarmored Kerberos messages, an AS-REQ produced by tooling that holds no device TGT cannot be armored, and so it is refused before any AS-REP is returned. That behaviour follows directly from the documented "Fail unarmored authentication requests" option described below.

The Group Policy Settings That Are Off by Default

Three settings govern this, spread across two Administrative Templates nodes. All three are Not Configured out of the box.

Registry paths, friendly names and quoted descriptions come from the ADMX_kdc and Kerberos Policy CSP references.

The four KDC options

The KDC setting has four options, and the differences are not cosmetic:

Two consequences deserve to be on a sticky note before anyone touches the Domain Controllers OU:

🚨 Danger: Microsoft's own warning on the KDC policy — "When 'Fail unarmored authentication requests' is set, then client computers which don't support Kerberos armoring will fail to authenticate to the domain controller." Any Kerberos client that cannot armor — appliances, non-Windows hosts, embedded systems, anything older than Windows 8 / Windows Server 2012 — stops authenticating. Inventory before you enforce, not after.

The second: the two strict options silently do nothing below Windows Server 2012 domain functional level. Microsoft states that both options "cause intermittent authentication or access control failures if there are any domain controllers not running Windows Server 2012 in the domain. So neither of these options will take effect until the domain is set at the Windows Server 2012 functional level. Until then, domain controllers running Windows Server 2012 will behave as if the Supported option is configured." A domain still sitting at a 2008 R2 functional level can configure "Fail unarmored" and get Supported behaviour instead: armoring offered to clients that ask for it, nothing enforced.

Detection

Armoring status is measurable from three independent angles: configuration, live authentication telemetry, and KDC health events.

Indicators that reveal the armoring state

The pre-authentication type table and the monitoring guidance come from Microsoft's reference for 4768(S, F) A Kerberos authentication ticket (TGT) was requested, which recommends alerting when the "Value is not 138 when Kerberos Armoring is enabled for all Kerberos communications in the organization." Events 33 and 34 and the FAST performance counters are documented in What's New in Kerberos Authentication.

Check whether the policies are configured

Start with configuration state. Run on a domain controller:

# Enforcement options need Windows Server 2012 domain functional level or higher
Get-ADDomain | Select-Object DNSRoot, DomainMode

# KDC side: nothing returned means the policy is Not Configured
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\KDC\Parameters' `
                 -Name EnableCbacAndArmor -ErrorAction SilentlyContinue

Then the client side, on a workstation or member server:

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

Measure how many logons are actually armored

Configuration only tells you intent. To measure what is actually happening, group live TGT requests by pre-authentication type on a domain controller:

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

Selecting the field by its Name attribute rather than by positional index matters: Microsoft shipped an updated version of Event 4768 with additional fields in the January 2025 cumulative update for Windows Server 2016 and later, so field positions differ between event versions.

To pull only the unarmored requests directly:

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

Feed the same 4768 stream into whatever you already use for Active Directory event monitoring. The ratio of type 138 to everything else is the single number that tells you how far a rollout has actually progressed.

Remediation

The staged rollout

Roll out in this order. Trimarc's guidance is unambiguous on the sequencing: "Ensure that Kerberos Armoring is enabled for clients first… This change needs to be applied to all clients before being configured on Domain Controllers."

1. Confirm the domain functional level. Get-ADDomain | Select-Object DomainMode must report Windows Server 2012 or higher before the enforcing options do anything. If you are still below it, this becomes a functional-level upgrade project first.

2. Enable the client policy on all clients. Computer Configuration > Policies > Administrative Templates > System > Kerberos > Kerberos client support for claims, compound authentication and Kerberos armoring → Enabled. Link it to workstation and member-server OUs, not just a pilot group. Verify the policy actually applied — a broken or badly scoped GPO is the most common reason a rollout stalls silently:

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

3. Set the KDC policy to Supported on the Domain Controllers OU. Computer Configuration > Policies > Administrative Templates > System > KDC > KDC support for claims, compound authentication and Kerberos armoring → Enabled, option Supported. If a domain controller logs System event 33 afterwards, Microsoft's documented resolution is to run gpupdate /force on a domain controller.

4. Measure before enforcing. Watch the KDC AS Requests with FAST and KDC armored TGS Requests performance counters and the 4768 pre-authentication type distribution. Every principal still showing type 2 is a client that will break under enforcement.

5. Inventory the clients that cannot armor. Armoring support starts at Windows 8 and Windows Server 2012 clients. Appliances, Linux and UNIX hosts, network devices and legacy Kerberos stacks each need an explicit decision: upgrade, exempt by OU scoping, or accept that enforcement will lock them out.

6. Only then enforce. On the KDC side, move to Fail unarmored authentication requests. On the client side, enable Fail authentication requests when Kerberos armoring is not available. Do these one at a time, with a rollback plan, and never both in the same change window.

Capacity and cost before you enforce

Deploy enough armoring-capable domain controllers to carry the load before you enforce. The ADMX_kdc reference warns that an "insufficient number of domain controllers that support this policy result in authentication failures whenever Dynamic Access Control or Kerberos armoring is required."

Finally, budget for the cost. Microsoft is upfront in the same reference that "Kerberos armoring fully encrypts Kerberos messages and signs Kerberos errors which results in increased processing time, but doesn't change the service ticket size." Ticket bloat is not the concern here; DC CPU is.

How EtcSec Detects This

EtcSec's vulnerability catalogue carries this control as two separate checks, because the client half and the KDC half fail independently and a domain can easily have one without the other:

• 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 — the compliance-flavoured view of the same control

Those checks are correlated with the attack-surface entries they actually mitigate — ASREP_ROASTING_RISK, KERBEROASTING_RISK and KERBEROS_RC4_FALLBACK — so a report shows both the accounts exposed to offline cracking and whether the protocol-level control that limits harvesting is switched on. That pairing is the point: an audit that reports roastable accounts without reporting armoring state is describing half the problem. If you are working through a broader review, this control sits naturally alongside the rest of an Active Directory security audit.