Privileged access is the attacker's objective: every path in the AD attack-path map is really a hunt for a credential powerful enough to own the domain. So the defensive discipline that matters most is designing privileged access to survive credential theft — to ensure that stealing one admin's token does not cascade into Domain Admin. This page is the deep version of the foundation referenced in AD Hardening & Tiering.
The core realisation: you cannot stop every credential from being stolen (phishing and LSASS theft will succeed sometimes), so you design so that the credentials that can be stolen are not the ones that matter, and the ones that matter are almost never exposed.
The problem: credential theft + reuse = Domain Admin
The classic attack chain is depressingly short: phish a workstation → dump cached credentials or LSASS → find that a Domain Admin logged on to that box (or reuse a shared local-admin password) → pass-the-hash or pass-the-ticket laterally → reach a DC → DCSync. Every link in that chain assumes a powerful credential was exposed on a machine an attacker could reach. Privileged-access design removes that assumption.
From the tier model to the Enterprise Access Model
The original defence was the tier model (Tier 0 = identity/DCs, Tier 1 = servers, Tier 2 = workstations) with a strict no-downward-credential rule, often reinforced by a dedicated ESAE “Red Forest.” Microsoft's current guidance generalises this into the Enterprise Access Model, which spans on-prem and cloud:
CONTROL PLANE identity & infrastructure control
(highest value) DCs, Entra global admin, AD CS, Azure root mgmt groups
^ never exposes credentials downward
|
MANAGEMENT PLANE administration of servers & workloads
^
|
DATA / WORKLOAD the apps & data themselves (business value)
PLANE
Rule: a credential from a higher plane NEVER authenticates to a
lower-plane, internet-exposed, or user-reachable asset.The planes matter more than the old tier numbers because modern privilege lives in the cloud too — a Global Admin in Entra or an owner of the Azure root management group is Control-plane, exactly like a domain controller. The clean source principle ties it together: a system is only as secure as the systems that control it, so anything that manages a Control-plane asset must itself be Control-plane.
Privileged Access Workstations (PAWs)
Admins need a trustworthy place to type privileged credentials. A general-purpose laptop that also browses the web and reads email is not it — that is where phishing and drive-by compromise happen. A PAW is a dedicated, hardened, separately-managed device used only for privileged tasks:
- No web browsing, no email, no arbitrary software — the highest-risk everyday activities are simply absent.
- Locked down with application allowlisting, Credential Guard, and strict baselines; managed from the Control plane, not the user plane.
- Access to Tier-0/Control-plane systems (DCs, Entra admin) is permitted only from a PAW, often through a jump server that adds a network segmentation and recording layer.
The PAW population is small even in huge organisations — typically 5–15 true Control-plane admins — so the highest tier is affordable to protect well, and you expand the model outward from there.
PAM: vault, elevate just-in-time, record everything
A Privileged Access Management platform operationalises least privilege for admins:
- Vaulting — privileged credentials live in a vault, checked out per task, auto-rotated after use, never known to the human.
- Just-in-time (JIT) elevation — no standing admin rights; access is requested, approved, time-boxed, and automatically revoked (Entra PIM, CyberArk, BeyondTrust).
- Just-enough-admin (JEA) — grant the specific capability, not blanket admin.
- Session recording & monitoring — every privileged session is brokered and recorded, giving the auditability regulators require.
- Break-glass — a tightly controlled, heavily alerted emergency account for when the system itself fails.
Tooling: CyberArk (the enterprise heavyweight), BeyondTrust, Delinea, Microsoft Entra PIM, and the cloud-native Teleport for infrastructure/SSH/K8s access. All of it should sit behind phishing-resistant MFA and use named accounts (never shared admin logins), so every privileged action is attributable.
Red team ↔ blue team: what this breaks
| Attack chain step | How the model breaks it |
|---|---|
| Harvest a DA credential from a workstation | DAs never log on to workstations; there is no high-value credential to steal there |
| Pass-the-hash laterally to a server | No standing privilege + JIT means the stolen token is already expired or unprivileged; segmentation blocks the hop |
| Reach and admin a domain controller | DCs are Control-plane, reachable only from a PAW via a jump host — not from user space |
| Abuse delegation / DCSync | Both require already-high privilege; the model ensures that privilege was never exposed to be stolen in the first place |
Privileged access isn't a product you buy — it's a design that removes the implicit, standing, exposed privilege the entire AD attack chain depends on. It is the same idea as Zero Trust (least privilege, verify every time, no standing trust), applied to the most dangerous accounts in the company.
Key takeaways
- Privileged access is the attacker's goal; design it to survive credential theft.
- The Enterprise Access Model (Control/Management/Data planes) + clean-source principle replaces the old tier model and spans cloud.
- PAWs give admins a trustworthy place to use credentials; PAM removes standing privilege with JIT elevation, vaulting, and recording.
- Done right, it breaks the AD attack chain by ensuring the credentials that matter are never exposed where they can be stolen.