Who is allowed to log in where? The KDC-side answer to credential theft in Active Directory

1. Two accounts, one TGT, every domain controller#

On a Tuesday morning in April 1997, an independent researcher named Paul Ashton posted to the NTBugtraq mailing list. His patched Samba smbclient did not accept a password. It accepted the hash, and the file server gave it everything ^[1]. The directory had no answer for the next sixteen years.

Skip forward to today. A domain admin's laptop is compromised by a phishing payload. The attacker runs Mimikatz against lsass.exe, recovers a Kerberos ticket-granting ticket for the admin account, and from that TGT every domain controller in the forest is reachable. The detection engineer who pulls the incident report knows exactly what happened. The architect on the other side of the table knows the answer was never going to come from the workstation, from the smartcard, or from the RDP client. It had to come from the directory.

This is what every credential-theft chain reduces to: a question about which accounts the directory will authenticate, from which machines, with which credential materials, for how long, and to whom they may delegate. Until October 2013, Active Directory had no place to answer that question. It had access-control lists, group memberships, and an AdminSDHolder template that re-stamped privileges every hour ^[2]. None of those mechanisms could refuse to issue a stolen credential, because on the wire a stolen credential is identical to a legitimate one.

Windows Server 2012 R2 changed that on October 18, 2013 ^[3]. In a single release, the directory acquired three controls that compose into one operational answer. The tier model names which accounts and machines belong to which control plane: T0 holds the domain controllers and the systems that manage them, T1 holds servers and business data, T2 holds workstations ^[4]. The Protected Users security group (well-known RID 525) imposes a non-configurable credential-restriction set: no NTLM, no DES or RC4 in Kerberos, no delegation, no cached offline-sign-in verifier, and a four-hour non-renewable TGT cap ^[5]. Authentication Policies and Authentication Policy Silos are directory objects that tell the Key Distribution Center (KDC) which source machines may authenticate which accounts, at AS-REQ time, before any TGT exists to be stolen ^[6].

The on-prem AD KDC, keyed on directory state read at issuance time, is the operational answer to credential-theft attack chains. The directory decides which accounts may authenticate, from which machines, with which credential materials, for how long, and to whom they may delegate. The three controls -- tier model, Protected Users, Authentication Policy Silos -- compose into that decision.

The rest of this article pays off the question Ashton's 1997 post raises. Why did the directory have no answer for sixteen years? What changed in October 2013 that the pre-2013 controls could not deliver? What does a working 2026 deployment look like, and what does it still leave open?

2. Why the directory had no answer for a decade#

Ashton's 1997 demonstration was not subtle. The NT hash is, on the wire, the credential. Windows NT 4's challenge-response authentication used the LanMan or NT one-way function output as the long-term key; anyone who could read that value from the SAM, from a network capture, or from lsadump could authenticate as the principal without ever knowing the password ^[1]. Wikipedia's secondary anchor attributes the first public demonstration to Ashton and dates it to 1997 ^[7]; the Exploit-DB mirror of the original patch preserves file modification timestamps that narrow the day to Tuesday, April 8, 1997 ^[1].

For more than a decade after Ashton's post, Microsoft's institutional position was that this was a protocol legacy, not a vulnerability. The reasoning was internally consistent: the hash IS the long-term key in the protocol's design; refusing to honour it would break every existing Windows client. The 2008 Pass-the-Hash Toolkit, written by Hernan Ochoa ^[7], turned the academic demonstration into a single-binary Windows-native tool that read NT hashes from lsass.exe and injected them into a running logon session ^[7]. Microsoft's Privileged access strategy page now records the 2008 release of the Pass-the-Hash Toolkit as the proximate cause of the escalation in attacker tooling ^[8].

The escalation that finally broke the institutional posture was Benjamin Delpy's Mimikatz, released publicly in May 2011 (closed source) on his personal blog ^[10]. Wired's biographical piece records the date verbatim: "He released it publicly in May 2011, but as a closed source program" ^[9]. The GitHub repository at github.com/gentilkiwi/mimikatz opened in April 2014; the sekurlsa::logonpasswords command on a SYSTEM-level shell printed plaintext passwords, NT hashes, and Kerberos session keys directly from lsass.exe ^[11]. Within twenty-four months it was the default post-exploitation credential dumper in every public AD attack-and-defence talk ^[12][9].

Microsoft's first institutional acknowledgement arrived in December 2012 as Mitigating Pass-the-Hash, Version 1. The canonical Microsoft Download Center URL for that version has not survived the company's reorganisations and now returns HTTP 404; the document is preserved through references inside its successor, the 2014 Version 2 paper, which is still hosted ^[13]. Version 2 introduces tiered administrative segmentation as a deployment shape and is unambiguous about why the previous decade of mitigations had not worked.

"Pass-the-Hash and similar credential theft attacks are 100% successful when an attacker gains administrative privileges on a computer, because once a computer is compromised, the attacker can read any credential stored on that computer." -- Microsoft, Mitigating Pass-the-Hash, Version 2 (2014) ^[13]

That sentence is the institutional pivot. It moves the framing from "protocol feature, defend the host" to "credentials, once stolen, win." The defence cannot live in the host, because the host is where the attacker has already won. It also cannot live in the ACL, because the ACL evaluates the principal that is authenticating, and the stolen credential authenticates as the legitimate principal. If access-control lists cannot stop a stolen credential, what can?

3. Five generations of pre-2013 controls and why each one failed#

