Tiered Admin Model: Killing Lateral Movement

A single domain admin credential cached in an interactive logon session on a Tier 2 workstation is, statistically, the fastest path an attacker has to full forest compromise. Privileged access tiering exists precisely because flat Active Directory

#The Flat-Network Credential Exposure Problem

In a non-tiered domain, administrative credentials are portable across the entire estate. A domain admin who logs on interactively to troubleshoot a Tier 2 file server leaves an NTLM hash and, depending on Kerberos

The fix is not better antivirus on the file server. It is architectural: credentials must be structurally incapable of authenticating outside their designated trust boundary, regardless of endpoint hygiene. That is the entire premise of privileged access tiering — segmenting the identity plane so that compromise of a low-tier asset cannot yield a usable high-tier credential.

#Architectural Breakdown: The Enterprise Access Model

#

Tier Definitions and the Control Plane

Microsoft’s Enterprise Access Model (the successor to the legacy Tier 0/1/2 model) maps directly onto three functional planes: the Control Plane (domain controllers, PKI, federation servers, Entra Connect, Privileged Access Workstations), the Management Plane (endpoint management, SCCM/Intune, monitoring tooling, backup

Privileged access tiering enforces this through three mechanisms working in concert: authentication silos (Kerberos claims-based restriction on where an account can authenticate), Privileged Access Workstations (hardened, single-purpose endpoints for admin sessions), and logon right restrictions enforced via Group Policy at the OU level. None of these is sufficient alone — silos without PAWs still expose credentials to keyloggers on general-purpose hardware, and PAWs without silos rely on human discipline rather than protocol-level enforcement.

#Implementation Logic: Enforcing Privileged Access Tiering

Rolling out privileged access tiering against an established, flat domain is an incremental hardening exercise, not a big-bang cutover. The sequence below reflects the order that minimises lockout risk while closing the highest-severity gaps first.

• Inventory and classify accounts. Every account with domain admin, enterprise admin, or schema admin membership, plus any account with GenericAll/WriteDacl on Tier 0 objects (a common blind spot — delegated OU permissions frequently grant de facto Tier 0 rights without group membership).
• Build the tiered OU structure. Separate Tier 0, Tier 1, and Tier 2 computer and user objects into distinct OU trees so Group Policy can target logon rights precisely without relying on group filtering alone.
• Deploy Privileged Access Workstations. Dedicated, non-internet-browsing hardware imaged from a locked baseline, with no local admin rights for the operator and no access to email or general productivity tooling.
• Create authentication policy silos. Bind Tier 0 accounts to a silo that restricts Kerberos ticket issuance to explicitly listed PAWs and domain controllers.
• Apply deny-logon GPOs cross-tier. Explicitly deny interactive, RDP, and network logon rights for Tier 0 accounts on Tier 1/2 hosts, and for Tier 1 accounts on Tier 2 hosts.
• Rotate and randomise local admin credentials. Deploy LAPS (or Windows LAPS) fleet-wide so no local administrator password is shared across workload-plane hosts, closing the lateral pivot path that silos alone don’t cover.

#

Authentication Silo Configuration

Authentication silos are the enforcement primitive that makes privileged access tiering non-optional rather than policy-based. Once an account is a silo member, the KDC will refuse to issue a service ticket if the requesting workstation is not on the silo’s permitted device list — this is enforced at the protocol layer, independent of local GPO application.

1# Create the Tier 0 authentication policy
2New-ADAuthenticationPolicy -Name "Tier0-AuthPolicy" `
3  -Enforce `
4  -UserTGTLifetimeMins 240 `
5  -Description "Restricts Tier0 accounts to Tier0 PAW authentication silo"
6
7# Create the silo and bind the policy
8New-ADAuthenticationPolicySilo -Name "Tier0-Silo" `
9  -UserAuthenticationPolicy "Tier0-AuthPolicy" `
10  -ComputerAuthenticationPolicy "Tier0-AuthPolicy" `
11  -Enforce
12
13# Add Tier0 admin accounts and approved PAWs to the silo
14Get-ADUser -Filter {MemberOf -eq "CN=Domain Admins,CN=Users,DC=corp,DC=example"} |
15  ForEach-Object { Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account $_ }
16
17Get-ADComputer -SearchBase "OU=Tier0-PAWs,OU=Admin,DC=corp,DC=example" -Filter * |
18  ForEach-Object { Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" -Account $_ }

The -Enforce flag matters. Deploying silos in audit mode first (via -Enforce:$false equivalent audit policies) surfaces legitimate authentication paths you have forgotten — scheduled tasks, service accounts, monitoring agents — before you break them in production.

#

Cross-Tier Logon Denial via GPO

Silos govern Kerberos ticket issuance; GPO-based logon rights govern the local security policy on the target machine, and both are required because NTLM fallback and local account authentication bypass Kerberos silo enforcement entirely.

1<!-- GPO fragment: Deny log on locally / RDP for Tier0 group on Tier2 OU -->
2<GPO name="Tier2-DenyTier0Logon">
3  <SecurityOptions>
4    <UserRightsAssignment>
5      <Name>SeDenyInteractiveLogonRight</Name>
6      <Member>CORPTier0-Admins</Member>
7    </UserRightsAssignment>
8    <UserRightsAssignment>
9      <Name>SeDenyRemoteInteractiveLogonRight</Name>
10      <Member>CORPTier0-Admins</Member>
11    </UserRightsAssignment>
12    <UserRightsAssignment>
13      <Name>SeDenyNetworkLogonRight</Name>
14      <Member>CORPTier0-Admins</Member>
15    </UserRightsAssignment>
16  </SecurityOptions>
17</GPO>

Link this GPO to the Tier 2 workload OU with enforced inheritance and no security filtering exceptions. Any exception request is a symptom of an unmapped Tier 0 dependency that belongs on the inventory list, not in the GPO exclusion group.

#

Conditional Access as the Cloud-Side Silo Equivalent

For hybrid estates, Entra ID Conditional Access enforces the equivalent boundary for cloud-side privileged roles, binding Global Administrator and Privileged Role Administrator sign-in to compliant, PAW-tagged devices only.

1{
2  "displayName": "Tier0-CloudAdmins-RequirePAW",
3  "conditions": {
4    "users": { "includeRoles": ["62e90394-69f5-4237-9190-012177145e10"] },
5    "applications": { "includeApplications": ["All"] },
6    "platforms": { "includePlatforms": ["windows"] }
7  },
8  "grantControls": {
9    "operator": "AND",
10    "builtInControls": ["compliantDevice", "mfa"]
11  },
12  "sessionControls": {
13    "signInFrequency": { "value": 4, "type": "hours", "isEnabled": true }
14  }
15}

This policy, applied through the Graph API’s Conditional Access endpoint, means a Global Administrator token cannot be minted from a non-compliant device even with valid credentials and MFA — extending privileged access tiering from on-premises Kerberos boundaries into the cloud control plane consistently.

#Failure Modes and Edge Cases

The most common operational failure is silo lockout of break-glass accounts. If your emergency access account is a silo member and the PAW fleet is unreachable during an outage, you have engineered your own denial of service. Break-glass credentials must be excluded from silo membership and stored in an offline vault with independent MFA, audited separately.

Legacy service accounts are the second recurring problem. A backup agent or monitoring probe running under a Tier 0-equivalent account but installed on Tier 2 hardware will fail silently once silo enforcement goes live, because the KDC returns KDC_ERR_POLICY rather than a descriptive error. This is why the audit-mode rollout step is not optional — skipping it against a mature estate reliably produces a 2am incident.

NTLM fallback is the third edge case, and the most frequently missed. If NTLM is not explicitly restricted via Network security: Restrict NTLM policies, an attacker holding a captured hash can authenticate to a Tier 0 resource using NTLM even when Kerberos silos are correctly enforced, because silo policy only governs Kerberos ticket issuance. Privileged access tiering without NTLM restriction is enforcement theatre.

#Scaling and Security Trade-offs

• Operational overhead vs. containment — maintaining separate PAW hardware and OU structures increases help-desk complexity, but caps lateral movement blast radius to a single tier per incident.
• Silo enforcement vs. legacy compatibility — strict enforcement breaks undocumented service account dependencies; audit-first rollout trades a slower deployment timeline for zero unplanned outages.
• Cross-forest trust boundaries — silos do not span forest trusts automatically; multi-forest environments require selective authentication plus SID filtering, adding administrative surface area.
• Cloud/on-prem parity — Conditional Access session controls approximate silo behaviour for Entra roles, but token lifetime and Continuous Access Evaluation configuration must be aligned or the cloud side becomes the weaker link.
• Monitoring cost — every denied authentication event (4820/4825 in the Windows Security log) needs SIEM correlation; under-resourced logging pipelines turn enforcement gaps into invisible outages rather than actionable alerts.

None of these trade-offs argue against tiering — they argue for sequencing it correctly and instrumenting it before enforcement, rather than after. Teams evaluating broader architectural patterns for identity segmentation should treat privileged access tiering as a prerequisite baseline, not an optional hardening pass, because every subsequent zero-trust control — conditional access, JIT elevation, PAM session brokering — assumes the tier boundaries already exist. Reference the Microsoft Enterprise Access Model documentation when mapping your own tier definitions, as the boundary definitions there are what most PAM vendors expect integrations to align against.