Active Directory / Advanced / Lesson 13

Privileged access, tiering, and control-plane security

Protect identities that can control the directory and its dependencies, using current enterprise-access guidance rather than treating legacy tiers as a complete modern architecture.

About 5 min readContent reviewed 2026-10-26

On this page

Lesson goals

Identify direct and indirect control over AD DS.
Explain privilege separation and secure administration paths.
Review classic tier concepts against the current enterprise access model.

Directory control extends beyond a familiar admin group

A directory control plane includes more than the visible Domain Admins membership. Permission editing, group management, controller administration, sensitive backup access, and management systems that can control identity infrastructure can create indirect authority. Review those relationships rather than relying on a short privileged-group list. A compromised ordinary workstation should not become a trusted administration surface merely because an administrator signs in there. Separate routine user activity from privileged administration and define accountable owners for the paths. This is a defensive architecture lesson, not an exercise in obtaining credentials, testing escalation, or interacting with a real directory.

Use separation concepts without freezing an obsolete diagram

Classic AD tier models describe preventing highly privileged identities from being exposed to less trusted administrative or user surfaces. Microsoft’s enterprise access model extends the framing to control, management, and data/workload planes and modern access paths. Treat that current guidance as the architecture reference; do not present an old privileged-forest or three-tier diagram as a universal new-deployment prescription. The complete Python model checks two declared administration paths and rejects using the identity-admin role for ordinary browsing. It models intent only, not Windows logon rights, credential protections, conditional access, or a secure workstation configuration.

python Offline privileged-path separation model

approved_paths = {
    ("identity_admin", "identity_management_surface"),
    ("workload_admin", "workload_management_surface"),
}
requests = [
    ("identity_admin", "identity_management_surface"),
    ("identity_admin", "ordinary_browsing_surface"),
    ("workload_admin", "identity_management_surface"),
]
for request in requests:
    print(request in approved_paths)

Expected output

True
False
False

The outputs are True, False, False under the declared model. No logon, credential use, endpoint check, or domain policy is performed.

Protect the full path used to administer identity

Define the administrator identity, approved device/surface, target, authentication requirements, privilege duration, audit evidence, and emergency access ownership. Multifactor authentication and privileged access tooling must fit the actual protocol and management channel; a web sign-in control does not automatically protect every legacy path. Avoid shared routine administrator identities that obscure accountability. Keep powerful groups small and reviewed, but also review who can alter those groups or the systems that enforce them. Domain controllers should not become general application or browsing hosts. This course supplies no workstation setup, logon configuration, or administrative command to apply.

Document intended paths and explicit exclusions

The contextual record distinguishes identity control from workload management and ordinary use. It is a defensive review document, not an enforcement policy or evidence that a privileged workstation is correctly built. Real implementation needs supported platform controls, identity lifecycle, recovery access, and testing for alternate paths. An emergency account must have monitored, controlled use rather than being ignored because it is rarely used. A role with broad rights should not be copied into a service identity just to simplify automation. Tie exceptional access to an owner, a reason, and a review/removal condition without recording secrets in the course or logs.

json Non-runnable privileged-access review record

{"control_plane":"AD DS administration","approved_surface":"identity_management_surface","ordinary_user_activity":"excluded","emergency_access":"controlled_and_audited","review_state":"architecture_only"}

The record describes separation intent and review ownership only. It changes no account, logon right, device policy, or access control.

Verify alternate paths, not only the preferred tool

An approved design review should identify every management route that can control the directory, including backup and virtualization dependencies where relevant. Test intended allowance and denial in an isolated environment and review audit visibility. A local path-set test cannot prove credentials are protected or a machine is trustworthy. Track changes to privileged groups, delegated permissions, and management integrations with accountable ownership. When a legacy path cannot meet the target design immediately, document the residual risk and migration plan rather than declaring the whole control plane secure. Periodic review must use current Microsoft guidance and actual environment evidence, not a permanently trusted diagram.

Common errors and fixes

Only Domain Admins membership is reviewed.

Why it happens: Indirect control through permissions and management systems was omitted.
How to fix it: Review the full identity control-plane relationship graph.
Prevent it next time: Include backups, delegated rights, and management dependencies.

A privileged account performs ordinary browsing on an untrusted device.

Why it happens: Identity privilege and administration surface were not separated.
How to fix it: Use the reviewed dedicated administration path.
Prevent it next time: Test denied alternate use paths under the approved policy.

A legacy tier diagram is presented as complete current guidance.

Why it happens: Historical separation concepts were not reconciled with the enterprise model.
How to fix it: Review Microsoft’s current enterprise access model and environment scope.
Prevent it next time: Date architecture reviews and name residual risks.

Check your understanding

1. An automation service can edit a privileged group but is absent from the admin inventory. Explain the missing relationship without testing an escalation.

Show worked solution

The service can influence who receives privileged authority, creating an indirect control path. Add its actual permission, owner, execution surface, approval process, and audit coverage to the review. Do not authenticate as it or modify membership to demonstrate the point. Analyze approved configuration evidence and a synthetic relationship model before any operational validation.

2. Add a new approved management surface to the local model. What must a real review establish before that path is accepted?