Between 1997 and 2013, operators tried five distinct families of controls. Each targeted a different part of the stack. Each failed in the same structural way.

The first family was operational discipline: give every administrator two accounts, alice for daily work and alice.da for domain-administrative work, and trust her not to use the privileged identity from her daily workstation. NT 4 (RTM July 31, 1996) shipped with this as the operating model ^[14]. As a control it is a procedure, not an enforcement: there is no directory mechanism that prevents alice.da from interactively logging on to a tier-2 workstation. The Microsoft 2014 paper named the failure mode plainly: once alice.da runs anywhere an attacker also runs, the credential material sits in that machine's LSASS and is replayable forest-wide ^[13].

The second family was directory-ACL hardening. AdminSDHolder is an object under CN=System in the directory that stores a template security descriptor. A background task called SDProp runs every 60 minutes on the PDC emulator and re-stamps that ACL onto every account with adminCount=1 -- Domain Admins, Enterprise Admins, Schema Admins, and the rest of the protected groups ^[2]. The intent is to prevent ACL drift: a helpdesk operator's misconfigured permission cannot weaken Domain Admin protections for more than an hour. The mechanism survives in modern AD, but its original threat-model framing as a pass-the-hash mitigation is dead. ACLs evaluate the principal; a stolen credential authenticates as the legitimate principal. Worse, Sean Metcalf's Sneaky Active Directory Persistence #15 documents the inverse abuse: AdminSDHolder is not protected by AdminSDHolder, so an attacker who writes a Full-Control ACE into it once gets that ACE propagated across every protected member within sixty minutes ^[2].

The third family was smartcard-required admin accounts. Setting the SMARTCARD_REQUIRED flag (UAC bit 0x40000) on a privileged account causes the KDC to refuse any AS-REQ that is not a PKINIT request -- the user must present a certificate chain rooted in the domain, with the matching private key on a smartcard ^[15]. The phishing-credential-into-fake-portal vector is closed: the operator does not know a password to type. But the PKINIT exchange produces a derived long-term key that lives on the workstation as a normal NT hash. The 2014 Mitigating Pass-the-Hash paper is unambiguous in §6: "Smart cards do not protect against the Pass-the-Hash credential theft attack vector. When a smart card is used to log in to a system, the system computes a derived NT hash of the password and stores it on the system" ^[13]. Mimikatz extracts the derived hash like any other.

The fourth family was host-side credential protection: LSA Protection (RunAsPPL), WDigest plaintext disablement, and the TokenLeakDetectDelaySecs registry setting. LSA Protection runs lsass.exe as a Protected Process Light, refusing handles with PROCESS_VM_READ to anything not signed at PPL level ^[16]. WDigest plaintext disablement (via UseLogonCredential=0, shipped in KB 2871997 in May 2014) stops the WDigest SSP from caching the user's plaintext password ^[17]. Both moved the bar; neither closed the attack. PPL is enforced by the kernel; on pre-VBS Windows an attacker with a signed kernel driver clears the protection bit, and Mimikatz ships mimidrv.sys for exactly this purpose ^[11] (on modern hardware-rooted HVCI/VBS, the VTL1 secure kernel closes the signed-driver bypass, but the discussion then moves to where the §6 Credential Guard primitive lives ^[18]). WDigest disablement removes plaintext from memory but does nothing to the NT hash or to Kerberos session keys, which are the actually-replayable material.

The fifth family was Restricted Admin Mode for RDP, shipped via the October 14, 2014 revision of KB 2871997 ^[17]. The intent was to interrupt lateral movement: mstsc /restrictedadmin causes the RDP client to send a CredSSP-wrapped network logon to the target. The target creates a network-logon token instead of an interactive one, and the user's NT hash or Kerberos session keys never land on the target ^[19][20]. Within months, Benjamin Delpy demonstrated the inverse: because the RDP client authenticates with the user's existing credential material, an attacker on the client can pass a stolen NT hash directly into the RDP session with sekurlsa::pth /user:alice.da /domain:CORP /ntlm:<hash> /run:"mstsc /restrictedadmin" ^[11]. The defence became the lateral move. Microsoft updated KB 2871997 to acknowledge this, and Restricted Admin is off by default client-side on modern Windows ^[17].

flowchart TD
Op["Operator discipline (two-account pattern, 1990s)"] --> Op_x["Procedure, not enforcement: one mistake compromises the forest"]
ACL["AdminSDHolder + SDProp (NT 4 / 2000)"] --> ACL_x["ACLs evaluate the principal, and a stolen credential authenticates as the legitimate principal"]
SC["Smartcard-required (Server 2003+)"] --> SC_x["PKINIT changes only the AS-REQ method, and the derived NT hash still lives in LSASS"]
HS["LSA Protection / WDigest off (2013-14)"] --> HS_x["PPL bypassable by a signed kernel driver, with NT hash and Kerberos keys still in memory"]
RA["Restricted Admin Mode for RDP (Oct 2014)"] --> RA_x["Inverse-of-intent: enables pass-the-hash via RDP from the compromised client"]
Op_x --> Sink["All five enforce in a layer that does not see the directory's authoritative view of who-may-issue-credentials-from-where"]
ACL_x --> Sink
SC_x --> Sink
HS_x --> Sink
RA_x --> Sink

If the operator cannot be trusted, the ACL cannot enforce, the smartcard-derived hash still lives in LSASS, the host-side protections can be bypassed by anyone with privilege to deploy them, and the RDP mode meant to interrupt lateral movement enables it -- where does the decision have to move?

