The Privileged Access Model: Tier 0, Administrative Separation, and the Enterprise Access Model.

1. Core mechanism

This lesson treats privilege as an asset's ability to establish lasting or temporary control over another asset, not merely as membership in Domain Admins. Legacy Tier 0 centers on domain controllers, forest and domain administration groups, and the identity infrastructure that determines their security. The Enterprise Access Model expands that boundary into the control plane; the management and data/workload planes remain separate management targets. Lesson 14.02 applies this model to trusted endpoints, accounts, and sessions; lesson 14.03 covers control-plane dependencies beyond domain controllers.

Interfaces and specifications

• The control plane manages enterprise identity and access-control decisions. Compromising it can redefine access across the other planes.
• The management plane contains enterprise-wide IT management functions. It is powerful, but it is not the same trust boundary as the control plane.
• The data/workload plane contains applications and data. Its business value may be high, but that does not make every workload administrator a control-plane administrator.
• Legacy Tier 0 is the highest-trust tier in the model for limiting privilege escalation in on-premises AD. EAM extends the idea to modern enterprise access paths.
• Separation applies in both directions: lower-plane identities must not manage the control plane, and control-plane identities must not be used on lower-plane productivity surfaces.
• An asset's plane is determined by its control effect, not its label. A dependency that can change control-plane identities, policies, or management paths may belong in control-plane scope.
• The synthetic SDDL artifact shows how this boundary might be represented in a resource DACL. It says nothing about real groups or effective access.

Tier 0 is not a group name

Thinking of Tier 0 only as the Domain Admins group is incomplete. The real question is whether a principal or system can change identity and access-control decisions. An account may not belong directly to a privileged group, yet still touch the same control chain if it can change that group's membership, the system an administrator signs in to, or an authorizing policy.

Tier 0 scope is therefore derived from control effect, not a static product list. Forest roots, domain controllers, and highly privileged groups are starting points; dependencies that determine their management paths must also be included.

What changes in the Enterprise Access Model?

Microsoft's Enterprise Access Model does not discard the legacy AD tier model; it places it within a broader enterprise access map. Tier 0 expands into the control plane. The former Tier 1 splits into an enterprise-wide management plane and a workload-specific data/workload plane. The former Tier 2 splits into user-access and app-access paths.

This distinction is more useful when cloud and on-premises management meet in one organization. A workload administrator may have a critical role without needing authority over the enterprise identity system. A central management platform may also have broad access; if that access gives it control-plane authority, its scope must be reclassified.

Management separation is a graph problem

Plane separation is not just an OU, name, or group prefix. Chains such as principal → group → delegated right → policy → endpoint → credential must be reviewed together. A lower-plane administrator changing a control-plane GPO, or a control-plane administrator signing in to a lower-plane device, breaks the separation in practice even when the labels look correct.

The review must therefore go beyond 'Who is a Domain Admin?' It must ask who can change a control-plane decision, which devices accept that identity, and which dependencies can rewrite that path.

The DACL makes the boundary visible

The synthetic DACL artifact shows three roles: Generic All for control-plane administrators, Generic Read/Execute for auditors, and an explicit Generic All deny for lower-plane administrators. It is not a deployment recipe; it is a small model of how a plane policy might be represented in resource permissions.

The SDDL parser only reads the owner, group, DACL flags, and ACE fields. It does not prove that the SIDs belong to real groups, that ACE ordering produces the intended result for the target object type, or that no other control path exists.

State and data flow

1. Inventory the business value to protect and the identity/access-control components that determine access to it.
2. Review which accounts, policies, or management paths each component can change; record control effect rather than labels.
3. Place assets that can change identity and access-control decisions within control-plane scope.
4. Separate enterprise-wide management tools into the management plane and workload-specific management roles into the data/workload plane.
5. Define separate administrator principals and resource ACLs for each plane.
6. Remove transitions where a lower-plane principal has management rights over a control-plane resource, or document them explicitly as exceptions.
7. Also limit the devices and targets to which control-plane administrators can sign in; lesson 14.02 covers this endpoint path.
8. Reassess changes through transitive control paths and effective DACLs, not only by group name.

2. Exploitation

Broken trust assumption

The broken assumption is that clean membership in highly privileged groups is enough to establish Tier 0 separation.

Technical prerequisites

• The lower-plane principal, or a system it manages, must be able to change a control-plane ACL, group membership, policy, or endpoint.
• The influence may come through an indirect route such as a nested group, delegated right, or management agent rather than direct membership.
• A review limited to privileged-group membership must miss the transitive control path for this scenario to remain undetected.
• A control-plane identity must be used on a lower-plane device, or a lower-plane account must be accepted by a control-plane target.

Exploitation mechanism

