Case Study 1: Meridian's Domain-Admin Lockdown

"We had spent two years making sure the front door was hard to kick in. Then we counted the people who could open every door in the building, and stopped sleeping." — Sam Whitfield, Security Engineer, Meridian Regional Bank (constructed)

Executive Summary

The Chapter 18 access reviews left Meridian's security team with an uncomfortable number: forty-one accounts had a path to Domain Admin, in a bank with four full-time infrastructure engineers. Most were not even human. None of the powerful credentials were vaulted, none rotated automatically, and the domain admins routinely used those accounts to log into ordinary laptops. In the language of this chapter, Meridian had built an excellent §19.1 escalation ladder for the attacker — a single phished laptop could plausibly become a domain takeover in an afternoon.

This case study follows engineer Sam Whitfield and junior analyst Theo Brandt through Meridian's domain-admin lockdown: the design-and-build project that brought privileged access under control. It is a build-heavy study — the work is architecture and rollout, not log analysis (Case Study 2 is the analysis-heavy counterpart). You will watch the chapter's controls assemble into a single coherent standard: a privileged-account inventory, credential vaulting with check-in rotation, just-in-time access with approvals, a three-tier model with PAWs, session recording, and the detections that make the whole thing visible. The scenario and all figures are constructed for teaching (Tier 3).

Skills applied: privileged-account inventory; credential vaulting and rotation design; just-in-time access and approval-workflow design; tiered administration and PAW deployment; session recording; privileged-abuse detection; phased rollout under operational constraints; break-glass design.

Background

Meridian Regional Bank runs the hybrid environment frozen in this book: an on-prem Windows Active Directory domain (meridianbank.example) with VMware and the legacy core-banking system, plus AWS and a Microsoft 365 / Entra ID tenant. CISO Dana Okafor's program-maturation initiative had, by this point, hardened the network (Chapters 6–7), the hosts (Chapter 11), and authentication (Chapter 16), and had just finished the identity-governance cleanup of Chapter 18 — disabling orphaned accounts and running the bank's first access certification.

That cleanup surfaced the privileged-access problem in stark terms. Elena Vasquez, the GRC analyst, had asked the deceptively simple audit question that PCI-DSS and the FFIEC examiners would also ask: who can administer the systems that hold cardholder data and the core ledger, and how do you control them? The honest answer was a mess. Dana chartered a focused project — the domain-admin lockdown — and gave Sam the lead, with Theo embedded to build the detections. The constraint was explicit and non-negotiable: do not break banking operations, and do not lock the bank out of its own systems during an outage.

🔗 Connection: This project is the direct sequel to Chapter 18's access reviews. Governance found who held privileged access (the inventory) and removed the clearly invalid grants; PAM now takes the valid-but-dangerous remainder and controls how that access is stored, granted, used, and watched. The two disciplines hand off to each other: you cannot lock down privileged accounts you have not inventoried, and an inventory with no lockdown is just a list of things that can hurt you.

The Project

Phase 0 — The inventory (you cannot lock down what you cannot see)

Sam's first move was not to buy a PAM platform. It was to count. Echoing Dana's Chapter 1 instruction — "tell me what we have" — the team built a privileged-account inventory by hunting across every system that could grant administrative power, not just the obvious named admins. Theo ran bluekit's privileged_inventory() against an exported account list to triage by hygiene, and the pair walked the results by hand.

The categories they found, and where they found them:

The eye-opener was the count of accounts with a path to Domain Admin once nesting was resolved: forty-one. Several were the never-owned service accounts — exactly the "invisible admin" problem the chapter's CTF exercise dramatizes. The single identical local-Administrator password across ~900 machines was, Sam noted grimly, "a pre-built lateral-movement highway": compromise any one machine, and the same credential opened the other 899.

⚠️ Common Pitfall (avoided): Theo's first inventory listed only the seven named domain admins. Sam pushed exactly the way the chapter warns: "The named admins are the least of our problems — they're the ones we know about. Find me the service accounts nested into privileged groups, the backup operator, and whoever can administer the SIEM. The dangerous privileged accounts are the ones nobody is thinking about." Resolving group nesting (groups inside groups inside Domain Admins) turned 7 visible admins into 41 real paths.