4. October 18, 2013: the directory acquires a vocabulary#

The Microsoft Server team's August 14, 2013 save-the-date blog post fixed the General Availability of Windows Server 2012 R2 for October 18, 2013 ^[3]. In that single release, three new directory-side primitives appeared: the Protected Users built-in security group with well-known RID 525, the msDS-AuthNPolicy AD object class for Authentication Policies, and the msDS-AuthNPolicySilo AD object class for Authentication Policy Silos ^[21]. The legacy Windows Server 2012 R2 TechNet documentation, preserved on Microsoft Learn, states the introduction verbatim: "This group was introduced in Windows Server 2012 R2" ^[21]. The architectural decision visible in the wire format: the KDC, not the application, now decides whether a TGT may be issued, what its lifetime will be, and what delegation operations on it will succeed.

The detail that matters: there is no dedicated "Protected Users bit" in the PAC. The encoding is the well-known group SID S-1-5-21-<domain>-525 carried in PAC_LOGON_INFO.GroupIds ([MS-PAC] §2.5) ^[23][21]. The KDC reads that array at AS-REQ and TGS-REQ time the same way it reads it for every other group; what changes is the behaviour the KDC takes when it sees RID 525.

The down-level half of the shipment arrived seven months later. On May 13, 2014, Microsoft Security Advisory KB 2871997 backported the client-side honoring of Protected Users and Authentication Policies to Windows 7, Windows 8, Server 2008 R2, and Server 2012 ^[17]. KB 2871997 is not the introduction of Protected Users. It is the down-level backport that closed the long-tail Silo-bypass class an enterprise would hit if its 2014-era fleet could not honour the new restriction list. Five months later, the October 14, 2014 revision of the same KB shipped Restricted Admin Mode for RDP -- the mode §3 already taught the reader to treat as a cautionary tale.

Microsoft followed the primitive with a deployment shape. The Securing Privileged Access reference material, originally published on TechNet circa 2014-2015 and preserved on Microsoft Learn at the privileged-access-workstations root ^[24], codified the clean-source principle: a higher-tier secret must never be exposed to a lower-tier host. T0 holds domain controllers, the PKI root, the identity-sync infrastructure, and the DC backup system. T1 holds servers and business data. T2 holds workstations ^[4]. T0 credentials never authenticate to T1 or T2; T1 credentials never authenticate to T2. The Privileged Access Workstation (PAW) is the dedicated source machine for T0 administration. Server 2012 R2 gave operators the primitives; SPA gave them the shape.

flowchart LR
A["Apr 8, 1997: Paul Ashton, NTBugtraq -- hash IS the credential"] --> B["2008: Hernan Ochoa, Pass-the-Hash Toolkit"]
B --> C["May 2011: Benjamin Delpy, Mimikatz public release"]
C --> D["Dec 2012: Microsoft, Mitigating Pass-the-Hash v1"]
D --> E["Oct 18, 2013: Windows Server 2012 R2 GA -- Protected Users, Authentication Policies, Silos"]
E --> F["May 13, 2014: KB 2871997 down-level backport"]
F --> G["Oct 14, 2014: KB 2871997 adds Restricted Admin RDP"]
G --> H["2014-2015: Securing Privileged Access reference material"]
H -->     I["Dec 15, 2020: ESAE retired, Enterprise Access Model begins"]
I --> J["Nov 9, 2021: KB 5008380 PAC hardening"]
J --> K["May 10, 2022: KB 5014754 PKINIT strong mapping"]
K --> L["Feb 11, 2025: KB 5014754 Full Enforcement default"]
L --> M["Sep 9, 2025: KB 5014754 Compatibility-mode revert removed"]

The KDC, not the application, decides whether a TGT may be issued, what its lifetime is, and what delegation operations on it will succeed. The decision is made by reading directory state -- group SID 525 in PAC_LOGON_INFO.GroupIds for Protected Users, msDS-AssignedAuthNPolicySilo and msDS-AssignedAuthNPolicy for Silo and Policy bindings -- at request time. This is the architectural pivot. The credential-on-the-wire identity property no longer matters, because the credential never gets issued in the first place to be stolen.

Three controls, one ship. But how do they compose, exactly -- which decision does the KDC actually make at AS-REQ time, what does it read from the directory, and what does it refuse?

5. How the three controls compose: a mechanism walkthrough#

If you have time to read only one section of this article, read this one. The Server 2012 R2 controls compose into a precise decision the KDC makes at AS-REQ and TGS-REQ time. The mechanism has four moving parts.

5.1 The tier model as policy intent#

The tier model is policy intent, not enforcement. Tier 0 is the control plane: every domain controller, every certificate authority that issues domain-trust certificates, the Microsoft Entra Connect server that synchronises identity to the cloud, and the backup systems that can restore any of those. Tier 1 is the management and data plane: servers, business applications, and the database engines that hold the data the organisation actually cares about. Tier 2 is the user plane: workstations and the devices users carry ^[4]. The rule that defines the model is the clean-source principle: a higher-tier credential must never authenticate to a lower-tier host, because once it lands in the lower-tier host's memory it is exfiltrable by anyone with privilege on that host ^[8]. The tier model says nothing about how the rule is enforced. Protected Users and Authentication Policy Silos are how.

5.2 Protected Users: the credential-restriction switch#

