Skip to content

Module 12 — Tiering a Brownfield Domain

Type 12 · Migration / Brownfield — take the already-running, already-compromised Corp domain and roll out the tier model from Module 11 incrementally, without locking anyone out (strangler-fig); the deliverable is the migration runbook + the staged Deny-logon GPO + the per-wave "no admin locked out, no attack path reopened" proof + a per-wave rollback, not a greenfield design. Go to the hands-on lab →

Last reviewed: 2026-06

Active Directory & Windows Security — Module 11 designs the tiered model on a clean slate; this module imposes it on a live domain where DAs already log into workstations every day — and you are not allowed to break their access while you fix it.

Difficulty: Intermediate–Advanced  ·  Estimated time: ~5–7 hrs (study + lab)  ·  Prerequisites: Foundations, Module 08 — Path to Domain Admin (the path you're closing), Module 11 — Defending Identity (the target tier design)

In 60 seconds

Module 11 designed the tier model on greenfield Corp; this module imposes it on a live domain where DAs already RDP into workstations every morning — and you may not break their access while you fix it. The naive move (link the Deny-logon GPO at the domain root) is a big-bang cutover: one blast radius, no incremental rollback, debugged live against every admin. The discipline is strangler-fig: stage to a pilot OU, move accounts in waves, and prove each wave twice — no admin locked out AND the attack path that wave closed is now dead — before you widen.

Why this matters

Module 11 gives you the right answer — a tiered admin model where Tier 0 credentials never touch a Tier 2 workstation, so a compromised Finance box can never hold a domain admin's hash. But Module 11 designs that model on greenfield Corp: a clean assignment table, the GPOs as a specification, the JIT workflow as a description. The domain you actually inherit looks nothing like that. It is brownfield: tallen (a domain admin) RDPs into Finance workstations to fix printers, sgarcia runs the helpdesk console from her own laptop, service accounts log on interactively where they shouldn't, and nobody has a complete inventory of who-logs-on-where. The tier boundaries you designed cut straight across how people work today. The job is not to design the model — you already did — it's to get there from here without an outage, on a domain the whole company depends on every morning.

The naive move is the dangerous one, and it is exactly what a stressed engineer (or an LLM asked to "apply the tier model") will reach for: write the Deny log on locally and Deny log on through Remote Desktop Services GPOs that the design calls for, link them at the domain root, and go home. This is the big-bang cutover, and it fails for a reason that has nothing to do with whether tiering is correct — it fails because you have just changed the logon rights for every privileged account on every host simultaneously. The Module 11 README warns about this in one line ("accidentally applying Deny log on through Remote Desktop Services to the wrong scope can lock administrators out of a production DC"); this module is that warning made into the whole lesson. The instant that GPO replicates, the admin who was mid-session fixing a server is denied their next logon, the backup service account that was logging on interactively fails its job, and you cannot tell which of a hundred newly-denied logons is a real lockout versus an intended one — you are debugging a domain-wide access outage live, with no incremental rollback, while the helpdesk queue fills with "I can't log in." The blast radius is every admin in the company.

The correct path is stage to a pilot OU, move accounts in waves, prove each wave, then widen — the strangler-fig migration. You do not link the Deny-logon GPO at the root. You stand the tier model up beside the flat domain: create the Tier 0/1/2 OUs and groups, write the restriction GPOs but link them to a single pilot OU containing one cooperative team's workstations, and move privileged accounts into Protected Users and out of lower-tier logon rights one wave at a time. After each wave you run the same two-part proof: every admin in the wave can still do their job through the now-correct path (no lockout — the whole point), and the attack path that wave was meant to close is now dead (re-walk the relevant hop of PATH-001 and show it fails). Only when both hold do you widen the GPO scope to the next OU. A per-wave rollback (unlink the GPO from that OU, pull the account back out of Protected Users) is ready at every step, and it is cheap precisely because the flat domain is still serving everyone you haven't moved yet.

The mental model

The pattern is the strangler fig (Fowler, 2001): a vine grows around a living tree and draws it down gradually — the host is never felled in one stroke. Applied here, you grow the tiered structure around the running flat domain, moving accounts and host OUs one wave at a time, while the flat surface (DAs on workstations) shrinks toward zero and everyone keeps working. The lever that makes it incremental is GPO scope — a restriction authored once but linked to one pilot OU, then widened.

The mental model is the strangler fig (Martin Fowler, 2001 — named for the rainforest vine that grows around a host tree, drawing it down gradually until the new structure can stand on its own, with the original never felled in a single stroke). Applied to a live domain: you do not impose the tier model on the whole forest in one GPO link. You grow the tiered structure around the running flat domain — moving privileged accounts and host OUs across one wave at a time — and the surface still running flat (DAs on workstations, service accounts logging on interactively) shrinks toward zero while everyone's access keeps working. Big-bang is the failure mode the pattern exists to prevent: changing every privileged logon right at once is a single blast radius with no incremental rollback, debugged live against every admin in the company.

The mechanism that makes it incremental is scope: a GPO's effect is exactly the OUs (and security-group filters) it is linked and filtered to, so a restriction you author once can be rolled out to one OU, proven, then widened. Concretely, the flat state is tallen (Tier 0) holding Domain Admins and freely RDPing into WS-FIN-01 (Tier 2) — interactive logon is unrestricted, so the DA hash lands in a workstation's LSASS, which is the seam every Module 03–08 attack walks through. The target state is the Module 11 design: Tier 0 accounts denied interactive and RDP logon on Tier 2 hosts (so the hash can never co-locate with untrusted code), and added to Protected Users (no NTLM, no RC4, 4-hour TGT — Kerberoasting and PTH of those accounts removed). A wave is the unit you move: a coherent slice — e.g. "the Tier 0 accounts, denied logon on the pilot Finance OU" — small enough that you can name every admin it touches and coordinate the change. The cutover is linking (or scope-widening) the Deny-logon GPO to that wave's OU and moving its accounts into Protected Users. Because GPO effect is scoped, doing wave 1 changes nothing for the OUs you haven't linked yet — the rest of the domain keeps running flat, untouched, exactly as before.

The discipline that makes it safe is the before/after proof, run per wave, and it asserts two things, not one — "still works" AND "now closed." Before a wave, you record the baseline: which admin reaches which host and how (today: tallen RDPs directly into the Finance box). You cut the wave over. Then you prove (1) no admin is locked out — every account in the wave can still perform its legitimate task, now via the correct tiered path (the admin works from the jump host / PAW-equivalent, not the workstation), because a tiering rollout that locks out the people who run the domain is an outage no matter how secure it is; and (2) the attack path that wave closed is actually dead — re-walk the specific PATH-001 hop the wave targeted (after the Tier 0 Deny-logon wave, dumping WS-FIN-01 no longer yields a DA credential; after the Protected Users wave, the AS-REP/Kerberoast against that account fails) and show it now fails. Both, or the wave isn't done. If lockout assertion (1) fails, you roll back that wave — unlink the GPO from that OU, pull the accounts out of Protected Users — and those admins are working again in minutes while you debug one slice, not a company-wide lockout. The rollback is cheap because the flat domain never went away; you only ever changed scope.

The gotcha

A wave is not done when the admin can log on from the jump host — it's done when the old flat path is closed. If Deny log on through RDS was scoped wrong and the DA can still RDP into the workstation, you've added a tiered path without removing the flat one, and every attacker who lands there harvests a DA credential exactly as in Module 08. The "attack-path-dead" assertion is the one teams skip and the one that matters; an open Deny-that-doesn't-deny is tiering theater.

The honest gotcha that separates a real migration from a checkbox one: the migration is only done when the old flat behavior is closed, not merely when the new tiered path works. It is tempting to declare a wave complete the moment the admin can log on from the jump host — but if Deny log on through Remote Desktop Services was scoped wrong and the DA can still RDP into the workstation, you have added a tiered path without removing the flat one, and every attacker who lands on that workstation can still harvest a DA credential exactly as in Module 08. Assertion (2) — the attack path is now dead — is the one teams skip and the one that matters, because closing the flat logon per-wave is what actually shrinks the breach surface; an open Deny-that-doesn't-deny is tiering theater. Widening the GPO to the whole domain at the end is the final, forest-wide version of that same per-wave close — taken last, when the un-migrated surface is provably zero and you have proven, wave by wave, that nobody gets locked out.

Go deeper: the per-wave proof asserts two things, not one

The half-discipline that fails is proving only "still works." The full proof, run per wave, is (1) no admin locked out — every account in the wave does its job via the correct tiered path — and (2) the attack path that wave targeted is now dead (re-walk the specific PATH-001 hop and show it fails: dumping WS-FIN-01 no longer yields a DA credential; the AS-REP/Kerberoast against the Protected-Users account fails). Both, or the wave isn't done — and if (1) fails, you roll back that one slice, not a company-wide lockout, because the flat domain never went away.

AI caveat

Ask a model to "apply the tier model to Corp" and it hands you a big-bang plan — link the Deny-logon GPO at the root, add every privileged account to Protected Users at once — because that's the simplest thing to express and it doesn't feel the fear of locking out the admin team on a Tuesday. Use it for the bookkeeping (wave checklists, link/unlink commands, proof tables); you sequence by blast radius and you verify both assertions on every wave.

Learn (~3 hrs)

Migration-focused: read enough to understand why a big-bang tier rollout locks people out, how strangler-fig staging de-risks it, and what Microsoft's own phased privileged-access guidance looks like — then go to the lab.

The strangler-fig pattern — why incremental beats big-bang (~15 min) - Martin Fowler — Strangler Fig Application (~15 min) — the original 2001 essay that named the pattern. Read it for the why: gradual replacement around a still-running system de-risks what a one-shot cutover cannot. The metaphor (grow around, retire last) maps one-to-one onto moving privileged accounts into tiers wave by wave while the flat domain keeps serving everyone you haven't moved. This is the mental model the whole module rests on.

Microsoft's own guidance is incremental, not big-bang (~1.25 hrs) - Microsoft — Developing a privileged access strategy (~30 min) — Microsoft's own framing: privileged access is "a journey that must be composed of quick wins and incremental progress" — explicitly not a single cutover. Read the "Building the recommended strategy" and "Strategic initiatives" sections; the "Mitigate Lateral Traversal" initiative ("compromising a single device won't immediately lead to control of many or all other devices") is the PATH-001 break you're rolling out, and the phrasing makes clear the standards-body version of this work is staged. - Microsoft — Implementing Least-Privilege Administrative Models (~45 min) — the canonical AD-specific treatment of why DAs-on-workstations is the core risk and how to separate privileged use from daily use. Read the sections on the risk of using highly-privileged accounts for day-to-day administration and the recommendations to constrain where they log on — this is what each wave moves, and it is the AD-native source behind the Module 11 design you're now deploying.

Scope is the migration lever — GPO targeting (~1 hr) - Microsoft — Deny log on through Remote Desktop Services (User Rights Assignment) (~20 min) — the exact policy you stage. Read the "Best practices" and "Vulnerability / Countermeasure" sections; it states plainly that misapplying this right can deny legitimate administrators access — the precise lockout this module's staged rollout exists to prevent. Pair it with the sibling Deny log on locally page for the interactive-logon half. - Microsoft — Filter Using Security Groups (GPO scope/security filtering) (~15 min) — how you scope a GPO to one pilot wave and widen it: the page states the rule plainly — "settings in a GPO apply only to users and computers… to which the GPO is linked, and that are… in a group specified in Security Filtering." OU link + security-group filter is exactly the knob that turns the big-bang GPO into a staged one (note the gotcha: remove Authenticated Users from Scope, or the filter doesn't actually narrow). The Deny log on through RDS page above also documents the LSDOU processing order (Local → Site → Domain → OU) you rely on. - Microsoft — Protected Users Security Group (~15 min) — the second thing each wave moves. Read the "Protected Users group caveats" section specifically: adding an account breaks NTLM-dependent apps and RC4 logons for it, which is exactly the kind of legitimate-access regression your per-wave "no lockout" proof must catch before you widen.

