# Kerberos in Windows: The Other Half of NTLMless
> After NTLM, Kerberos becomes the load-bearing authentication protocol for Windows. Eight years of attacks, the December 2025 Beyond-RC4 cadence, and the H2 2026 IAKerb / Local KDC broad enable.
*Published: 2026-05-11*
*Canonical: https://paragmali.com/blog/kerberos-in-windows-the-other-half-of-ntlmless*
*License: CC BY 4.0 - https://creativecommons.org/licenses/by/4.0/*
---
**Kerberos was a 1988 protocol that solved one problem: mutual authentication on an untrusted network using a trusted third party.** Then it got piled on for thirty-three years. In 2026 NTLM is being switched off, the AS-REQ / AS-REP / TGS-REQ / TGS-REP skeleton is finally the single load-bearing authentication path for Windows, and the eleven attack primitives that exposed every joint of that skeleton between 2014 and 2022 are still mostly fixable by configuration, not by protocol. This is the companion to [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/): what happens to the protocol that takes over.
## 1. A Chain Without NTLM
Imagine a defender who has done every NTLM retrofit Microsoft has shipped. NTLM is disabled by default on the workstations. `RestrictNTLMInDomain` is on at the domain controller. SMB signing is enforced. Extended Protection for Authentication is set on every IIS endpoint. ESC8 has been patched. The defender has read the [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/) post and ticked every box.
A low-privileged user on that network opens a PowerShell prompt. They run `Powermad` to create a fresh computer account. The default `MachineAccountQuota` is still `10`, which means any authenticated domain user can create up to ten computer objects in Active Directory by design [@shenanigans-rbcd]. They then write a single LDAP attribute, `msDS-AllowedToActOnBehalfOfOtherIdentity`, on a target file server they have any write permission against. They ask the Key Distribution Center for a service ticket via `Rubeus s4u`, present that ticket to the target file server, and walk in as `Administrator`. Total elapsed time: less than this paragraph. Total NTLM in the chain: zero.
> **Note:** The post-NTLM Resource-Based Constrained Delegation chain depends on three properties of Kerberos that are features, not bugs: (a) the default `MachineAccountQuota = 10` setting on every fresh Active Directory forest, (b) the S4U2Proxy guarantee that always produces a forwardable TGS even when the input ticket was not forwardable, and (c) the absence of any KDC-side check on whether the requesting principal is a "trusted delegator". All three are documented behaviours of the protocol. None of them is a CVE [@shenanigans-rbcd].
The chain has a name and a primary disclosure: Elad Shamir's "Wagging the Dog" post on shenaniganslabs.io, January 28, 2019 [@shenanigans-rbcd]. The weaponised tooling is GhostPack's Rubeus, the C# Kerberos toolset that ships ready-made commands for `s4u`, `asktgt`, `kerberoast`, and `diamond` [@ghostpack-rubeus]. The single-line elevation wrapper that splices together Powermad, KrbRelay, Rubeus, and an SCM bypass is `KrbRelayUp`, published by Mor Davidovich ("Dec0ne") on April 24, 2022; its README scopes itself as a universal no-fix local privilege escalation in Windows domain environments where LDAP signing is not enforced (and that is the default) [@krbrelayup].
sequenceDiagram
participant U as Low-priv user
participant DC as Domain Controller / KDC
participant T as Target file server
U->>DC: Powermad: create machine account FAKE$
U->>DC: LDAP write msDS-AllowedToActOnBehalfOfOtherIdentity on T to FAKE
U->>DC: AS-REQ for FAKE$ -> TGT
U->>DC: S4U2Self as Administrator (non-forwardable TGS returned)
U->>DC: S4U2Proxy with TGS returns forwardable TGS for cifs on T
U->>T: AP-REQ presenting Administrator TGS
T->>U: SYSTEM access on T
Read the chain twice. The first read shows that every step is a documented Kerberos exchange. The second read shows that *removing NTLM did nothing to it*. Restrict-NTLM, EPA, SMB signing, ESC8 -- the entire NTLM-retrofit catalogue has no edge against a Kerberos-only attack path that uses S4U2Self, S4U2Proxy, and the Resource-Based Constrained Delegation attribute exactly as Microsoft documented them in [@ms-kerberos-overview].
This is the article's load-bearing thesis. *Removing NTLM did not remove the attack surface; it shifted the attack surface onto a protocol that is also thirty-three years old, also retrofitted, and now also the only load-bearing one.* In October 2023, Matthew Palko, Microsoft's Principal Group Product Manager for Windows authentication, wrote the post that committed Microsoft publicly to deprecating NTLM and named the Kerberos features that would replace it [@ms-palko-evolution]. The NTLMless companion article walked through the NTLM-side mechanics of that transition. This one walks through the Kerberos side.
The question that drives everything that follows is the question the chain above forces: *how did Windows arrive at a state where the most catastrophic post-NTLM Active Directory attack chain depends on Kerberos working exactly as the 1989 designers intended?*
## 2. Origins: Needham, Schroeder, Athena, and 1988
Kerberos is not new engineering. The story of Windows authentication in 2026 starts with two Xerox PARC researchers and a 1978 paper in Communications of the ACM.
In December 1978, Roger M. Needham and Michael D. Schroeder published "Using Encryption for Authentication in Large Networks of Computers" in CACM 21(12), pages 993 to 999 [@needham-schroeder]. The paper is paywalled on the ACM Digital Library, but RFC 4120's own Background section names it as the parent protocol [@rfc4120] and the Wikipedia article on the Needham-Schroeder protocol preserves the message structure verbatim [@wiki-needham-schroeder]. The symmetric-key version of that protocol is five messages long, and it is the structural blueprint of every "ticket from a trusted third party" design that followed.
$$A \to S:\ A, B, N_A$$
$$S \to A:\ \{N_A, K_{AB}, B, \{K_{AB}, A\}_{K_{BS}}\}_{K_{AS}}$$
$$A \to B:\ \{K_{AB}, A\}_{K_{BS}}$$
$$B \to A:\ \{N_B\}_{K_{AB}}$$
$$A \to B:\ \{N_B - 1\}_{K_{AB}}$$
`A` and `B` are the principals; `S` is the trusted third party; `K_AS` and `K_BS` are pre-shared long-term keys; `K_AB` is the session key that `S` mints for the conversation; `N_A` and `N_B` are nonces. The "ticket" is the part of the third message that `A` cannot decrypt and just forwards to `B`. That structure -- a server-issued cryptographic envelope intended for somebody else and opaque to the carrier -- is what becomes the Kerberos TGS thirty-eight years later.
Three years later, in August 1981, Dorothy Denning and Giovanni Maria Sacco published "Timestamps in Key Distribution Protocols" in CACM 24(8), 533-536. The paper is also paywalled on dl.acm.org, but the Wikipedia secondary preserves the finding: the Needham-Schroeder symmetric protocol is vulnerable to a replay attack if an attacker recovers an old session key [@wiki-needham-schroeder]. Denning and Sacco proposed timestamps as the fix. This is the structural reason every Kerberos ticket carries a timestamp and every Kerberos network requires a synchronised time service today.
A Kerberos administrative boundary, written in uppercase like `CONTOSO.COM`, that scopes a set of principals (users, services, computers) sharing a single Key Distribution Center. Every Kerberos ticket names the issuing domain in its `EncTicketPart.crealm` and `EncTicketPart.cname` fields. Active Directory binds one Kerberos domain to one AD forest root by default [@ms-kerberos-overview].
Between 1983 and 1991, MIT Project Athena -- the joint MIT, DEC, and IBM campus computing effort led by Jerome Saltzer -- needed a working authentication service for a distributed workstation network running over a hostile campus LAN. The Athena Technical Plan Section E.2.1, "Kerberos Authentication and Authorization System" [@mit-athena-plan], is the canonical internal design document. Steve Miller and Clifford Neuman did the protocol work; Jeffrey Schiller ran the network operations.
In February 1988, MIT published two complementary artefacts. Bill Bryant wrote "Designing an Authentication System: a Dialogue in Four Scenes" -- a pedagogical script in which an engineer named Athena designs her way step by step from "users type their password to every server" to "users obtain time-limited tickets from a trusted third party". Bryant's dialogue is the most cited pre-protocol document about why Kerberos exists in the shape it does [@mit-dialogue]. The same month, Jennifer Steiner, Clifford Neuman, and Jeffrey Schiller presented "Kerberos: An Authentication Service for Open Network Systems" at the USENIX Winter Conference in Dallas [@cerias-steiner1988]. The protocol that paper described -- later called Kerberos version 4 -- carried forward to v5 with ASN.1 encoding, extensibility hooks, and pre-authentication, but the AS / TGS / AP message-triple skeleton it specified is unchanged thirty-eight years later.
On January 24, 1989, MIT shipped the first public release of Kerberos v4 [@wiki-kerberos]. Five years later, in September 1993, the IETF adopted Kerberos v5 as RFC 1510 [@rfc1510]. RFC 1510 added ASN.1 encoding, cross-domain trust, and an extensibility hook called PA-DATA that every Kerberos extension since has used. In July 2005, RFC 4120 replaced RFC 1510 as the Kerberos v5 standard [@rfc4120].
sequenceDiagram
participant C as Client
participant AS as Authentication Service
participant TGS as Ticket-Granting Service
participant S as Application Server
C->>AS: AS-REQ: identify yourself
AS->>C: AS-REP TGT encrypted to TGS, session key wrapped under client long-term key
C->>TGS: TGS-REQ: present TGT, ask for service ticket
TGS->>C: TGS-REP service ticket encrypted to S, session key wrapped under TGT session key
C->>S: AP-REQ: present service ticket
S->>C: AP-REP: mutual auth confirmation
Kerberos in 2026 is the same protocol as Kerberos in 1988, with thirty-three years of extensions piled on top. The skeleton you draw on a whiteboard for a graduate seminar is exactly the skeleton a Windows 11 24H2 machine throws at a 2025 domain controller. The interesting question is what those thirty-three years of extensions did to the inside of every message.The default maximum clock skew between client and KDC in Windows Kerberos is five minutes (300 seconds), set by Group Policy "Maximum tolerance for computer clock synchronization" and documented in [@ms-kerberos-overview]. The five-minute window is the residue of Denning and Sacco's 1981 timestamp fix.
## 3. The Wire in 2026: Six Messages and an Encryption Matrix
Every Kerberos textbook draws the same six-message diagram you saw in Section 2. The diagram has been unchanged since 1988. What is different in 2026 is everything inside the messages.
Look first at the AS-REQ. In raw RFC 4120 the AS-REQ carries a `req-body` (client name, target name, requested lifetime, requested enctypes) and an optional `padata` field [@rfc4120]. That `padata` slot is the load-bearing extensibility hook of the entire protocol. Every Kerberos enhancement since 1993 has been a new PA-DATA type: `PA-ENC-TIMESTAMP` (the encrypted-timestamp pre-auth blob), `PA-PK-AS-REQ` (PKINIT [@rfc4556]), `PA-FX-FAST-REQUEST` (FAST armoring [@rfc6113]), `PA-AS-FRESHNESS` (PKINIT freshness [@rfc8070]). The skeleton survives only because the joints are extensible.
A `SEQUENCE OF { padata-type, padata-value }` field in the Kerberos AS-REQ and AS-REP messages, introduced in RFC 1510 (1993) and carried forward unchanged into RFC 4120 §5.2.7 (2005). PA-DATA is the only protocol-level hook by which a Kerberos client can prove possession of a credential before the KDC issues a Ticket-Granting Ticket, and the only hook by which an enhancement like FAST or PKINIT can attach new behaviour to the AS exchange without breaking compatibility with older clients [@rfc4120].
The AS-REP returns the TGT. The TGT itself is encrypted under the TGS's long-term key, so the client cannot inspect it. What the client *can* inspect is the `EncTicketPart` flag bitfield wrapped in the TGT envelope. RFC 4120 §2 enumerates the ticket-flag positions, including `forwardable`, `proxiable`, `postdated`, `renewable`, `initial`, `pre-authent`, `hw-authent`, `transited-policy-checked`, and `ok-as-delegate` [@rfc4120]. (`may-postdate` looks like a sibling but is a `KDCOptions` request bit per RFC 4120 §5.4.1, not a `TicketFlags` bit.) Pay attention to `forwardable`. In 2020, Jake Karnes of NetSPI demonstrated that an attacker who knew a service account's long-term key could decrypt the S4U2Self output ticket, set `forwardable = 1`, re-encrypt, and feed the ticket back to the KDC's S4U2Proxy step. The KDC accepted it. The bypass is CVE-2020-17049 and the attack is called Bronze Bit [@cve-2020-17049] [@netspi-bronze-bit].
Inside the ticket's `AuthorizationData` field is the Microsoft-specific construction that turns Kerberos into a Windows authorisation system. The Privilege Attribute Certificate, defined in [MS-PAC] revision 26.0 [@ms-pac-overview] [@ms-pac-deeplink], carries the user's SID, their group SIDs, their logon name, timestamps, and three cryptographic signatures: a Server signature, a KDC signature, and -- since CVE-2022-37967 in November 2022 -- a Full PAC Signature that covers the entire encoded PAC structure instead of just the existing signatures [@cve-2022-37967].
A Microsoft-specific authorization data element that the Kerberos KDC attaches to every ticket it issues for a Windows principal. The PAC carries the user's SID, group SIDs, logon name, and timestamps, and is signed by the KDC's `krbtgt` key and by the target service's key. The PAC, not the Kerberos ticket itself, is what gives a Windows file server the access-control information it needs to make a permission decision. Defined in [MS-PAC] [@ms-pac-overview].
Then there is the encryption matrix. Kerberos abstracts ciphers behind the RFC 3961 framework [@rfc3961], which defines an enctype as a tuple of (encrypt, decrypt, checksum, string-to-key, key-derivation) functions. The history of Windows Kerberos is the history of which enctypes were the default at any given time.
| Enctype | Number | Spec | Status in 2026 |
|---------|--------|------|----------------|
| DES-CBC-CRC | 1 | RFC 3961 [@rfc3961] | Disabled by default since Server 2008 R2 [@ms-kile-227] |
| DES-CBC-MD5 | 3 | RFC 3961 [@rfc3961] | Disabled by default since Server 2008 R2 [@ms-kile-227] |
| RC4-HMAC | 23 | RFC 4757 [@rfc4757] | Informational, not Standards Track; default-removed in mid-2026 per [@ms-beyond-rc4] |
| AES-128-CTS-HMAC-SHA1-96 | 17 | RFC 3962 [@rfc3962] | Default since Server 2008; cross-version compatible |
| AES-256-CTS-HMAC-SHA1-96 | 18 | RFC 3962 [@rfc3962] | Default since Server 2008; the mid-2026 destination |
| AES-128-CTS-HMAC-SHA256-128 | 19 | RFC 8009 [@rfc8009] | Specified in [MS-KILE] bit K [@ms-kile-227]; no default-enable timeline |
| AES-256-CTS-HMAC-SHA384-192 | 20 | RFC 8009 [@rfc8009] | Specified in [MS-KILE] bit L [@ms-kile-227]; no default-enable timeline |
Enctype 23 is the row that built every Kerberoasting career. Kannan Jaganathan, Larry Zhu, and John Brezak of Microsoft published RFC 4757 in December 2006 [@rfc4757]. The IESG note on the RFC is unusually candid: the document is *Informational*, not Standards Track, because RC4-HMAC "do[es] not provide all the required operations in the Kerberos cryptography framework [RFC 3961]" and because of "security concerns with the use of RC4 and MD4". The choice that made enctype 23 dangerous, however, was upstream of the RFC. To make Windows 2000's Kerberos rollout backward-compatible with the existing SAM password database, Microsoft set the RC4-HMAC long-term Kerberos key equal to the *NT hash of the user's password* -- the same hash NTLM was already storing. As Microsoft's own October 2024 Kerberoasting guidance puts it verbatim: "RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key" [@ms-kerberoasting-guidance].
The function that converts a typed password into a Kerberos long-term symmetric key. For RC4-HMAC (enctype 23), `s2k(password) = MD4(UTF-16-LE(password))` -- the NT hash, no salt, no iteration. For AES-CTS-HMAC-SHA1-96 (enctypes 17 and 18), `s2k(password, salt) = PBKDF2-HMAC-SHA1(password, salt, 4096, dklen)` followed by RFC 3962 post-processing into a 128- or 256-bit AES key. The salt is the concatenation of the Kerberos domain name and the user principal name [@rfc3962].
The cryptography in that definition is short enough to read end-to-end. Here it is in JavaScript using the Web Crypto API:
{`
async function kerberosStringToKey256(password, salt) {
const enc = new TextEncoder();
const passKey = await crypto.subtle.importKey(
"raw",
enc.encode(password),
{ name: "PBKDF2" },
false,
["deriveBits"]
);
const rawBits = await crypto.subtle.deriveBits(
{
name: "PBKDF2",
salt: enc.encode(salt),
iterations: 4096,
hash: "SHA-1",
},
passKey,
256
);
const hex = [...new Uint8Array(rawBits)]
.map((b) => b.toString(16).padStart(2, "0"))
.join("");
return hex;
}
const password = "Summer2026!";
const salt = "CONTOSO.COMalice";
const keyHex = await kerberosStringToKey256(password, salt);
console.log("PBKDF2-HMAC-SHA1 output (truncated AES-256 key):", keyHex);
`}
That 32-byte output is the value LSA stores when an account is configured with `msDS-SupportedEncryptionTypes` bit E set. When a Kerberoasting attacker steals the TGS-REP, what they crack offline is which password produces that key. The RFC 3962 post-processing -- a single round of `DK(key, "kerberos")` -- shapes the output to AES key length but does not slow the dictionary attack down. The dispositive defence is not in the cryptography; it is in the password (or, more precisely, in not having one at all -- the move to gMSA and dMSA replaces typed passwords with KDC-generated random secrets [@ms-gmsa] [@ms-dmsa]).
PBKDF2 at 4,096 iterations is well below modern PHC recommendations -- the 2023 OWASP guideline for PBKDF2-HMAC-SHA1 is 1.3 million iterations [@owasp-password-storage] -- but the 4,096 figure is wired into RFC 3962 and is the same on every supported Windows version. Service accounts using gMSA bypass this entirely: the gMSA's "password" is a 240-character random secret rotated every 30 days, derived by the Microsoft Key Distribution Service rather than entered by a human [@ms-gmsa].
The wire in 2026 is therefore six messages and a matrix of seven enctypes. The protocol skeleton is forty years old. In 2014 a SANS instructor named Tim Medin gave a forty-five-minute talk that turned every one of those enctypes into a problem.
## 4. The Attack Cascade: 2014 to 2022
September 26-28, 2014. Louisville, Kentucky. DerbyCon 4. Talk slot T120. Tim Medin -- then at Counter Hack Challenges, also a SANS instructor -- walks on stage with a forty-five-minute talk titled "Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades" [@irongeek-derbycon4]. The talk demonstrates that any authenticated domain user can request a TGS for any Service Principal Name in the directory, and that the service-portion of the returned ticket is encrypted under the SPN account's long-term key -- which, under RC4-HMAC enctype 23, is the NT hash of the password. Cracking the ciphertext is reduced to a dictionary attack against whatever password an admin set on the service account.
That talk is the moment Kerberos becomes interesting to attackers. The next eight years play out as a cascade. Five generations, each one named after the canonical primitive that defined it, each one exposing a different structural property of the protocol, each one earning its own engineered Microsoft response years later.
A unique identifier for a service instance in Active Directory, written in the form `service-class/host:port/service-name` (for example `HTTP/web01.contoso.com`). Kerberos uses the SPN to look up which account holds the long-term key that decrypts the service ticket. Any account that has an SPN -- a user account that has had `setspn -A` run against it, every machine account in the directory, every gMSA -- is a candidate for Kerberoasting [@adsecurity-kerberoast].
### Generation 1, 2014: Kerberoasting
Tim Medin's primitive [@irongeek-derbycon4]. Will Schroeder's PowerShell weaponisation as `Invoke-Kerberoast` (later rolled into the C# Rubeus) [@ghostpack-rubeus]. Sean Metcalf's operational walkthrough on adsecurity.org [@adsecurity-kerberoast]. MITRE catalogued the technique in 2020 as ATT&CK T1558.003, which preserves the structural definition verbatim: "Portions of these tickets may be encrypted with the RC4 algorithm, meaning the Kerberos 5 TGS-REP etype 23 hash of the service account associated with the SPN is used as the private key and is thus vulnerable to offline Brute Force attacks" [@mitre-t1558-003].
The structural insight is the part that matters. The TGS-REP is encrypted with the service account's *long-term* password-derived key, so any domain user who can issue a TGS-REQ can mine ciphertext offline against any dictionary they care to assemble. The Kerberos protocol has no mechanism by which the KDC could tell whether the requesting user has any business asking for that SPN, because RFC 4120 has no concept of "this service is for these users". Anyone with a TGT gets the service ticket.
Microsoft's engineered response did not arrive until ten to twelve years later. Server 2012 introduced Group Managed Service Accounts: passwords randomised to 240 characters, derived by the Microsoft Key Distribution Service via `kdssvc.dll`, rotated every 30 days, retrievable from a domain controller by member hosts that are explicitly authorised in `msDS-GroupMSAMembership` [@ms-gmsa]. Server 2025 then introduced Delegated Managed Service Accounts (dMSA), which take the next structural step: the dMSA's secret is "derived from the machine account credential" held by the domain controller, and "the secret can't be retrieved or found anywhere other than on the DC" [@ms-dmsa]. The October 2024 Microsoft Security Blog formalised the Kerberoasting guidance in a single page that names RC4 as the load-bearing weakness and announces the deprecation [@ms-kerberoasting-guidance]. The December 2025 Beyond-RC4 announcement closed the cadence with a calendar date [@ms-beyond-rc4].
### Generation 2, 2014-2017: Mimikatz Kerberos and AS-REP Roasting
Benjamin Delpy publishes `mimikatz` 2.0 on April 6, 2014; the v2 banner inside the repository README reads verbatim `mimikatz 2.0 alpha (x86) release "Kiwi en C" (Apr 6 2014 22:02:03)` [@mimikatz]. The Kerberos module contains two commands that define the era: `kerberos::golden` (forge a TGT from the KRBTGT account's long-term key, granting Domain Admin equivalence indefinitely) and `kerberos::silver` (forge a TGS from any service account's long-term key, granting impersonation of any user against that service).
The structural insight: RFC 4120 has no online ticket validation [@rfc4120]. Once a ticket carries the right signatures, the service trusts it. Whoever holds a long-term key forges any ticket that key signs. Possession of a key collapses to ticket forgeability.
Around 2017, the same team behind Rubeus publicises AS-REP Roasting [@ghostpack-rubeus]: the same offline-cracking primitive as Kerberoasting, but against any account whose `userAccountControl` has `UF_DONT_REQUIRE_PREAUTH` (the `DONT_REQ_PREAUTH` flag) set. With pre-authentication disabled, the KDC will return an AS-REP encrypted under the user's password-derived key to *anyone* who asks for it, no proof of password possession required. The dispositive Microsoft response was already in place: pre-authentication has been required by default for all new Active Directory accounts since Windows 2000, and the flag has to be deliberately cleared by an administrator. The remaining vulnerability is operational hygiene -- finding the handful of legacy accounts an organisation has left with pre-auth disabled.
### Generation 3, 2018-2020: Delegation Abuse
Three primitives in three years.
**SpoolSample / PrinterBug.** Lee Christensen (tifkin_, SpecterOps) published the PoC on GitHub on October 5, 2018 [@spoolsample]. The MS-RPRN remote-procedure-call interface includes a method, `RpcRemoteFindFirstPrinterChangeNotificationEx`, that any authenticated user can invoke against any host's spooler service to ask the spooler to *please call back* to an attacker-controlled address. The spooler obediently authenticates outbound using the machine account's credentials. Combined with unconstrained Kerberos delegation on the attacker-controlled host, the inbound authentication captures the target machine's TGT.
**Wagging the Dog (RBCD).** Elad Shamir's January 28, 2019 post on shenaniganslabs.io [@shenanigans-rbcd]. The TL;DR of the post is the load-bearing structural disclosure: "Resource-based constrained delegation does not require a forwardable TGS when invoking S4U2Proxy. S4U2Self works on any account that has an SPN, regardless of the state of the TrustedToAuthForDelegation attribute. S4U2Proxy always produces a forwardable TGS, even if the provided additional TGS in the request was not forwardable. By default, any domain user can abuse the MachineAccountQuota to create a computer account and set an SPN for it, which makes it even more trivial to abuse resource-based constrained delegation to mimic protocol transition" [@shenanigans-rbcd]. Every clause of that TL;DR points at a documented behaviour. The chain in this article's Hook is built directly on top.
**Bronze Bit.** Jake Karnes at NetSPI; CVE-2020-17049; disclosed November 10, 2020 [@netspi-bronze-bit] [@cve-2020-17049]. The NVD entry preserves Microsoft's verbatim description: "A security feature bypass vulnerability exists in the way Key Distribution Center (KDC) determines if a service ticket can be used for delegation via Kerberos Constrained Delegation (KCD). To exploit the vulnerability, a compromised service that is configured to use KCD could tamper with a service ticket that is not valid for delegation to force the KDC to accept it" [@cve-2020-17049]. The bypass: any service in possession of its own long-term key can decrypt the S4U2Self output ticket, flip the `forwardable` bit in `EncTicketPart`, and re-encrypt with the same key. Pre-2020 the KDC's S4U2Proxy validation accepted the resulting ticket because nothing on the ticket independently attested whether the `forwardable` flag had been set by the KDC or by the service itself. Microsoft's November 10, 2020 fix, per the NVD entry verbatim, "addresses this vulnerability by changing how the KDC validates service tickets used with KCD" so that the tampered flag is rejected [@cve-2020-17049]. The PAC signatures, contra a common framing, were never meant to cover the `EncTicketPart` flag bits in the first place.
Microsoft's engineered responses: the November 2020 Bronze Bit patch [@cve-2020-17049] tightened the KDC's S4U2Proxy ticket-validation step; KB5008383 (November 2021) [@ms-kb-5008383] issued the canonical "set `ms-DS-MachineAccountQuota = 0` for non-administrator users" guidance; LDAP signing and channel binding work, ongoing since the [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/) era, became the dispositive control against the relay variant of the chain.
### Generation 4, 2021-2022: Certificate-Based Ticket Forgery and Kerberos Relay
**Certifried.** Oleg Tsarev and Yaron Zinar disclosed CVE-2022-26923 to Microsoft, who patched on May 10, 2022 [@cve-2022-26923]. The attack exploited a quirk of how Active Directory Certificate Services (ADCS) bound a certificate's identity to an AD account when the certificate was used for PKINIT. Before the strong-mapping fix, AD's account-lookup at PKINIT time used the certificate's Subject Alternative Name (SAN) and matched the User Principal Name. If an attacker controlled a machine account, they could change the machine's `dNSHostName` to match a domain controller's, request a certificate via the (overly-permissive) default `Machine` template, and use the resulting certificate to PKINIT-authenticate to the KDC as that domain controller. Microsoft's response is documented end-to-end in KB5014754 [@ms-kb-5014754]: a new "strong certificate mapping" requirement that pins each issued certificate to a specific account SID via an X.509 extension (OID 1.3.6.1.4.1.311.25.2). The original release moved to Compatibility mode on May 10, 2022; full Enforcement mode took effect on February 11, 2025; the registry-key fallback that allowed administrators to roll back to Disabled mode was removed on September 9, 2025 [@ms-kb-5014754].
**KrbRelayUp.** Mor Davidovich (`Dec0ne`), April 24, 2022 [@krbrelayup]. The README's universal-no-fix-LPE framing is preserved in the PullQuote below. The chain wraps `Powermad` (machine account creation), `KrbRelay` (Kerberos relay to LDAP), Rubeus (S4U2Self bypass of Protected Users, RBCD privilege addition), and `SCMUACBypass` (a wrapper that uses the resulting ticket to open the local Service Control Manager and create a service running as `NT AUTHORITY\SYSTEM`). The class of attack is "Kerberos relay" -- the post-NTLM cousin of NTLM-relay. The dispositive control is not a Kerberos patch; it is domain-wide LDAP signing plus channel binding plus Extended Protection for Authentication on ADCS Web Enrolment.
"A universal no-fix local privilege escalation in windows domain environments where LDAP signing is not enforced (the default settings)." -- Mor Davidovich, KrbRelayUp README, April 2022 [@krbrelayup]
### Generation 5, 2022-2023: Forged-Ticket Sophistication
**Diamond Ticket.** Charlie Clark at Semperis co-authored a blog post in 2022 with Andrew Schwartz at TrustedSec disclosing the modern Diamond Ticket technique [@semperis-diamond] [@trustedsec-diamond]. The Semperis byline names the antecedent: a 2015 Black Hat EU presentation by Tal Be'ery and Michael Cherny ("Watching the Watchdog") that introduced the "Diamond PAC" idea. Verbatim from the Semperis post: "Golden Ticket attacks take advantage of the ability to forge a ticket granting ticket (TGT) from scratch, Diamond Ticket attacks take advantage of the ability to decrypt and re-encrypt genuine TGTs requested from a domain controller (DC)" [@semperis-diamond]. The structural insight is that a Diamond Ticket has a *legitimately issued, KDC-signed* PAC at its base; only the privilege-claim fields inside the PAC are tampered. Before the November 2022 Full PAC Signature fix, the existing Server and KDC signatures only covered specific sub-structures, leaving room to modify the parts they did not sign.
**Sapphire Ticket.** Charlie Bromberg, also known online as "Shutdown", at Synacktiv [@pgj11-diamond-sapphire] [@thehacker-recipes-sapphire]. The community wiki The Hacker Recipes, which Bromberg maintains, documents the Sapphire Ticket technique end-to-end at `thehacker.recipes/a-d/movement/kerberos/forged-tickets/sapphire` [@thehacker-recipes-sapphire]. The verifiable third-party attribution lives at pgj11.com, which records verbatim: "One brand new technique is Sapphire Ticket. Created by Charlie Shutdown (twitter.com/_nwodtuhs) this approach is more stealthy. You can create a TGT impersonating any user assembling real TGT and real PAC combining S4U2Self + U2U ... He extended Ticketer from Impacket to add this attack" [@pgj11-diamond-sapphire]. The Sapphire Ticket bolts a *legitimately KDC-issued* PAC (obtained by chaining the S4U2Self and User-to-User Kerberos extensions to request a service ticket *to oneself* with the PAC of an arbitrary target user) onto a Diamond-style ticket. The result presents PAC signatures that the KDC itself produced. Unit 42's December 2022 "Next-Gen Kerberos Attacks" writeup is the secondary that joined Diamond and Sapphire into the same article and named them collectively the "Precious Gemstones" [@unit42-precious-gemstones].
Some secondary sources attribute Sapphire Ticket to Charlie Clark of Semperis. The misattribution probably stems from Clark's separate "AS Requested STs" post on the Semperis blog, which discusses a different technique exploiting unarmored machine-account AS-REQs and is not the Sapphire Ticket primary [@semperis-as-sts]. The verified Sapphire-Ticket originator is Charlie Bromberg (Shutdown, Synacktiv) per [@pgj11-diamond-sapphire].The adsecurity.org URL `?p=2293` is Sean Metcalf's "Cracking Kerberos TGS Tickets Using Kerberoast -- Exploiting Kerberos to Compromise the Active Directory Domain" (not Metcalf's separate KRBTGT-account post, which lives at a different URL). The page is the operational walkthrough that pairs with Tim Medin's 2014 DerbyCon disclosure [@adsecurity-kerberoast].
Microsoft's engineered response to both Diamond and Sapphire was CVE-2022-37967, the KrbtgtFullPacSignature [@cve-2022-37967] [@ms-kb-5021131]. It is the first PAC-handling protocol change since Windows 2000's introduction of the PAC. After full enforcement, the KDC adds a *Full PAC Signature* that covers the entire encoded PAC, not just the existing sub-signatures. Diamond and Sapphire variants that modify any PAC field beyond what the Server and KDC sub-signatures already covered will fail validation.
"The accounts most vulnerable to Kerberoasting are those with weak passwords and those that use weaker encryption algorithms, especially RC4. RC4 is more susceptible to the cyberattack because it uses no salt or iterated hash when converting a password to an encryption key, allowing the cyberthreat actor to guess more passwords quickly." -- Microsoft Security Blog, October 11, 2024 [@ms-kerberoasting-guidance]
### The Spine Table
| Generation | Year | Primitive | Structural Insight | Microsoft Response |
|------------|------|-----------|--------------------|--------------------|
| 1 | 2014 | Kerberoasting [@irongeek-derbycon4] | TGS-REP is encrypted with the SPN account's long-term key; offline-crackable | gMSA (2012) [@ms-gmsa]; dMSA (2025) [@ms-dmsa]; Beyond-RC4 (2025-2026) [@ms-beyond-rc4] |
| 2 | 2014-2017 | Golden / Silver Ticket [@mimikatz]; AS-REP Roasting [@ghostpack-rubeus] | RFC 4120 has no online ticket validation [@rfc4120]; long-term key = forge equivalence | KrbtgtFullPacSignature (2022) [@cve-2022-37967]; preauth-required default since Windows 2000 |
| 3 | 2018-2020 | SpoolSample [@spoolsample]; RBCD [@shenanigans-rbcd]; Bronze Bit [@cve-2020-17049] | MS-RPRN coercion; S4U2Proxy always returns forwardable; pre-2020 KDC did not independently validate the EncTicketPart flags | Bronze Bit patch (Nov 2020); KB5008383 MachineAccountQuota=0 (Nov 2021); LDAP signing |
| 4 | 2022 | Certifried [@cve-2022-26923]; KrbRelayUp [@krbrelayup] | ADCS template SAN-binding ambiguity; LDAP defaults unsigned | KB5014754 strong-mapping [@ms-kb-5014754]; LDAP signing + EPA on /certsrv/ |
| 5 | 2022 | Diamond [@semperis-diamond]; Sapphire [@pgj11-diamond-sapphire] [@unit42-precious-gemstones] | PAC sub-signatures did not cover the encoded PAC structure | KrbtgtFullPacSignature (CVE-2022-37967, Nov 2022) [@cve-2022-37967] |
timeline
title Kerberos attack cascade
section 2014
Sep 2014 : Kerberoasting (Tim Medin, DerbyCon 4)
Apr 2014 : Mimikatz 2.0 (Golden / Silver Tickets)
section 2017
2017 : AS-REP Roasting (Rubeus weaponisation)
section 2018-2020
Oct 2018 : SpoolSample (PrinterBug, Lee Christensen)
Jan 2019 : Wagging the Dog / RBCD (Elad Shamir)
Nov 2020 : Bronze Bit (Jake Karnes, NetSPI)
section 2022
Apr 2022 : KrbRelayUp (Mor Davidovich)
May 2022 : Certifried (Tsarev / Zinar)
2022 : Diamond Ticket (Clark / Schwartz)
2022 : Sapphire Ticket (Charlie Bromberg)
Nov 2022 : KrbtgtFullPacSignature (Microsoft fix)
Eight years. Eleven structural primitives. One protocol. By 2022 the cascade slowed, not because the protocol got better, but because every primitive a thirty-three-year-old design *could* expose had been exposed. The 2022 Microsoft response, KrbtgtFullPacSignature, was the first one that targeted the *structural* properties (PAC coverage of its own structure) rather than the per-primitive patches that defined the 2014-2020 era. To see why that was a turning point, it helps to see exactly what the defensive cadence looked like before then.
## 5. The Defensive Cadence Before 2023
Each of the eleven primitives in Section 4 shipped with a fix. By 2022 every named primitive *had* a fix. And yet the cascade kept producing new primitives. Why?
The answer is in the shape of the defensive controls. Walk them in chronological order.
**Protected Users (Server 2012 R2, October 2013) [@ms-server-2012-r2].** A new security group that triggers five non-configurable client-side protections and four non-configurable domain-controller-side protections [@ms-protected-users]. The client side: CredSSP "doesn't cache the user's plain text credentials"; Windows Digest "doesn't cache the user's plaintext credentials"; "NTLM stops caching the user's plaintext credentials or NT one-way function (NTOWF)"; "Kerberos stops creating Data Encryption Standard (DES) or RC4 keys ... or long-term keys after acquiring the initial Ticket Granting Ticket (TGT)"; "The system doesn't create a cached verifier at user sign-in or unlock" [@ms-protected-users]. The domain-controller side, also verbatim: members "cannot authenticate with NTLM authentication ... use DES or RC4 encryption types in Kerberos preauthentication ... delegate with unconstrained or constrained delegation ... renew Kerberos TGTs beyond their initial four-hour lifetime" [@ms-protected-users]. The limit is the obvious one: Protected Users breaks every workflow that relied on delegation, RC4, or NTLM, and there are many such workflows still in production.
**Authentication Policy Silos (Server 2012 R2).** A scope construct that lets administrators apply Protected-Users-equivalent constraints (no RC4, no unconstrained delegation, mandatory FAST) to tiered subsets of an organisation rather than per-account. The standard tier-zero / tier-one / tier-two split fits neatly under three silos [@ms-privileged-access].
A container of users, computers, and managed service accounts in Active Directory that scopes a single authentication policy. Members can be required to authenticate only from designated hosts, must use AES enctypes, may be excluded from delegation, and (when paired with FAST armoring) sign their AS-REQ inside a machine-account or anonymous-PKINIT armor. Available since Server 2012 R2; the operational granularity that Protected Users does not provide on its own [@ms-protected-users].
**Restricted Admin (2014) and Remote Credential Guard (2016) [@ms-remote-credential-guard].** The RDP-side companions that block credential exposure on the target host. Both work by changing what gets sent on the wire during a remote sign-in: Restricted Admin (Windows 8.1 / Server 2012 R2 era) uses the user's TGT to authenticate via Kerberos network logon, so no credentials reach the target; Remote Credential Guard (Windows 10 1607, August 2016) performs the same trick but for interactive sessions, redirecting CredSSP back to the originating workstation [@ms-remote-credential-guard].
**Credential Guard (Windows 10 RTM, 2015) [@ms-credential-guard].** Virtualization-Based-Security-isolated LSASS: secrets that LSASS would otherwise hold in user-mode memory are moved into the LSAISO trustlet running in Virtual Trust Level 1. SYSTEM on the box cannot read VTL1 memory. Credential Guard is the ceiling against memory-side ticket and key theft, and is one of the cross-link points to the [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/) companion article.
**FAST armoring (RFC 6113, April 2011).** Sam Hartman and Larry Zhu's "A Generalized Framework for Kerberos Pre-Authentication" defines the FAST (Flexible Authentication Secure Tunneling) channel [@rfc6113]. The AS-REQ is wrapped in an outer armor envelope, keyed under the machine account's TGT (for a domain-joined client), an anonymous PKINIT TGT (for a non-domain-joined client), or a compound identity. The armor envelope encrypts the PA-ENC-TIMESTAMP blob and authenticates the entire request, closing the offline-cracking path that targets the encrypted-timestamp pre-auth. The limit: FAST is client opt-in, not on by default, and Server 2012 R2 domain functional level is the floor for compound identity. Many production environments still do not require FAST on their tier-zero accounts.
**gMSA (Server 2012).** The dispositive Kerberoasting defence for service accounts [@ms-gmsa]. The Microsoft Key Distribution Service (`kdssvc.dll`) computes a 240-character random password, rotated every 30 days, and member hosts authorised in `msDS-GroupMSAMembership` can retrieve it from a domain controller. The decisive property that gMSA closes is the human-typed-password assumption: there is no password to remember, write down, or share.
**LDAP signing and channel binding.** The dispositive KrbRelayUp defence. Set `LDAPServerIntegrity = 2` to require signing on every LDAP bind, and `LdapEnforceChannelBinding = 2` to require channel binding on TLS-bound LDAP connections. Both are off by default in older domain functional levels, which is exactly the default the [@krbrelayup] README is targeting when it calls itself "no-fix".
**KrbtgtFullPacSignature (November 2022).** The first PAC-handling protocol change since Windows 2000's introduction of the PAC. After full enforcement, every PAC carries an additional Full PAC Signature covering the entire encoded structure, not just sub-pieces; Diamond and Sapphire variants that previously evaded validation by tampering with un-covered fields now fail [@cve-2022-37967] [@ms-kb-5021131].
**MachineAccountQuota = 0 guidance (KB5008383, November 2021) [@ms-kb-5008383].** The dispositive RBCD defence as a configuration: setting the directory-wide `ms-DS-MachineAccountQuota` attribute on the domain root to zero prevents non-administrative users from creating computer accounts at all, which kills the first step of the chain in Section 1's Hook.
> **Key idea:** Each defensive control patches a primitive. No control patches the structural property of the protocol -- that any long-term symmetric key is forge-equivalent for every ticket type that key signs, and that the protocol's offline-validation guarantee makes online ticket revocation incompatible with the design.
| Defence | Target Primitive | Structural Limit |
|---------|-----------------|------------------|
| Protected Users [@ms-protected-users] | Pass-the-Hash, Pass-the-Ticket, RC4 pre-auth | Breaks delegation, RC4, and NTLM; four-hour TGT cap may break legacy apps |
| Authentication Policy Silo [@ms-protected-users] | Per-tier scope of Protected-Users behaviour | Requires Server 2012 R2 DFL; FAST armoring requires Server 2012 R2 too |
| Credential Guard | LSASS memory theft (Mimikatz `sekurlsa::`) | Does not prevent ticket theft via legitimate Kerberos APIs |
| FAST (RFC 6113) [@rfc6113] | PA-ENC-TIMESTAMP offline cracking | Client opt-in; not on by default |
| gMSA [@ms-gmsa] | Kerberoasting on service accounts | Human-managed service accounts unaffected |
| LDAP signing + channel binding | KrbRelayUp [@krbrelayup] | Off by default in older domains |
| KrbtgtFullPacSignature [@cve-2022-37967] | Diamond and most Sapphire variants | Does not stop Sapphire variants whose tampered PAC was issued legitimately |
| MachineAccountQuota = 0 | RBCD chain [@shenanigans-rbcd] | Default value is `10`; setting requires admin action |
Read the table the way an attacker reads it. Each row is necessary; no row is sufficient. The "structural limit" column is the next-attack catalogue. Protected Users does not stop a Diamond Ticket forged from a stolen KRBTGT key. Credential Guard does not stop the operator who has SYSTEM on a domain controller. FAST does not stop AS-REP Roasting (because AS-REP Roasting only happens on accounts with pre-auth disabled, where FAST is moot). gMSA does not protect a service account someone still manages manually with a Notes-saved password.
The pattern is the answer to the section's opening question. Every control attacks one primitive -- a key, a flag, a coercion path, a ticket lifetime -- and none of them closes *the* protocol-level structural property that any long-term symmetric key in the domain is forge-equivalent for any ticket type that key signs. By 2022 the engineering catalogue was complete. The 2023 announcement was the first plan that targeted the structure.
What would a structural fix even look like, given that any "online revocation" change would also give up Kerberos's O(1) service-side validation, and given that any "deprecate the long-term key" change has to back-compat to clients that have not been touched since Server 2008? The October 2023 Palko post had answers.
## 6. The Breakthrough: Closing the Domainless Gap
October 11, 2023. Matthew Palko, Microsoft's Principal Group Product Manager for Windows authentication, publishes "The evolution of Windows authentication" on the Windows IT Pro Blog. The article's `` reads `2023-11-11T01:30:49.108-08:00` in the raw HTML; the description metadata reads "Discover how we're securing authentication and reducing NTLM usage in Windows" [@ms-palko-evolution]. It is the first time Microsoft commits publicly to deprecating NTLM, and the first time Microsoft names the three load-bearing engineering features that move Kerberos from "domain-only" to "load-bearing-for-everything".
The plan has four moving parts. Each one closes a specific reason that NTLM survived for thirty years.
### IAKerb: Kerberos without KDC line-of-sight
The structural reason NTLM lived through Server 2003, Server 2008, Server 2012, and Server 2019 is that Windows had no Kerberos-equivalent path for the case where a client cannot reach a KDC. A laptop on a hotel network, a hybrid Azure-joined workstation that can reach the application server but not the AD DC, a workgroup machine attempting to access a domain file share -- all of those flowed back to NTLM by default, because Kerberos required a working AS-REQ to the domain controller before it could mint a TGT.
IAKerb (Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API) closes that gap. The draft IETF specification, draft-ietf-kitten-iakerb, is by Benjamin Kaduk, Jim Schaad, Larry Zhu, and Jeffrey E. Altman [@iakerb-draft]. The mechanism is GSS-API encapsulation: the client wraps each AS-REQ, AS-REP, TGS-REQ, and TGS-REP message inside a GSS-API token addressed to the application server, and the application server proxies the token to the KDC the server *can* reach. From the client's perspective, it is talking to the application server; from the KDC's perspective, the AS exchange came from the application server. The protocol's verbatim problem statement reads: "encapsulating the Kerberos messages inside GSS-API tokens. With these extensions a client can obtain Kerberos tickets for services where the KDC is not accessible to the client, but is accessible to the application server" [@iakerb-draft].
Initial and Pass Through Authentication Using Kerberos V5 and the GSS-API. An extension to GSS-API Kerberos (RFC 4121) that encapsulates Kerberos AS / TGS exchanges inside GSS-API tokens between client and application server, so the application server can proxy them to a KDC the server can reach but the client cannot. Documented in the IETF draft `draft-ietf-kitten-iakerb` by Kaduk, Schaad, Zhu, and Altman [@iakerb-draft].
A Kerberos Key Distribution Center implemented as an in-process service inside the local Windows Security Authority (LSASS) on a workgroup or Azure-joined machine. The Local KDC issues tickets backed by the local SAM password database, exposing no Kerberos port to the network; clients reach it only through IAKerb encapsulation tunnelled through the application protocol. Closes the "local account auth has no KDC" gap that has kept NTLM alive for workgroups since Windows NT 3.1 [@ms-palko-evolution] [@fosdem-localkdc].
MIT krb5 added IAKERB support thirteen years ago. The README for krb5-1.9, released December 22, 2010, says verbatim: "Add support for IAKERB -- a mechanism for tunneling Kerberos KDC transactions over GSS-API, enabling clients to authenticate to services even when the clients cannot directly reach the KDC that serves the services" [@mit-krb5-19-readme] [@mit-krb5-19-page]. The capability sat in MIT's mainline Kerberos for over a decade. Windows did not ship the equivalent because, until NTLM was on a deprecation path, Windows did not need it -- NTLM filled the line-of-sight gap. Once NTLM was on the road to removal, IAKerb stopped being optional.
The thirteen-year gap between MIT krb5-1.9 IAKERB (December 22, 2010) and Microsoft's planned H2 2026 broad enable is the cleanest evidence that Microsoft's NTLM deprecation is the *forcing function* for the Kerberos refit, not a side effect. The specification was waiting for the customer demand to catch up.
### Local KDC: Kerberos for the workgroup
The second structural reason NTLM survived was that Windows local accounts had no concept of "domain". Without an AD domain, there was no KDC. Without a KDC, there were no Kerberos tickets. Local-account authentication therefore flowed through NT challenge-response (NTLMv2) by default.
Local KDC closes this. The Local KDC, shipping in Windows 11 24H2 and Server 2025 with broad enablement targeted for H2 2026 [@ms-palko-evolution], is a Kerberos KDC built directly on top of the local SAM database. LSA derives an AES-256 long-term key from the local account's password rather than persisting the legacy RC4 NT hash. The Local KDC exposes no listening Kerberos port; clients reach it only through IAKerb encapsulation inside the application protocol (SMB, RDP, HTTP).
The parallel open-source path was demonstrated by Alexander Bokovoy and Andreas Schneider at FOSDEM 2025, where they presented "localkdc: A General Local Authentication Hub" [@fosdem-localkdc]. The abstract reads verbatim: "A local Kerberos Key Distribution Center (KDC) is not a new invention. It is a useful tool in combination with the Kerberos IAKerb extension but also allows to map SSO from a web authentication to local authentication or in a network environment isolated from the rest of the enterprise environment ... how use of NTLM in SMB protocol will be replaced by a localkdc in combination with IAKerb" [@fosdem-localkdc]. Samba 4.21 carries the prototype implementation.
"Add support for IAKERB -- a mechanism for tunneling Kerberos KDC transactions over GSS-API, enabling clients to authenticate to services even when the clients cannot directly reach the KDC that serves the services." -- MIT krb5-1.9 release notes, December 22, 2010 [@mit-krb5-19-readme]
### PKINIT and the freshness extension
The third gap NTLM filled was non-password credentials. Windows Hello for Business, smart cards, and Federal Information Processing Standard token logon all need to translate "I hold this private key" into "I hold this Kerberos TGT". PKINIT (Public Key Cryptography for Initial Authentication in Kerberos), RFC 4556, by Larry Zhu (Microsoft) and Brian Tung (Aerospace Corporation), is the protocol for that [@rfc4556]. The AS-REQ carries a `PA-PK-AS-REQ` PA-DATA element wrapping an `AuthPack` CMS structure signed by the client's private key; the AS-REP carries the TGT keyed for the client to decrypt with either RSA key transport or Diffie-Hellman key exchange.
The 2006 RFC 4556 PKINIT had a replay window: an attacker who recorded a `signedAuthPack` could replay it indefinitely until the client's certificate expired. RFC 8070, "PKINIT Freshness Extension," by Michiko Short, Seth Moore, and Peter Miller of Microsoft (February 2017) closed it [@rfc8070]. The AS-REP issues an opaque `PA-AS-FRESHNESS` blob in a preliminary KDC-error round-trip; the client must echo the blob in its next signed AS-REQ; replays after the freshness window fail. Verbatim from RFC 8070 abstract: "exchange an opaque data blob that a Key Distribution Center (KDC) can validate to ensure that the client is currently in possession of the private key during a PKINIT Authentication Service (AS) exchange" [@rfc8070].
Together, RFC 4556 plus RFC 8070 anchor every modern non-password Windows credential: Windows Hello for Business, smart-card logon, FIDO2 keys mediated by Windows Hello, and the upcoming Entra-issued cloud TGTs. The 2022 Certifried CVE [@cve-2022-26923] forced the *strong-mapping* layer on top of all of this: every certificate used for PKINIT must carry an X.509 extension binding it to a specific AD account SID. KB5014754 [@ms-kb-5014754] tracks the rollout; see §4 for the full Compatibility / Enforcement / rollback-removal date sequence.
### FAST armoring as default
The fourth gap was the trust assumption at the start of an AS-REQ: the encrypted-timestamp pre-auth blob, `PA-ENC-TIMESTAMP`, is keyed under the client's password-derived key, which is offline-crackable on observation. FAST (RFC 6113) wraps the AS-REQ inside an armor envelope keyed under a separate key the attacker does not see [@rfc6113]. In a domain-joined client the armor key is derived from the machine account's TGT; in a non-domain-joined client it is derived from an anonymous PKINIT TGT; in a compound-identity scenario it is the combination of both.
What changes in the 2023 plan is the *default-on* posture: Authentication Policy Silos can now require FAST for every AS-REQ from a silo member, and Local KDC clients use anonymous PKINIT armoring out of the box because the SAM-derived long-term key is the only credential available and offline-crackability would be catastrophic.
sequenceDiagram
participant C as Client (no KDC reach)
participant S as Application Server
participant KDC as KDC (reachable from S)
C->>S: GSS-API token: IAKerb (AS-REQ wrapper)
S->>KDC: AS-REQ (forwarded)
KDC->>S: AS-REP (forwarded)
S->>C: GSS-API token: IAKerb (AS-REP wrapper)
C->>S: GSS-API token: IAKerb (TGS-REQ wrapper)
S->>KDC: TGS-REQ (forwarded)
KDC->>S: TGS-REP (forwarded)
S->>C: GSS-API token: IAKerb (TGS-REP wrapper)
C->>S: AP-REQ presenting service ticket
S->>C: AP-REP -- session established
### The Gap-to-Closure Mapping
| NTLM-fallback gap | Engineered closure | Primary source | Ship target |
|-------------------|--------------------|----------------|-------------|
| Client has no KDC line-of-sight | IAKerb GSS-API encapsulation | [@iakerb-draft] | Windows 11 24H2 / Server 2025; broad enable H2 2026 [@ms-palko-evolution] |
| Local accounts have no domain KDC | Local KDC on SAM + AES-256 derivation | [@ms-palko-evolution] [@fosdem-localkdc] | Windows 11 24H2 / Server 2025 |
| Non-password credentials need an AS path | PKINIT (RFC 4556) + Freshness (RFC 8070) + strong mapping (KB5014754) | [@rfc4556] [@rfc8070] [@ms-kb-5014754] | Enforcement February 11, 2025; rollback removed Sept 9, 2025 |
| AS-REQ pre-auth is offline-crackable | FAST armoring (RFC 6113) default-on in silos | [@rfc6113] | Available since Server 2012 R2; default-on with new silos |
After thirty-three years of layered extensions, Kerberos in 2026 is finally a single-protocol authentication path for every Windows scenario. Domain-joined, workgroup, Azure-joined without AD line-of-sight, local-account to local-account. The mechanism that closes the last gap -- IAKerb -- is a sixteen-year-old MIT protocol coming to Windows for the first time. What's left for Kerberos to fix is encryption-type hygiene, and a December 2025 Microsoft post named the calendar dates for that too.
## 7. The Beyond-RC4 Cadence
December 3, 2025. The Microsoft Windows Server Blog publishes "Beyond RC4 for Windows authentication" [@ms-beyond-rc4]. The post is short and specific. Verbatim: "By mid-2026, we will be updating the domain controller default assumed supported encryption types. The assumed supported encryption types is applied to service accounts that do not have an explicit configuration defined. Secure Windows authentication does not require RC4; AES-SHA1 can be used across all supported Windows versions since it was introduced in Windows Server 2008" [@ms-beyond-rc4]. For the first time in twenty years, RC4-HMAC is on a removal cadence with a calendar date and an enforcement CVE.
The rollout has three phases.
**Phase 1, January 2026, audit only.** Domain controllers gain new fields in Event ID 4768 (TGT issued) and Event ID 4769 (TGS issued): `msDS-SupportedEncryptionTypes`, `Available Keys`, and `Session Encryption Type`. The fields tell an administrator, for each ticket issued, which enctypes the requesting account had configured and which one the KDC actually chose. Two new PowerShell auditing scripts ship in the `microsoft/Kerberos-Crypto` GitHub repository: `List-AccountKeys.ps1` enumerates every account and the enctype configuration on each; `Get-KerbEncryptionUsage.ps1` parses the 4768 / 4769 log stream and prints accounts still requesting or being issued RC4 tickets [@ms-beyond-rc4]. Verbatim from the post: "we have enhanced existing information within the Security Event Log and developed new PowerShell auditing scripts. These enhancements are available in Windows Server versions 2019, 2022, and 2025" [@ms-beyond-rc4].
**Phase 2, mid-2026, default flip.** The "assumed" `msDS-SupportedEncryptionTypes` on accounts that have no explicit setting changes from "anything the client asks for, including RC4" to "AES-SHA1 only". AES-SHA1 (RFC 3962 enctypes 17 and 18) has shipped on every supported Windows version since Server 2008 [@rfc3962], so the flip is theoretically backward-compatible with every domain-joined client; in practice the casualties are third-party Kerberos clients (legacy Linux MIT krb5 with RC4-only keytabs, network-attached-storage appliances stuck on older krb5 libraries, SQL Server linked servers with manually-configured service-principal RC4 entries).
**Phase 3, mid-2026, enforcement.** RC4 tickets require explicit per-account opt-in. The enforcement boundary is *CVE-2026-20833*, called out by name in the Microsoft post [@ms-beyond-rc4]. After that date, an account that has not had `msDS-SupportedEncryptionTypes` explicitly written to include `0x4` (RC4) will not be issued RC4 tickets, and DCs will reject any TGS-REQ that asks for one against an account configured AES-only.
> **Note:** The mid-2026 RC4-default removal is gated on CVE-2026-20833, named in the December 2025 "Beyond RC4" post as the enforcement boundary [@ms-beyond-rc4]. The audit window closes when this date lands. Production environments that have not migrated their service accounts to gMSA or explicitly set `msDS-SupportedEncryptionTypes` will find Kerberos authentication failing for those accounts the day Phase 3 ships.
The interesting question is why the migration destination is AES-SHA1 (enctypes 17 and 18) and not AES-SHA2 (enctypes 19 and 20). RFC 8009 specifies AES-SHA2 [@rfc8009]; Microsoft's `[MS-KILE]` §2.2.7 supported-encryption-types bit table includes bits K (`AES128-CTS-HMAC-SHA256-128`) and L (`AES256-CTS-HMAC-SHA384-192`) [@ms-kile-227]. Linux MIT krb5 has shipped RFC 8009 since version 1.15 (December 2016) [@mit-krb5-115]. Cross-domain interoperability between AES-SHA2 Windows and AES-SHA2 MIT works. The remaining work is purely Microsoft-side default enablement and the auditing infrastructure analogous to the RC4 cadence.
The Beyond-RC4 post does not name an AES-SHA1 -> AES-SHA2 timeline at all. The audit-default-enforce cadence Microsoft has now demonstrated for RC4 -- audit instrumentation in event logs, default flip with backward-compatible enctypes, enforcement gated by a named CVE -- has no announced analogue for AES-SHA1 yet.
> **Key idea:** The cadence Microsoft has is audit, default, enforce. The RC4 to AES-SHA1 transition has all three: audit instrumentation in Phase 1, the default flip in Phase 2, and named enforcement via CVE-2026-20833 in Phase 3. The AES-SHA1 to AES-SHA2 transition has none. The [MS-KILE] bits exist; the cross-domain interoperability works; the Microsoft-side rollout is the missing piece.
The `microsoft/Kerberos-Crypto` GitHub repository ships the two PowerShell auditing scripts (`List-AccountKeys.ps1`, `Get-KerbEncryptionUsage.ps1`) that the December 2025 post names as the Phase 1 instrumentation. They are the right tools for an administrator who wants to find their RC4-dependent service accounts before the audit window closes mid-2026 [@ms-beyond-rc4].
Mid-2026 is the audit-window-closes date. The question for every AD operator is *which* of their service accounts will still be requesting RC4 tickets when the default flips, and whether their detection tooling sees them in the window. Two quarters from now, the answer "we'll just turn RC4 off and see what breaks" stops being a defensible operating posture.
timeline
title Beyond-RC4 rollout
section Phase 1 -- Audit
Jan 2026 : Event 4768 / 4769 fields msDS-SupportedEncryptionTypes Available Keys Session Encryption Type
Jan 2026 : Kerberos-Crypto GitHub repo with List-AccountKeys.ps1 and Get-KerbEncryptionUsage.ps1
section Phase 2 -- Default flip
Mid 2026 : Assumed msDS-SupportedEncryptionTypes flips to AES-SHA1-only for accounts without explicit configuration
section Phase 3 -- Enforcement
Mid 2026 : CVE-2026-20833 enforcement boundary -- RC4 tickets require explicit per-account opt-in
## 8. What Removing NTLM Cannot Buy You
After everything in Section 6 and Section 7 ships, Kerberos in 2026 is still vulnerable to four classes of attack. None of them are protocol bugs; all of them are protocol *structure*.
**Kerberos has its own relay class.** The KrbRelayUp README explicitly scopes itself to Windows domain environments where LDAP signing is not enforced -- the post-NTLM cousin of NTLM-relay [@krbrelayup]. The relay primitive survives the move from NTLM to Kerberos because the attack does not target the authentication protocol -- it targets the LDAP protocol's lack of mandatory integrity, and any authenticated bind (Kerberos or NTLM) is fair game once the channel is unsigned. The dispositive control is LDAP signing plus channel binding domain-wide, plus Extended Protection for Authentication on every AD CS Web Enrolment endpoint. It is a configuration, not a protocol fix. The [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/) companion article walks through the LDAP-side work in detail.
**The long-term-key problem is intrinsic to symmetric Kerberos.** Whoever holds the `krbtgt` account's long-term key forges any TGT (the Golden Ticket primitive). Whoever holds an SPN account's long-term key forges any TGS for that service (the Silver Ticket primitive). RFC 4120's offline-validation property [@rfc4120] *requires* that the service trust the key alone -- the AP-REQ contains no callback to the KDC; the service decrypts the ticket, validates the signatures, and decides. Any change that adds an online "is this ticket still valid?" check also gives up Kerberos's O(1) service-side scaling and the offline-validation guarantee that makes the protocol cheap. Authentication Policy Silos, Protected Users, TPM-backed credentials, and Credential Guard all raise the cost of obtaining the key; they do not close the forge-equivalence property. Mathematically, if you have the key, you are the principal.
**The PAC is a signed vouching token, not a verified live query.** KrbtgtFullPacSignature [@cve-2022-37967] closes the *modification* side of Diamond and Sapphire. It does not close the *staleness* side. A user removed from `Domain Admins` at 09:00 still presents service tickets attesting Domain Admin membership until the ticket expires (default 10 hours user TGT, 7 days renewable; Protected Users members are capped at 4 hours [@ms-protected-users]). The PAC vouching window is the residual stale-authorization gap. The defender's option is shorter ticket lifetimes or out-of-band ACL flips at the service tier; the protocol itself has no callback by which a service learns about a group-membership change before the ticket expires.
**Domainless does not mean keyless.** Local KDC binds the SAM password to an AES-256 long-term key. The wire form of pass-the-hash is gone: there is no NT hash on the line, no `LMv2` challenge response, no DES-CBC-MD5 keytab. But a `NT AUTHORITY\SYSTEM`-level attacker on the box still recovers the AES key, because LSA must materialise that key in user-mode memory to hand it to Kerberos. The chip- and VBS-based countermeasures (TPM-backed credentials, Microsoft Pluton, Credential Guard) remain orthogonal and necessary; none of them is replaced by Local KDC.
> **Key idea:** H2 2026 ships Kerberos as the load-bearing single authentication protocol; it does not ship a Kerberos in which (1) the Kerberos-relay class is closed, (2) long-term-key forge-equivalence is closed, (3) PAC staleness is closed, or (4) local-key recovery from a SYSTEM-level attacker on the box is closed. The arc is a transition between tradeoffs, not out of them.
## 9. Open Problems and the 2026-2027 Edge
Five problems sit on the May-2026 research agenda. None has a shipping Microsoft answer.
**The AES-SHA1 to AES-SHA2 Windows-default timeline.** RFC 8009 [@rfc8009] is nine years old. The `[MS-KILE]` §2.2.7 supported-encryption-types bit table already includes the AES-SHA2 bits K and L [@ms-kile-227]. Linux MIT krb5 shipped RFC 8009 in version 1.15 (December 2016) [@mit-krb5-115]. Cross-domain Kerberos interop between MIT clients and Windows DCs over AES-SHA2 works in the laboratory. What is missing is a Microsoft-side equivalent of the audit / default / enforce cadence already in place for the RC4 transition, especially because the hard part is not the cryptography but the long tail of third-party Kerberos clients and pre-2017 keytabs that an AES-SHA2 audit would have to enumerate before the default can flip. The 8009 cadence is the largest Windows-side cryptographic gap that has no announcement.
**Quantum risk.** Kerberos symmetric primitives (AES-128 and AES-256) retain a Grover-bound effective security margin of 64 and 128 bits respectively, which is durable against the near-term cryptographically-relevant quantum computer. PKINIT is the exposed half: the CMS signature chains in `AuthPack` are RSA or ECDSA per RFC 4556 §3.2 [@rfc4556], and both are broken by Shor's algorithm. Anonymous PKINIT, used for FAST armoring on non-domain-joined clients, has the same exposure. Microsoft has not announced a PKINIT-specific post-quantum cryptography plan; the Kerberos team's standardisation tracking sits on the IETF kitten working group's queue rather than on a shipping Windows roadmap. Cross-link to the post-quantum cryptography sibling article in this series.
**dMSA field-deployment maturity.** Server 2025 introduced Delegated Managed Service Accounts as the successor to gMSA [@ms-dmsa]. The protocol-level differences -- "Authentication for dMSA is linked to the device identity ... dMSA uses a randomized secret (derived from the machine account credential) that is held by the Domain Controller (DC) to encrypt tickets" -- close several gMSA gaps, including the multi-tenant-key problem. But the 14-day account-migration window, the four-ticket-lifetime startup state during which both the legacy account and the dMSA can authenticate, and the cross-domain plus cross-forest behaviours are still being shaken out in field deployments. As of the May 2026 reading, dMSA is shipping but not yet the default for new service accounts.
**Cross-cloud Kerberos.** Kerberos Cloud Trust for Windows Hello for Business is the architectural piece that lets an Azure-joined laptop obtain TGTs from Entra ID rather than from an on-premises DC, with the on-premises DC trusting Entra's signatures via federation. Per [@ms-palko-evolution] the architecture is planned but unproven in the field at scale. The role of Local KDC in pure-Entra (no AD on-prem) deployments is still being defined. The trust graph for "Local KDC + Entra ID + on-premises AD" is one of the open architectural problems the Palko post mentions but does not yet detail.
**Open-source IAKerb and Local KDC.** Samba's `localkdc` work, demonstrated by Alexander Bokovoy and Andreas Schneider at FOSDEM 2025 [@fosdem-localkdc], is the most public open-source mirror of Microsoft's Local KDC plan. Heimdal has a partial implementation. MIT krb5 IAKERB has been shipping since krb5-1.9 on December 22, 2010 [@mit-krb5-19-readme] and is mature. The Local-KDC-on-the-SAM pattern is new to the Windows world specifically; in the open-source world the equivalent (a Kerberos KDC fed from a local user database) has existed in textbooks since Kerberos v4.
Each of the five problems is a residual. Each is the next decade's research. None of them invalidates the Phase 3 shipping commitment. The article's load-bearing closing claim is honest about that: H2 2026 is a *transition*, and what comes next will be its own multi-year cadence.
## 10. What an AD Engineer Should Do This Quarter
If you read nothing else from this article, read this. Seven controls; each one is tied to one primary Microsoft Learn or MSRC URL; each one closes one of the attack primitives in Section 4. Cross-link to the parallel practical-guide section in the [NTLMless](/blog/ntlmless-the-death-of-ntlm-in-windows/) companion article.
> **Note:** Run the two PowerShell scripts in `microsoft/Kerberos-Crypto`: `List-AccountKeys.ps1` enumerates every account's configured enctypes; `Get-KerbEncryptionUsage.ps1` parses your Event 4768 / 4769 stream and lists accounts still requesting or being issued RC4 tickets. The audit window closes mid-2026 when Phase 2 flips the default [@ms-beyond-rc4]. Every account on the list above is a Phase-3 production incident if you do nothing.
> **Note:** Do not rely on the mid-2026 default flip. Explicitly write `msDS-SupportedEncryptionTypes` with the value `0x18` (AES-128 + AES-256, no RC4) on every service account that does not have a documented RC4 dependency. For service accounts that do, write `0x1C` (AES-128 + AES-256 + RC4) and put a calendar reminder against the RC4 dependency so it gets remediated before Phase 3 [@ms-beyond-rc4].
> **Note:** Manually-managed service-account passwords are the Kerberoasting attack surface per [@ms-kerberoasting-guidance]. gMSA gives you 240-character KDS-derived passwords rotated every 30 days [@ms-gmsa]. dMSA on Server 2025 binds the account secret to the device identity and stores it only on the domain controller, where it can be further protected by Credential Guard [@ms-dmsa]. There is no service-account workflow gMSA or dMSA does not cover; the migration is operational, not architectural.
> **Note:** Setting `ms-DS-MachineAccountQuota` on the domain root to zero kills the first step of the RBCD chain in Section 1 [@shenanigans-rbcd] and the KrbRelayUp chain [@krbrelayup]. The default value of 10 has been the de facto attack-surface enabler since Windows 2000. The control is one PowerShell line: `Set-ADDomain -Identity (Get-ADDomain) -Replace @{'ms-DS-MachineAccountQuota'=0}`. The breakage surface is small: only legitimate computer-account bootstrap workflows that today rely on user-driven `djoin.exe`.
> **Note:** Protected Users gives every member the five non-configurable client protections plus the 4-hour TGT cap [@ms-protected-users]. Wrap an Authentication Policy Silo around the same population to add mandatory FAST armoring [@rfc6113] and per-silo logon-from constraints. Both controls have been available since Server 2012 R2; the operational reason most environments still have not adopted them is the breakage in legacy delegation workflows. Audit and remediate those workflows; do not skip Protected Users.
> **Note:** Set `LDAPServerIntegrity = 2` (require signing) and `LdapEnforceChannelBinding = 2` (require channel binding on TLS-bound connections) via Group Policy. This is the dispositive KrbRelayUp defence [@krbrelayup] and the dispositive defence against any Kerberos-relay-class attack that targets the LDAP control plane. Pair with Extended Protection for Authentication on every AD CS Web Enrolment endpoint to close the Certifried-style certificate-issuance variant [@ms-kb-5014754].
> **Note:** Flight the `RC4DefaultDisablementPhase` Group Policy setting in your Insider channel; pilot non-production AES-only configurations on a representative subset of service accounts; identify legacy NAS appliances, Linux MIT krb5 clients with keytabs older than 2017, and SQL Server linked-server SPNs before Phase 2 closes the audit window [@ms-beyond-rc4]. Phase 3 ships with CVE-2026-20833; production environments that have not run the audit will discover the dependency list the day enforcement lands.
Three quarters from now (mid-2026), every default in this list will have changed. Do the work in the audit window or do it in the post-flip ticket queue. The cost of an audit-window migration is a quarter of engineering time; the cost of a post-flip remediation is a sixty-minute outage on every undocumented RC4 dependency the directory holds. Cross-link to the [Pluton](/blog/pluton-a-tpm-on-silicon-microsoft-can-patch/), TPM, and Credential Guard sibling articles for the hardware-backing layer that protects the long-term keys these controls assume.
## 11. Frequently Asked Questions
AES-SHA1 (RFC 3962 enctypes 17 and 18) is enough against the 2026 attack picture: there is no known cryptographic attack against AES-256-CTS-HMAC-SHA1-96 within Kerberos's threat model, and AES eliminates the salt-less / iteration-less Kerberoasting weakness of RC4-HMAC [@rfc3962] [@ms-kerberoasting-guidance]. AES-SHA2 (RFC 8009 enctypes 19 and 20) is the obvious next step and is supported by [MS-KILE] bits K and L [@ms-kile-227]. Quantum threats are not the immediate worry for symmetric Kerberos; the exposed surface is PKINIT, not the ticket cipher.The Grover speedup applied to AES-256 leaves an effective 128-bit security margin, which is durable for the lifetime of any current cryptographic system [@nist-pqc].
Yes, for delegation, and that is the point. Per [@ms-protected-users], members cannot use unconstrained or constrained delegation, cannot use DES or RC4 in Kerberos pre-auth, and have their TGT capped at four hours. Workflows that today rely on a domain admin's TGT being forwardable to a downstream service must be reworked. Use Authentication Policy Silos for the per-account scope where some delegation must remain.
Yes, with risk. The mid-2026 enforcement boundary CVE-2026-20833 [@ms-beyond-rc4] is the formal cutover. Disabling RC4 today by setting `msDS-SupportedEncryptionTypes` to `0x18` (AES-only) on accounts will work, but expect breakage from Linux clients with MIT krb5 keytabs older than 2017, network-attached-storage appliances with hard-coded RC4 entries, and SQL Server linked-server SPNs that have not been updated. The audit-then-migrate cadence in Section 10 is the operationally honest path.
No. It kills *unsigned-PAC* Golden Tickets and most Diamond and Sapphire variants that tampered with PAC fields outside the original sub-signatures [@cve-2022-37967]. If an attacker has the actual `krbtgt` long-term key, they still mint correctly-signed tickets -- the Full PAC Signature is computed with that same key. The defence is rapid `krbtgt` rotation (the dual-password scheme means you must rotate twice with an interval) plus Credential Guard to keep the key out of LSASS user-mode memory.
PKINIT [@rfc4556] exists, Active Directory Certificate Services exists, Windows Hello for Business is built on top of PKINIT. The reason "everywhere" was hard is Certifried (CVE-2022-26923) [@cve-2022-26923] and the strong-mapping retrofit [@ms-kb-5014754]: the original ADCS templates allowed a certificate's Subject Alternative Name to be set independently of the AD account that requested the certificate, which let an attacker mint a certificate claiming to be a domain controller. Strong mapping (the SID-binding X.509 extension) closed that, but the rollout took years to land in Enforcement mode (see §4 for the full date sequence).
It eliminates the *wire* form. There is no NT hash on the LSA-to-Local-KDC path; the long-term key is an AES-256 derivation. A SYSTEM-level attacker on the box still recovers that AES key, because LSA must hold it in user-mode memory to hand to the Kerberos SSP. The chip-side defences (TPM, Microsoft Pluton, Credential Guard) remain orthogonal and necessary per [@fosdem-localkdc]. Local KDC closes the relay-from-the-wire class, not the SYSTEM-on-the-box class.
Kerberos Cloud Trust for Windows Hello for Business issues TGTs from Entra ID and federates trust back to on-premises AD, so an Entra-joined laptop can present a domain-trusted Kerberos ticket to a file server it has never directly authenticated to. The on-premises KDC role is partially federated; the on-prem AD signs nothing for the Entra-issued TGT but trusts Entra's signature via Cloud Trust. Per [@ms-palko-evolution] the architecture is shipping in stages. The full story is its own article in this series.
Not in this decade. The architectural trajectory is "Kerberos + PKINIT + FAST + Local KDC + IAKerb + Authentication Policy Silos + TPM-backed long-term keys" -- not a replacement protocol. The closest thing to a replacement on the horizon is post-quantum PKINIT, which is more of a re-cipher than a re-protocol. The Kerberos message triple (AS-REQ, TGS-REQ, AP-REQ) is genuinely durable.Compared with the 28-year deprecation cycle NTLM took, replacing Kerberos would be a thirty-year project on the same precedent. Microsoft's stated direction is to harden the joints, not to throw out the skeleton.
The commands below assume Server 2019 or later with the `microsoft/Kerberos-Crypto` repo cloned locally. Run on a domain controller; output names every account whose configured `msDS-SupportedEncryptionTypes` allows RC4 or has no explicit setting (in which case it inherits the pre-Phase-2 default of "anything goes"). Cross-reference with the 4768 / 4769 audit stream from `Get-KerbEncryptionUsage.ps1` to identify which of those accounts is actually being issued RC4 tickets in practice.
```powershell
# Enumerate accounts and configured enctypes
Import-Module ActiveDirectory
.\List-AccountKeys.ps1 -OutputCsv accounts.csv
# Parse 4768 / 4769 events for issued ticket enctypes
.\Get-KerbEncryptionUsage.ps1 -LookbackDays 30 -OutputCsv tickets.csv
# Join the two on account name -- the accounts that
# both have RC4-allowed AND were issued RC4 tickets
# are your Phase 3 incident list.
```