Protected Users is a global security group with well-known RID 525, present in every domain at Domain Functional Level 2012 R2 or later. Membership is encoded as the well-known SID S-1-5-21-<domain>-525 carried in the GroupIds array of the user's PAC_LOGON_INFO ([MS-PAC] §2.5) ^[23][5]. When the KDC reads RID 525 in that array, it applies a non-configurable restriction set documented on Microsoft Learn ^[5]:

1. No NTLM authentication. The DC refuses any NTLM authentication attempt for a Protected Users member -- the NTLM SSP and NetLogon path on the DC enforce the rejection, and the Kerberos KDC enforces the corresponding refusal for AS-REQ flows that fall back to NTLM-style pre-authentication. NTLM relay against the account is structurally impossible because there is no NTLM session to relay.
2. No NTLM hash caching on the host. Even if the user has logged on interactively, the LSA never holds the account's NT one-way function output. Mimikatz sekurlsa::logonpasswords prints (null) for the NTLM tab.
3. No DES or RC4 in Kerberos pre-authentication. AES-128 or AES-256 only. Kerberoasting against the account becomes inapplicable, because the public roasting tooling requires RC4-HMAC ticket material that the KDC refuses to issue.
4. No constrained or unconstrained delegation, in either direction. The account cannot be the source of a constrained-delegation chain, and S4U2Self / S4U2Proxy against the account as a target is refused at TGS-REQ time.
5. No cached offline-sign-in verifier. The Windows Hello for Business PIN-based offline-logon path is unavailable for Protected Users members; this is the operational price of removing the cached verifier from disk.
6. TGT lifetime capped at 240 minutes, non-renewable. Microsoft Learn states the figure verbatim: "For Protected Users members, the group automatically sets these lifetime limits to 240 minutes" ^[5]. The cap overrides the domain's "Maximum lifetime for user ticket" and "Maximum lifetime for user ticket renewal" policies.

The built-in domain Administrator (RID 500) is always exempt from Authentication Policy enforcement even when assigned to a Silo, which makes it a candidate break-glass identity ^[5]. That exemption does not extend to the Protected Users restriction set itself: adding RID 500 to Protected Users on a domain whose Administrator account lacks AES keys will lock the account out. Service accounts cannot be enrolled in Protected Users without breaking workflows -- see §6's canonical Microsoft Learn PullQuote on this point.

5.3 Authentication Policies and Silos: the KDC-side policy objects#

Two AD object classes, layered. The containment direction is the most common practitioner confusion, so be precise about it: the Silo references the Policy, not the other way.

The same Policy can be referenced by multiple Silos. Accounts can be bound to a Policy directly via msDS-AssignedAuthNPolicy without being placed in a Silo at all, though the more common pattern is Silo membership for the broader containment and Policy reuse for the rule definitions.

5.4 The KDC's decision points#

The KDC consults the directory at three precise moments, documented in [MS-KILE] §3.3.5 ^[27]:

• AS-REQ. The KDC reads the requester's msDS-AssignedAuthNPolicySilo and any msDS-AssignedAuthNPolicy. If the Policy specifies a UserAllowedToAuthenticateFrom SDDL, the KDC evaluates the source-machine identity (as presented in the pre-authentication exchange) against the SDDL. On denial, the KDC returns KDC_ERR_POLICY and no TGT is issued. The KDC also checks PAC_LOGON_INFO.GroupIds for RID 525; if present, it applies the Protected Users restriction set to the TGT it is about to issue (AES-only, 240-minute cap, delegation forbidden).
• TGS-REQ for S4U2Self. The KDC reads the target account's group memberships and Silo bindings. If the target is a Protected Users member, S4U2Self is refused. If the target's Silo Policy specifies an allowed-to SDDL, the requesting service identity is evaluated against it ^[28].
• TGS-REQ for S4U2Proxy. The KDC evaluates the requesting service's msDS-AllowedToDelegateTo and the target's msDS-AllowedToActOnBehalfOfOtherIdentity, then layers the Silo Policy's claim requirements on top. Protected Users membership on either side terminates the request ^[28].

sequenceDiagram
participant PAW as PAW (source machine)
participant KDC as KDC on DC
participant DS as Directory (LDAP DSA)
PAW->>KDC: AS-REQ for alice.da, pre-auth signed
KDC->>DS: Read alice.da object (PAC_LOGON_INFO, msDS-AssignedAuthNPolicySilo)
DS-->>KDC: GroupIds includes RID 525, Silo = "T0 Admins"
KDC->>DS: Read referenced Policy (msDS-AuthNPolicy)
DS-->>KDC: UserAllowedToAuthenticateFrom SDDL pinned to T0 PAWs
KDC->>KDC: Evaluate source machine identity against SDDL
alt Source is in the allowed-from set
KDC->>KDC: Apply Protected Users restriction set (AES-only, no NTLM, no delegation)
KDC->>KDC: Cap TGT lifetime at 240 minutes non-renewable
KDC-->>PAW: TGT issued with restriction PAC
else Source not in the allowed-from set
KDC-->>PAW: KDC_ERR_POLICY, no TGT issued
end

flowchart LR
A["User account alice.da (msDS-AssignedAuthNPolicySilo)"] --> S["Silo: T0 Admins (msDS-AuthNPolicySilo)"]
C["Computer account paw01 (msDS-AssignedAuthNPolicySilo)"] --> S
SV["Service account svc-bkp (msDS-AssignedAuthNPolicySilo)"] --> S
S -- "references" --> P["Policy: T0 Source Restriction (msDS-AuthNPolicy)"]
P --> Rule1["UserAllowedToAuthenticateFrom SDDL"]
P --> Rule2["TGT lifetime cap"]
P --> Rule3["Claim transformations"]
P --> Rule4["FAST armoring requirement"]
S -. "alt direct binding" .-> A2["Account can also bind via msDS-AssignedAuthNPolicy"]