Key concepts

  • Brownfield is the real job; Module 11 was the greenfield rehearsal — the domain already runs, DAs already log into workstations, the inventory is incomplete. "Apply the tier model" is greenfield advice that does not survive contact with a domain the company logs into every morning.
  • Big-bang GPO linking is the lockout disaster the staging prevents — linking Deny log on through RDS/locally at the root changes every privileged logon right at once: one blast radius, no incremental rollback, debugged live against every admin. The pilot OU and per-wave proof exist because of this.
  • Strangler-fig via GPO scope: pilot, wave, prove, widen — author the restriction once, link it to one pilot OU, move accounts into Protected Users in waves; GPO effect is exactly its linked/filtered scope, so a wave changes nothing for the OUs you haven't reached.
  • The per-wave proof asserts two things, not one — after each wave: (1) no admin is locked out (every account still does its job via the correct tiered path), and (2) the attack path that wave targeted is now dead (re-walk the PATH-001 hop and show it fails). Both, or the wave isn't done.
  • A migration is done when the old flat path is CLOSED, not when the new path WORKS — a Deny-logon scoped wrong that still lets the DA RDP into the workstation is tiering theater; the attacker harvests the credential exactly as in Module 08. Closing the flat logon per-wave is what shrinks the breach surface.
  • Rollback is cheap because the flat domain never left — back a wave out by unlinking the GPO from that OU and pulling accounts from Protected Users; those admins work again in minutes. The forest-wide widening is the irreversible step, taken last, when the un-migrated surface is provably zero.