Phase 1 — Vaulting and rotation (kill the standing shared secret)

With the inventory in hand, the team attacked the cheapest, highest-value win first: the identical local Administrator password. They deployed LAPS (Chapter 11's Local Administrator Password Solution) across all ~900 machines, giving each a unique, random local admin password rotated every 24 hours and stored where only authorized staff could retrieve it. In a single change, the lateral-movement highway was gone: a credential harvested from one machine now worked on exactly that one machine, and was dead within a day.

🛡️ Defender's Lens: This one step — unique, rotated local-admin passwords — is the highest return-on-effort control in the entire chapter, and it requires no commercial PAM platform. It directly breaks rung 4 (lateral movement) of the §19.1 ladder for the most common credential an attacker harvests. If a reader takes only one action from this chapter into a real environment, it should be this.

Next, the domain admin and database accounts went into a credential vault. The team stood up a PAM platform and onboarded the seven domain admin accounts, the four database admins, and the hypervisor admins. The new workflow: an engineer authenticates to the PAM portal with their own identity and FIDO2 key, requests access to a target, and the vault brokers the session with the credential injected, never shown. On check-in, the vault immediately rotates the credential to a 40-character random value no human knows.

The before/after for the domain admin account mirrored the chapter's worked example exactly:

BEFORE: password "Meridian$Admin2023" in a 5-person shared manager + a SharePoint runbook,
        last changed 11 months ago, shared by 7 people, used everywhere.

AFTER:  no human knows the password; access is vault-brokered with the engineer's own
        identity + FIDO2; the credential rotates on every check-in; the audit log records
        "WHITFIELD checked out domain-admin 14:02-14:14 for CHG-4471" instead of the
        anonymous "Administrator did something."

The friction was real and the team did not pretend otherwise. Engineers who had pasted a memorized password for years now had to check one out. Sam's framing to the team mattered: "You're not losing access. You're losing the ability to lose the most dangerous password in the bank."

Phase 2 — Just-in-time access (no standing privilege)

Vaulting controlled the credential; the team still had to kill standing privilege. They moved the seven domain admins from members of Domain Admins to eligible — using a just-in-time activation model (Entra PIM for the cloud roles, an equivalent for on-prem). The default state of every domain admin account became off.

The activation workflow the team designed, rendered as the bank's actual policy:

Meridian privileged-access activation (Tier 0 / Tier 1 roles):

  Requester authenticates to PAM with own account + FIDO2
        |
  Requests role + duration + change-ticket reference (e.g., "domain-admin, 60 min, CHG-4471")
        |
  Tier 0 / Tier 1 role?  ---> YES ---> route to a SECOND engineer for approval
        |                                       |
        |                              approver checks who/why/when
        |                                       |
        |                              approve -> grant, time-boxed, alert SOC
        |                              deny    -> log, no access
        v
  Grant is bounded (Tier 0 max 60 min; Tier 1 max 120 min); auto-revoked at expiry.
  Every activation is logged and bound to a ticket.

The design choices were all defensive and all drawn from §19.3. Approvals routed to a different engineer (separation of duties — no one can self-arm). Maximum windows were deliberately tight (60 minutes for Tier 0, not the 8 hours the vendor defaulted to). MFA was demanded at activation, not just at login, so a stolen session still hit a wall at the moment it tried to become powerful. And every activation carried a change-ticket reference, so an activation with no ticket became a high-fidelity signal for Theo's detections.

The measurable result, after one month, was the number Dana would later show the board: standing domain admin access dropped from 168 hours per admin per week to an average of roughly 3 hours per admin per week of activated access — a ~98% reduction in the window during which a compromised domain admin account would actually wield power.

⚠️ Common Pitfall (caught in testing): The first JIT configuration let any eligible engineer approve any other's activation, and the team realized during a tabletop that two colluding (or two compromised) accounts could approve each other instantly — separation of duties in name only. They fixed it by routing Tier 0 approvals to a small, named approver group with documented accountability, and by alerting when a requester and approver were the same person (which should be impossible, and is therefore a red flag).

Phase 3 — Tiering and PAWs (sever the ladder by architecture)

JIT and vaulting shortened the credential's life and the privilege window. Tiering closed rung 3 — the harvesting — by ensuring the credential was never exposed where an attacker could reach it.

The team partitioned identities and systems into three tiers:

   TIER 0 (control plane): domain controllers, AD, the PAM vault, PKI/CA, Entra ID admin.
   TIER 1 (servers):       core-banking app servers, databases, VMware, business apps.
   TIER 2 (endpoints):     ~900 user laptops and help-desk-managed workstations.

   RULE (enforced, not requested): a higher-tier credential is NEVER used to log on
   to a lower tier. Tier 0 accounts are DENIED logon to Tier 1 and Tier 2 at the OS level.

The painful but essential discipline: each of the seven engineers who administered Tier 0 now had two accounts — an ordinary Tier 2 account for email and daily work, and a separate Tier 0 account used only to administer the control plane, only from a dedicated PAW. The team stood up hardened Tier 0 PAWs: dedicated machines (some physical, some strongly isolated virtual) with application allowlisting (Chapter 11), no web browsing, no email, fully patched, locked down so the usual malware-delivery vectors simply were not present. A domain admin credential, after this, was only ever exposed on a machine that could not do the things that let malware in.

Enforcement was the hard part, and the team took the chapter's warning seriously: tiering on a slide is not a control. They configured logon-restriction policies that actively denied Tier 0 accounts the right to authenticate to Tier 1 and Tier 2 systems, and authentication policies that bound the Tier 0 accounts to their PAWs. Then they had Theo build the detection that would catch any bypass.

🔗 Connection: Tiering and PAWs are defense in depth (the principle from Chapter 3, and Theme 4) applied to administration. Even if vaulting, rotation, and JIT all failed and an attacker captured a live domain admin credential, the architecture guarantees that credential was never sitting on a reachable Tier 2 laptop. The controls are deliberately redundant: none is trusted to hold alone. This is the same layered logic, generalized to every request, that becomes zero-trust architecture in Chapter 32.

Phase 4 — Session recording (accountability + the forensic record)

With privileged access flowing through the vault, the team enabled session recording for all privileged sessions on in-scope systems — every Tier 0 and Tier 1 session, and specifically every session that touched the Cardholder Data Environment. Command-line sessions captured keystroke logs; graphical sessions captured screen recordings; both produced a structured event log, stored where the administrator being recorded could not alter it.

This closed the shared-account accountability gap completely. The vault already recorded which human checked out a shared account; recording now captured what they did with it. For Elena and the auditors, this was the evidence PCI-DSS and SOX expect: a reviewable trail of exactly who administered the sensitive systems and what they touched. For Theo and the future incident responders, it was the highest-fidelity forensic artifact the bank could have — the difference between "we think the attacker may have reached the CDE" and "here is every command they ran."

⚖️ Authorization & Ethics: The team scoped recording deliberately to privileged sessions on sensitive systems — not general employee activity — disclosed it clearly in policy and at logon, and put the recordings themselves behind strict access control (they contain sensitive actions and sometimes sensitive data). Elena reviewed the approach with legal and HR before deployment. Monitoring privileged access is well-established and defensible, but Meridian treated it as a bounded, disclosed control, not as ambient surveillance.

Phase 5 — Detection (assume it all fails)

Every control so far assumes the others might fail — so Theo built the detections that catch privileged abuse when they do. Working with SOC manager Marcus Reyes, he deployed a small set of high-fidelity rules, each exploiting the low, predictable baseline of privileged activity:

Meridian privileged-abuse detections (deployed to the SIEM):

  D1  Out-of-band privileged logon: a Tier 0/1 account authenticates with NO matching
      vault checkout (+/- 2 min).                                  SEVERITY: CRITICAL
  D2  Tier-0 credential on a Tier-2 host: should be impossible
      under enforced tiering (Event 4624/4672 on a non-PAW).       SEVERITY: CRITICAL
  D3  Off-hours / no-ticket JIT activation.                        SEVERITY: HIGH
  D4  New member added to Domain/Enterprise Admins outside JIT
      (Event 4728/4732/4756).                                      SEVERITY: HIGH
  D5  Credential-theft tradecraft on a privileged host: LSASS
      read, NTDS.dit access (via EDR + session monitoring).        SEVERITY: CRITICAL
  D6  ANY break-glass account authentication.                      SEVERITY: CRITICAL (page)

The elegance, as the chapter argues in §19.6, is that the controls created the detections. Before the lockdown, a domain admin logon was one event in an ocean. After it, a domain admin logon that did not come through the vault (D1) is a flare — anomalous by construction, because the vault is now the only legitimate path. Theo tuned the rules over two weeks (the main false-positive source for D1 turned out to be a legacy monitoring agent that authenticated with an over-privileged account — itself a finding, which the team fixed by right-sizing that account's rights).

Phase 6 — Break-glass (the deliberate, monitored exception)

The bank still needed a way in when PAM itself, or the identity provider, or MFA was down — the legitimate case for a break-glass account. Locking the bank out of its own domain during an outage was a real risk the team would not accept. They created two emergency domain admin accounts, stored their long, random passwords offline in a sealed envelope in the data-center safe (and a second copy in a separate secured location), exempted them from the normal workflow only in that they could be used directly in an emergency — but wired detection D6 to page the SOC instantly and unconditionally on any use, and scheduled quarterly tests and rotations.

🔄 Check Your Understanding: Meridian's break-glass accounts are deliberately exempt from the vault-brokered JIT workflow (so they work even when PAM is down), yet the team insists this is not the "backdoor" the chapter warns against. What three properties of Meridian's design keep the break-glass account from being a quiet bypass of everything they just built? (Hint: consider storage, alerting, and testing.)

Outcome

Three months in, Dana presented the lockdown to the board's Audit Committee with three numbers and one sentence. The numbers: forty-one privileged paths reduced and brought under management; standing domain admin access cut by ~98%; the single shared local-admin password (≈900 machines) eliminated. The sentence, which she had borrowed from Sam: "A phished laptop is now a contained incident, not a domain takeover." The FFIEC examiners, who had flagged privileged access the previous cycle, recorded the control as satisfied.

What the project actually bought was the thing this chapter exists to deliver: it severed the §19.1 escalation ladder at multiple rungs simultaneously, on the explicit assumption that the perimeter, the endpoint, and the user would all eventually fail — which, someday, they will.

Lessons and Tradeoffs

The lockdown succeeded, but it was not free, and an honest case study records the costs and the judgment calls alongside the wins. Several lessons are worth carrying into any real PAM program.

Sequencing was a deliberate risk decision, not an accident. Sam fought the instinct to start by buying the biggest commercial PAM platform and "doing it all at once." Instead the team ordered the work by risk reduced per unit of effort and disruption. LAPS came first because it closed the single most-abused lateral-movement path (the shared local-admin password across ~900 machines) for almost no cost and almost no operational friction — a change users never even noticed. The high-friction controls (JIT, tiering, PAWs) came later, after the team had built trust with the infrastructure engineers and proven the program would not break operations. The principle generalizes: when you cannot do everything, do the thing that removes the most attacker capability for the least disruption, and use the early, low-friction wins to earn the political capital the high-friction controls require.

The hardest part was not technical — it was the two-account discipline. Vaulting and JIT were software deployments; tiering was a behavior change for the people the bank most depends on in a crisis. Asking a senior engineer to maintain a separate Tier 0 account and switch to a locked-down PAW — one that cannot browse the web or read email — to do work they used to do from their everyday laptop is a genuine imposition. Two engineers initially resisted, arguing it would slow incident response. The team's answer had two parts. First, they made the PAW genuinely usable (fast, with the admin tools pre-installed and allowlisted) so the friction was minimized rather than dismissed. Second, they reframed the cost honestly: the inconvenience is the price of ensuring that the credential which can deploy ransomware to every endpoint is never sitting on a machine that can catch ransomware. Sam's line — "the PAW is slower because it is safe; that is not a bug" — became the team's shorthand.

Enforcement, not policy, was the line between real and theatrical. Every place the team relied on a written expectation, it later found a violation; every place it relied on a technical control, the expectation held. Tiering "by policy" was violated within days during a routine support task; tiering enforced by OS-level logon restrictions held. The lesson the team internalized — and the one the chapter states in §19.4 — is that a privileged-access control you cannot technically enforce is one you do not actually have. They made it a rule: every control in the standard had to have either a technical enforcement mechanism or a detection that fired when it was bypassed, and ideally both.

The detections paid for the controls. The team had justified the project on prevention, but the detections turned out to be the part the SOC valued most day to day. D1 (out-of-band privileged logon) caught the over-privileged legacy monitoring agent during tuning — a real misconfiguration that had existed for years and that no one had ever noticed, because before PAM there was no baseline of "legitimate privileged access" to deviate from. The controls did not just prevent abuse; by narrowing privileged access to one instrumented path, they manufactured visibility that the bank had never had. This is the relationship between prevention and detection that §19.6 describes, observed in the wild: tightening the legitimate path is itself a detection capability.

What they consciously deferred. The team did not solve the service-account problem in this project, and they said so explicitly. The eighteen privileged service accounts were inventoried and the worst (the never-owned svc-legacy-sync-style accounts) were investigated, but properly vaulting, rotating, and right-sizing non-human credentials is a distinct and larger effort. Dana scoped it as the next project — the secrets-and-machine-identity work — rather than letting it expand the lockdown's blast radius and delay the human-admin wins. Naming what you are deliberately not doing yet, and why, is part of running a program rather than lurching between fires.

Discussion Questions

1. Sam chose to deploy LAPS (unique rotated local-admin passwords) first, before the commercial PAM platform. Defend that sequencing on a risk-and-cost basis. What attack did it close most cheaply, and why was it the right first move even though it does not touch domain admins?
2. The JIT rollout cut standing domain admin access by ~98%. The infrastructure team complained that activation friction slowed routine changes. How would you decide whether the friction is proportionate? What metric distinguishes "meaningful JIT" from "JIT theater"?
3. Tiering forced each Tier 0 engineer to maintain two separate accounts and use a dedicated PAW. This is genuinely inconvenient. Argue both sides: when is this discipline worth the operational cost, and what would you say to an engineer who insists it slows down incident response?
4. The break-glass accounts are a deliberate exception to almost every control in the project. Is this a prudent safety valve or a dangerous loophole? What specific design properties move it from "loophole" to "controlled exception," and how would you test that it has not silently decayed?
5. Theo's detections (D1–D6) became possible because the controls narrowed the legitimate path. Explain this relationship between prevention and detection in your own words, and give one other place in security where tightening a control also improves your ability to detect its abuse.

Your Turn

Take a real or invented mid-size organization with an on-prem AD environment. Reproduce the first three phases of Meridian's lockdown on paper: (1) build a privileged-account inventory of at least eight categories (resolve group nesting — count the paths to admin, not just the named admins); (2) design the vaulting-and-rotation plan, naming what you would do first and why; and (3) design the three-tier model, placing at least six named systems into tiers and stating the enforced logon rule. Then specify two detections you would build and your break-glass design. Keep it to two pages. If you cannot name the owner and justification for a privileged account, flag it — an unowned privileged account is the most dangerous finding on your list.

Key Takeaways

• A privileged-access program starts with an inventory, and the inventory is always larger than the named admins — resolve group nesting and hunt for service accounts, backup operators, and security-tool admins. Meridian's 7 visible domain admins were 41 real paths.
• The cheapest, highest-value win is unique, rotated local-admin passwords (LAPS): it kills the shared-local-admin lateral-movement highway with no commercial platform required.
• Vaulting + check-in rotation ends the standing shared secret and restores individual accountability to shared accounts; JIT with approvals removes standing privilege, collapsing the attack window (~98% at Meridian) and turning the attacker's key move into a noisy, blockable event.
• Tiering + PAWs, enforced by logon restrictions, sever credential harvesting by architecture — so a compromised laptop has no privileged credential to steal. This is defense in depth: it holds even if every other control fails.
• Session recording delivers accountability, audit evidence, and the highest-fidelity forensic record; scope it to privileged access, disclose it, and protect it.
• The controls create the detections. Narrowing privileged access to a single instrumented path makes its misuse anomalous by construction (out-of-band privileged logon). Break-glass is a deliberate, monitored exception — offline, alerting, tested — never a backdoor.
• The whole program exists to turn "a phished laptop becomes a domain takeover" into "a phished laptop is a contained incident" — severing the escalation ladder on the assumption that earlier layers have failed.