The RunnableCode block below simulates the decision tree as a small JS function. It is pedagogical, not a real KDC, but the logic mirrors what [MS-KILE] specifies. Change the inputs -- move the source machine outside the allowed-from set, flip the Protected Users flag -- and the decision changes.

function kdcDecideAsReq(account, sourceMachine) {
// account: { name, inProtectedUsers, siloPolicy: { allowedFrom: [], tgtMinutes, requireFast } }
// sourceMachine: { name }

if (account.siloPolicy && account.siloPolicy.allowedFrom &&
    !account.siloPolicy.allowedFrom.includes(sourceMachine.name)) {
  return { issued: false, error: "KDC_ERR_POLICY", reason: "source not in allowed-from set" };
}

const restrictions = [];
let tgtMinutes = account.siloPolicy ? account.siloPolicy.tgtMinutes : 600;
let renewable = true;

if (account.inProtectedUsers) {
  restrictions.push("no-NTLM", "AES-only", "no-delegation", "no-cached-verifier");
  tgtMinutes = Math.min(tgtMinutes, 240);
  renewable = false;
}

return {
  issued: true,
  tgtMinutes,
  renewable,
  restrictions,
  sourceMachine: sourceMachine.name
};
}

const alice = {
name: "alice.da",
inProtectedUsers: true,
siloPolicy: { allowedFrom: ["paw-t0-01", "paw-t0-02"], tgtMinutes: 480, requireFast: true }
};

console.log("From PAW:", kdcDecideAsReq(alice, { name: "paw-t0-01" }));
console.log("From workstation:", kdcDecideAsReq(alice, { name: "wks-finance-77" }));

The KDC now has a vocabulary it did not have in 1997. Well-known group SID 525 as a credential-restriction switch. msDS-AuthNPolicySilo and msDS-AuthNPolicy as policy objects. drsuapi as the replication primitive that carries policy changes to every DC. The decision is keyed on directory state, made at request time, before any TGT exists to be stolen. With the mechanism in hand, what does a current 2026 reference deployment look like?

6. The 2026 reference deployment#

Microsoft has had thirteen years to settle the deployment shape. As of May 2026, a well-built environment looks like the layered stack below, in which Silos and Protected Users carry the on-prem enforcement and several complementary primitives close residuals the KDC plane cannot address by construction.

The reference deployment composes:

• Tier model present as policy intent, with Authentication Policy Silos as the enforcement primitive that makes the tier boundary KDC-visible.
• All human T0 administrators in Protected Users, in a "T0 Admins" Silo whose Policy's UserAllowedToAuthenticateFrom SDDL pins authentication to a defined set of T0 PAWs. The KDC will return KDC_ERR_POLICY for any AS-REQ from outside that set ^[6][27].
• T0 service accounts in a "T0 Services" Silo with a more permissive Policy that still pins source machines. Service accounts cannot be in Protected Users; the Silo plane is the only KDC-side enforcement available to them ^[5].
• Domain-wide migration off RC4-HMAC for AS-REP, with msDS-SupportedEncryptionTypes audited per account. Protected Users enforces AES-only for free for human members; service accounts need explicit per-account configuration ^[31].
• Credential Guard default-on for non-DC Windows 11 22H2+ and Windows Server 2025+ devices that meet the hardware requirements ^[18]. Windows LAPS managing local-administrator password uniqueness on every workstation ^[32].
• Entra PIM for Entra ID privileged roles ^[33], with Conditional Access keyed on the synced T0 Admins group requiring phishing-resistant MFA and a compliant device. The CA does not see the Silo; it sees the synced group. The two planes are independent (see §8).
• Microsoft Defender for Identity assessments running, including "Identify privileged accounts that are not protected by Protected Users group" and adjacent recommendations ^[34]. This is the detection plane that tells the operator the reference deployment is the deployed posture.

"Never add accounts for services and computers to the Protected Users group. For those accounts, membership doesn't provide local protections because the password and certificate is always available on the host." -- Microsoft Learn, Protected Users Security Group ^[5]

That quote is the operational reason the RBCD residual remains the punchline of §8. Before then, two further pieces of the reference deployment need to be named, because both have been mis-described in widely shared blog posts.

The first is the November 2021 PAC hardening in KB 5008380, which addressed CVE-2021-42287 and CVE-2021-42278 ("noPAC"). The fix added two new PAC buffer types to the Kerberos TGT: PAC_REQUESTOR (buffer type 18), which encodes the SID of the principal that requested the ticket, and PAC_ATTRIBUTES_INFO (buffer type 17), which carries PAC-generation attributes ^[37][23]. The KDC at TGS-REQ time now verifies that the requestor SID in the PAC matches the principal currently presenting the TGT. Initial deployment was November 9, 2021; the Enforcement phase landed October 11, 2022 ^[37].