AI acceleration

A model is genuinely useful at the planning and bookkeeping half of this migration — drafting the wave sequence (which accounts and OUs move in what order), generating the per-wave cutover checklist, writing the GPO link/unlink and Protected Users add/remove commands, and turning your raw before/after logon-test output into a clean per-wave proof table. That is real leverage on the tedious parts. But the posture is strict, because the dangerous instinct is the same one the stressed engineer has: AI drafts the plan → you decide the wave order and own the cutover → you read the before/after proof yourself. Ask a model to "apply the tier model to Corp" and it will cheerfully hand you a big-bang plan — link the Deny-logon GPO at the domain root, add every privileged account to Protected Users at once — because that is the simplest thing to express and it does not carry the operational fear of locking out the whole admin team on a Tuesday. The judgment the model cannot do for you is sequencing by blast radius (which wave is safe to pilot first, which admins it touches, who must be coordinated with, which service account silently logs on interactively and will break), and above all verifying both assertions — a model asked to "confirm the migration worked" will check that the admin can log on from the jump host and call it done, missing both the lockout it caused elsewhere and the open flat path it left behind. Make the model draft the runbook and the logon-test harness; you confirm every wave has a tested rollback, that the proof shows no-lockout AND attack-path-dead, and that the GPO widens to the whole domain only after the last wave is provably across. AI authors the runbook; you own the cutover.

Check yourself

  • Why does linking the Deny-logon GPO at the domain root fail even when the tier design it implements is correct?
  • What two assertions must every wave's proof pass, and why is "the admin can log on from the jump host" not enough?
  • What makes a per-wave rollback cheap, and which single step in the whole migration is the one that isn't?

Comments

Sign in with GitHub to comment. Choose the type: Feedback (errors or suggestions on this page) · Hints (help for fellow learners — no spoilers) · General (anything else).