Instead of joining a control-plane group directly, an attacker targets that group, an authorizing policy, or a lower-plane component that can alter an administrator's trusted session path. If a management or workload administrator can change a control-plane resource's DACL or owner, write its policy, or administer the endpoint used to manage it, the plane boundary can be bypassed. The labels may still look correct while the transitive control graph provides a path to a higher plane.

Why plane violations can be silent

A lower-plane account may not belong to Domain Admins, so a simple membership report can look clean. But if it can change a management tool's service configuration, a control-plane GPO, or the endpoint used by a Tier 0 administrator, it may still expose a control-plane identity.

In this model, the critical evidence is not one group list but the set of control edges. The weakest edge is any point where an attacker can change a higher plane's decisions, regardless of the plane where the path begins.

A label is not a security boundary

Adding a T0 prefix to a group or moving a server into a Tier 0 OU does not automatically separate the management paths that reach it. If ACLs, service accounts, deployment platforms, and session sources do not enforce the same boundary, naming only helps with inventory.

The threat model therefore does not stop at 'Which object is Tier 0?' It also asks 'Who or what can modify this object?' for every dependency in the path.

3. Defense & Detection

Telemetry scope

• For control-plane assets, track ownership, DACLs, group membership, policy writers, and management-endpoint ownership in one inventory.
• For each control edge, record the source principal's plane and the target asset's plane. Do not accept lower-to-control transitions without a documented exception.
• Resolve nested groups and delegated rights separately from a direct-membership report.
• Correlate control-plane administrator logons on lower-plane endpoints with the device and session data in lesson 14.02.

Events and relevant fields

• This lesson does not treat any single Windows Event ID as proof of Tier 0. Relevant telemetry about ACL, group, policy, and endpoint changes must be combined.
• A DACL change may generate an event, depending on the source, but that event alone does not show that the new descriptor is safe.
• A permission inventory is a point-in-time snapshot; recalculate it after group nesting or ownership changes.

The control edge is the unit of defense

For the blue team, the measurable unit is not group membership but the control edge from a source principal to a target resource. WriteDACL, ownership changes, group-membership writes, policy deployment, and management-endpoint control may come from different data sources, but they can represent the same plane violation.

This inventory must be timestamped. An ACL snapshot does not automatically reflect later changes to group nesting or ownership.

Enforce the boundary in both directions

Preventing lower-plane accounts from managing the control plane is not enough. If a control-plane account signs in to a productivity or workload device, that device becomes another attack surface for credential and session material.

Plane policy must therefore be enforced in both target ACLs and the rules that accept a logon source or device. Lesson 14.02 covers this second boundary through PAWs, separate accounts, and session discipline.

Detection logic · KQL

PrivilegedPathInventory | where TargetPlane == "Control" and SourcePlane != "Control" | project SourcePrincipal, SourcePlane, ControlEdge, TargetResource, EvidenceId

Query assumptions

• PrivilegedPathInventory is an organization-defined normalized graph or inventory table, not a product table.
• SourcePlane and TargetPlane labels must come from an analysis of control effects.
• ControlEdge must identify the directly or transitively resolved type of authority.

False positives

• A documented break-glass or migration path may temporarily create a lower-to-control edge.
• Read-only audit access may be misclassified as management control.
• A stale inventory may still show a delegation that has been removed.

Hardening

• Derive control-plane scope from identity and access-control effects, not group names.
• Do not give lower-plane principals management, ownership, or DACL-change rights over control-plane resources.
• Apply separate account, device, and target-acceptance policies to control-plane and lower-plane administration.
• Make exceptions time-bounded, assigned to an owner, and subject to a review date.
• Verify separation periodically with a transitive control graph and an effective-permission review.

Read the examples

O:SYG:SYD:PAI(D;;GA;;;S-1-5-21-111111111-222222222-333333333-2101)(A;;GRGX;;;S-1-5-21-111111111-222222222-333333333-2201)(A;;GA;;;S-1-5-21-111111111-222222222-333333333-2200)

Two reality checks

Assumption: Tier 0 is a fixed product list consisting of Domain Admins and domain controllers.

In fact: The legacy model starts with these assets, but the trust boundary includes every control path that can change identity and access-control decisions. The Enterprise Access Model expands this approach into the control plane.

Assumption: Adding only the right people to the Tier 0 group completes management separation.

In fact: Indirect paths such as nested groups, DACL or owner privileges, policy writers, and management endpoints can give a lower-plane principal control-plane influence. Verify the separation through the transitive control graph.

Sources

• Microsoft · Securing privileged access Enterprise access model
  Control, management, and data/workload planes; Zero Trust principles; Evolution from the AD tier model; Tier 0 scope expansion; Tier 1 and Tier 2 splits.
• Microsoft · Security Descriptors
  Owner SID, primary group SID, DACL, SACL, and control-flag components.
• Microsoft · Access Control Entries
  The trustee SID, access mask, allow/deny type, and inheritance/flag information in an ACE.