The second is the May 2022 PKINIT certificate-to-account strong-mapping fix in KB 5014754 ^[38]. Pre-fix, the KDC mapped a PKINIT certificate to an account by sAMAccountName or UPN -- the same comparison that Schroeder and Christensen's Certified Pre-Owned whitepaper showed could be spoofed via UPN conflicts or via the trailing dollar-sign convention on machine accounts ^[39][40]. The fix added the SecurityIdentifier X.509 extension OID 1.3.6.1.4.1.311.25.2 to certificates issued by AD CS and requires the KDC to match the SID in the certificate against the SID of the account being authenticated. The Full Enforcement default landed February 11, 2025; the Compatibility-mode revert option was removed on September 9, 2025 ^[38].

Reference 2026 deployment: what runs where.

If this is the reference deployment, what about the alternative architectures customers actually have in production -- ESAE forests, MIM PAM bastion forests, the Enterprise Access Model?

7. Tiered Administration vs. bastion forest vs. Enterprise Access Model#

Three operational doctrines coexist in 2026 production environments, with a fourth meta-architecture sitting above them. None are interchangeable; choosing the wrong one means over-building, under-building, or building the right thing in the wrong place.

Method A: Tier model + Authentication Policy Silos + Protected Users. The current Microsoft recommendation for the on-prem enforcement layer in connected and hybrid environments. The whole of §5 and §6 is the description. Cited references: ^[5][6][4].

Method B: MIM Privileged Access Management with a bastion forest. Microsoft Identity Manager PAM with the Server 2016 bastion-forest functional level gives just-in-time activation of privileged group membership in a separate, hardened "bastion" forest with a one-way trust from production to bastion. Microsoft Learn's Raise the bastion forest functional level page is explicit on the feature pivot: "With Windows Server 2016, PAM features of time-limited group memberships and shadow principal groups are built into Windows Server Active Directory" ^[41]. A user requests time-bound activation, MIM validates it, the user is briefly added to a bastion-forest privileged group (a shadow principal at WS 2016 FFL), and the resulting TGT carries the production SIDs via PAC SID History. When the activation expires, the SID History entry disappears from newly issued tickets. The Microsoft Learn page is explicit about scope:

"The PAM approach provided by MIM PAM is not recommended for new deployments in Internet-connected environments. MIM PAM is intended to be used in a custom architecture for isolated AD environments where Internet access is not available, where this configuration is required by regulation, or in high impact isolated environments like offline research laboratories and disconnected operational technology or supervisory control and data acquisition environments." -- Microsoft Learn, MIM PAM ^[42]

Method C: Enhanced Security Admin Environment (ESAE) / Red Forest. A separate hardened forest used exclusively for administrative identities, with a one-way trust from production to the admin forest. Production-forest administration is performed by accounts that live exclusively in the admin forest. Microsoft retired ESAE as a mainstream recommendation on December 15, 2020 ^[43].

Method D: Enterprise Access Model (EAM) / Rapid Modernization Plan (RaMP). Microsoft's current meta-architecture, announced concurrently with the ESAE retirement on December 15, 2020 ^[43][4][44]. EAM widens the segmentation from forest boundaries to access levels: a privileged-access plane (the equivalent of T0, now explicitly including Entra ID admin roles), a management plane (formerly T1), a data/workload plane (where applications run), and a user/app plane (T2). EAM does not deprecate the directory-level controls -- it encloses them inside a larger model that adds the cloud control plane as a first-class object.

Four operational doctrines, side by side.

Method D is the framework; Method A is the on-prem enforcement layer inside it; Methods B and C are the niche answers for environments Method A cannot reach. The four are not in competition for the same job. A connected hybrid enterprise in 2026 runs Method D + Method A on-prem, with B and C reserved for the air-gapped exception cases.

EAM is the framework. Method A is its on-prem enforcement layer. What does Method A's enforcement layer NOT close, by construction?

8. What the KDC cannot enforce#

A well-deployed Method A architecture eliminates the credential-theft attack chain at the KDC. It does not close every gap. The remaining gaps are not implementation bugs; they are structural properties of where the KDC sits in the stack. Naming them is not optional.

The RBCD residual. Resource-based constrained delegation is configured by writing the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the target object ^[28]. The write is governed by the target object's DACL, not by the Silo plane. The KDC never sees the write; it only sees the resulting TGS-REQ. If the target is a service account that is Silo'd but not in Protected Users -- which, per Microsoft Learn's explicit guidance, is the case for most service accounts -- the RBCD chain remains exploitable. The defence is layered: pin the source machine via the Silo Policy, deny WriteProperty on msDS-AllowedToActOnBehalfOfOtherIdentity for everyone but directory administrators, prefer Group Managed Service Accounts for new services, and put Defender for Identity detection on the attribute-write event ^[34].

Physical extraction from a logged-on T0 host. The KDC cannot prevent the extraction of credential material from the memory of a machine on which the user is logged on. The credential has to exist somewhere in memory for the user to use it. Credential Guard raises the bar dramatically by placing the credential material in a VBS-protected VTL1 enclave that the VTL0 kernel cannot read, even with a signed driver ^[18]. Remote Credential Guard adds a parallel host-side control for RDP-initiated authentications that redirects Kerberos requests back to the originating client ^[19]. None of these is a KDC control. The KDC and the host are two layers; both are required.

The on-prem-to-cloud bridge. On-prem AD KDC enforcement (Silo membership) and Entra ID Conditional Access enforcement are two independent policy planes by construction. The Primary Refresh Token does not carry msDS-AssignedAuthNPolicySilo. Conditional Access does not consume the Silo binding. Operational alignment is achieved by synchronising the Silo'd group through Microsoft Entra Connect and writing a Conditional Access policy keyed on the synced group. The CA sees the synchronised group; it does not see the Silo. Two planes, both must hold.

Closing the on-prem-to-cloud gap requires either a Microsoft product change that projects Silo membership into the Primary Refresh Token, or a third-party policy synthesiser. Neither exists as a product surface in May 2026 -- which is why the §10 Phase 4 workaround (sync the Silo'd group through Microsoft Entra Connect, key the Conditional Access policy on the synced group) is the current production answer. The workaround keeps both planes independent by construction; it does not close the gap, it routes around it.

Supply-chain compromise of T0 software. The KDC cannot enforce policy against an agent running as SYSTEM on every domain controller. By construction, the agent is outside the KDC's authorisation scope; it can rewrite the directory the KDC reads its policy from. The canonical instance is the SolarWinds Orion compromise disclosed in December 2020 (CISA Alert AA20-352A): the attackers used a backdoored Orion update to obtain SYSTEM-level access on management hosts and, per the CISA advisory's User Impersonation section, in several documented cases used that access to compromise "the SAML signing certificate using their escalated Active Directory privileges" -- the AD FS / Entra Connect token-signing certificate -- and then "create unauthorized but valid tokens" presented to services that trust SAML tokens from the environment, on T0 systems where the secret material has to exist in memory for the system to do its job ^[45]. The KDC saw legitimately-signed tickets and made legitimate policy decisions; the enforcement gap is one layer below, where the software running as the KDC's neighbour ships compromised code. The closure for this residual is not at the KDC; it is at the software-supply-chain layer (code signing, reproducible builds, attested deployment, and strict T0-software inventory).

A maximally-correct Method A deployment closes the KDC-plane gaps it was designed to close. Four explicit residuals remain by construction. Three need additional controls (target-ACL hardening, Credential Guard, Conditional Access keyed on the synced group); the fourth is closed at the software-supply-chain layer. The architecture is correct. The world is bigger than the architecture.

What is the active research, and what does a practitioner do on Monday morning to deploy what is settled?

9. Active research lines as of mid-2026#

The community is not standing still. Five lines of work are visible on the public radar.

Projecting Authentication Policy Silo membership into Entra Conditional Access as a first-class signal. The most-named open problem in both SpecterOps research and Microsoft's own post-NTLM roadmap discussion. Matthew Palko's October 2023 post Evolution of Windows Authentication is Microsoft's institutional acknowledgement that the post-NTLM future is Kerberos plus IAKerb plus Local KDC; the post does not commit to projecting Silo membership into the Primary Refresh Token, but it is the closest reading the community has of a hybrid identity direction ^[46]. IAKerb plus Local KDC is plausibly the substrate that could eventually carry Silo state across the on-prem-to-cloud boundary, but no public Microsoft roadmap entry as of May 2026 announces that projection.

Tier Zero scoping at hybrid-cloud scale. Defining the boundary of T0 in a hybrid environment is increasingly difficult. The on-prem T0 set (DCs, AD CS, Entra Connect, DC backup) is enumerable. The cloud-side T0 set (Entra ID Application Administrators with Graph permissions over AD-synced objects, Hybrid Identity Administrators, Global Administrators, Privileged Authentication Administrators) is large, dynamic, and contains roles whose tier-0 status is contested. The SpecterOps Tier Zero Table is the community's canonical operational answer; its GitHub README is explicit that "the table does not include all Tier Zero assets yet" ^[30]. BloodHound Community Edition is the companion discovery primitive: feed it a directory snapshot, ask it for attack paths to T0, fix the paths ^[47]. The introductory blog series at SpecterOps explains the "Defining the Undefined" definitional work behind the table ^[48].

Continued discovery of ADCS misconfiguration classes (ESC1-ESC8+). Schroeder and Christensen's June 17, 2021 Certified Pre-Owned whitepaper was the inflection ^[39][40]. The original taxonomy catalogued ESC1 through ESC8; ESC9 and several subsequently-disclosed classes have been added since by the SpecterOps team and the wider AD CS research community, with the GhostPack Certify tool tracking the enumerable classes in its active branch ^[49], and adjacent variants continuing to land in the SpecterOps blog stream. Each class is a tier-bypass primitive that survives Method A's deployment if the AD CS configuration is itself misconfigured: the KDC sees a legitimately-signed certificate and a legitimate AS-REQ. KB 5014754's strong-mapping closes the specific CVE-2022-26923 ("Certifried") class; template hardening (manager-approval, no-CT, no-enrollee-supplies-subject) addresses several other classes ^[38].

Kerberos relay primitives. The KrbRelay family of attacks, anchored to James Forshaw's October 2021 Project Zero research on cross-protocol Kerberos relaying ^[50] and operationalised in the cube0x0/KrbRelay tool released shortly thereafter ^[51], exploits the absence of channel binding in some pre-authentication flows. Silos enforce on the source-machine identity as presented in the AS-REQ; an attacker who can cause a different machine to issue an AS-REQ on the attacker's behalf and relay it can satisfy the Silo Policy. FAST (RFC 6113) provides the cryptographic primitive for channel binding ^[25]; Microsoft's Kerberos armoring uses FAST, and a Silo Policy can be configured to require FAST armoring. The open deployment question is whether FAST armoring becomes the universal default in legacy environments. The Palko post on the post-NTLM Windows authentication roadmap is the closest Microsoft has come to addressing the deployment direction publicly ^[46].

Service-account placement: Protected Users vs. Silo-only. The unsolved sub-problem inside the RBCD residual. Service accounts have two failure modes: they cannot be placed in Protected Users without breaking their delegation workflows, and they cannot be left out without leaving an RBCD-attack primitive against tier-protected service accounts that have writable msDS-AllowedToActOnBehalfOfOtherIdentity. The current best partial result is composite: Group Managed Service Accounts plus a tight Silo Policy plus an ACL on the delegation attribute plus a SIEM rule on attribute writes. The architectural answer would be an extension to Protected Users that retains delegation-as-source but refuses NTLM, RC4, and DES. No such extension appears on Microsoft's public roadmap as of May 2026 ^[5][34].

The settled controls are deployable. The open research is real and has not been closed. Five years from now, the Silo plane will likely still be the operational answer, with the residuals closed by different parts of the stack. What does that look like to a practitioner reading this on a Monday morning?

10. A six-phase playbook for deploying Method A this quarter#

A staged playbook. The phases are ordered for safety: each phase reduces the blast radius of the next, and the first phase is the most important and the most often skipped.

Phase 0: Inventory Tier 0#

Use the SpecterOps Tier Zero Table as the starting checklist ^[30][29]. Pair it with BloodHound Community Edition to discover the attack paths your environment actually has into the T0 set ^[47]. The Tier Zero Table is intentionally incomplete -- treat it as the floor, not the ceiling -- and add the assets specific to your environment: any service account whose compromise grants write access to a DC, any backup system that can restore a DC's NTDS.dit, any monitoring system that can run code on a DC. Sean Metcalf's body of work on secure workstation baselines is the canonical operator-grade reading for this phase ^[52][12].

Phase 1: Create the T0 Admins Silo and Policy in audit mode#

Create the msDS-AuthNPolicySilo named "T0 Admins" and its referenced msDS-AuthNPolicy named "T0 Source Restriction." Set msDS-AuthNPolicySiloEnforced=FALSE to start in audit mode ^[6]. Place a single test admin account in Protected Users and assign it to the Silo. Set the Policy's UserAllowedToAuthenticateFrom SDDL to a SID set containing exactly one PAW. Confirm that authentication from the PAW succeeds, that authentication from a tier-2 workstation generates the expected audit event (Authentication Policy Silo audit failure in the Security log), and that nothing else in the environment breaks. Once the audit window is clean, flip the Silo to enforced mode. The KDC now returns KDC_ERR_POLICY for any AS-REQ from outside the allowed-from set ^[27].

Phase 2: Catalogue every delegation relationship in the directory#

Enumerate every account with msDS-AllowedToDelegateTo set, every object with msDS-AllowedToActOnBehalfOfOtherIdentity set, and every account with the legacy TrustedForDelegation UAC bit. For each T0-adjacent service account, decide whether the workflow can survive Protected Users membership. If yes, enrol the account and move on. If no -- which will be the common answer -- create a "T0 Services" Silo with a tight UserAllowedToAuthenticateFrom Policy, bind the account to the Silo, deny WriteProperty on msDS-AllowedToActOnBehalfOfOtherIdentity for everyone but directory administrators, and audit Defender for Identity for the corresponding alerts ^[34]. The composite defence is the current best partial answer to the RBCD residual.

Phase 3: Roll the human T0 administrators into Protected Users in batches#

Audit the longest-running tier-0 administrative task in your environment before you enrol anyone. Forest backups, replication health checks, schema upgrade dry-runs, DC promotions, and emergency operational procedures sometimes exceed four hours; the Protected Users 240-minute non-renewable TGT cap will silently re-authenticate or fail outright when they do ^[31]. Enrol in batches of two or three administrators at a time; keep the previous batch in for at least two weeks before adding the next. Microsoft's How to Configure Protected Accounts page lays out the staged enrolment shape ^[31].

Phase 4: Project the T0 group into Entra Conditional Access#

Sync the T0 Admins group through Microsoft Entra Connect. Write a Conditional Access policy that requires phishing-resistant MFA (FIDO2, Windows Hello for Business, or certificate-based authentication) for that group, plus a compliant device, plus a known-good location if the threat model justifies it ^[33]. Document explicitly that the CA is keyed on the synchronised group, not on the Silo binding; the two enforcement planes are independent by construction. The Entra side is the topic of the Conditional Access post in this series for the deeper treatment.

Phase 5: Break-glass#

Two emergency-access accounts that are outside every Silo, outside Protected Users, with passwords stored offline in a tamper-evident envelope held by two separate people, with a documented monthly use-and-rotate procedure, and with high-fidelity SIEM detection on every authentication attempt. The cost of the break-glass pair is the deliberate, audited counter-balance to the rest of the architecture. Microsoft's RaMP guidance treats this as the first step of the privileged-access rollout ^[44]. The built-in domain Administrator (RID 500) is the natural canonical first break-glass identity because it is exempt from Authentication Policy enforcement even when assigned to a Silo ^[5].

You have a playbook. You also have a set of questions readers are now going to ask. Here they are.

11. Frequently asked questions#

The directory now has the answer it lacked for sixteen years. Three controls, one ship, plus thirteen years of operational discipline to compose them, plus an explicit acknowledgement of the four residuals the KDC cannot close by construction. On the Tuesday morning in April 1997 when Paul Ashton posted his patched smbclient to NTBugtraq, no one in the AD product group could have written this article. They can now -- and the KDC, keyed on directory state, is the layer they would write it from.