Exercises: Privileged Access Management

These exercises move from vocabulary to design judgment. Difficulty is marked ⭐ (recall/application), ⭐⭐ (analysis), and ⭐⭐⭐ (synthesis/open-ended). A dagger (†) marks problems with a full worked solution in Appendix: Answers to Selected Exercises — try every problem before you read one.

Work in your own notebook or a private lab. Where an exercise asks you to "design" or "rank," the reasoning matters more than landing on one canonical answer. Throughout, use only documentation values (meridianbank.example, the 203.0.113.0/24 range) and never a real credential.

Part A — Core vocabulary ⭐

1.† In one sentence each, define privileged account, credential vaulting, just-in-time (JIT) access, tiered administration, and privileged access workstation (PAW). Then write one sentence that uses all five correctly in the context of administering a domain controller.

2. Classify each account as privileged or not privileged, and for the privileged ones name the single most damaging thing an attacker could do with it: (a) a teller's day-to-day login; (b) a domain administrator; (c) a backup operator account; (d) a marketing intern with read access to a public folder; (e) the database sa account; (f) a service account that can modify Group Policy; (g) the account that administers the PAM vault itself.

3. Explain the difference between credential vaulting and password rotation. Why do mature programs use them together rather than choosing one?

4.† Define break-glass account. Give one legitimate reason an organization must have one, and three rules that keep a break-glass account from quietly becoming a backdoor.

5. A colleague says, "We don't need PAM — all our admins already have strong, unique passwords." In two or three sentences, explain why strong unique passwords do not address the threats PAM is built for (reference pass-the-hash and standing access).

6. What is a service account, and why does this chapter only introduce it while pointing forward to Chapter 20 for the full treatment? Name one way a service account differs from a human admin account in how its credential is typically stored.

Part B — Inventory privileged accounts ⭐⭐

7.† You are starting Meridian's privileged-account inventory. List at least eight categories of privileged account you would hunt for across a hybrid (on-prem AD + AWS + M365) environment, and for each, name where you would look to find them. (Hint: the obvious named admins are only the start.)

8. For each account below, state whether it should appear in the privileged inventory and why, then assign it a tier (0/1/2) under the model in §19.4: (a) an account that administers domain controllers; (b) the help-desk account that resets passwords and fixes laptops; (c) the account that administers the core-banking application servers; (d) the account that administers the PKI certificate authority; (e) a standard user account belonging to a senior engineer.

9. A scanner gives you 312 accounts that are members of some administrative group. Describe, in steps, how you would turn that raw list into a prioritized privileged-account inventory. Which attributes (beyond group membership) would you collect for each account, and how would you decide what to lock down first?

10.† Trace the tool. Given this inventory passed to bluekit's privileged_inventory():

accounts = [
  {"name": "DOMAIN\\da-jones", "vaulted": False, "standing": True,  "shared": False, "last_rotated_days": 200},
  {"name": "Administrator",    "vaulted": False, "standing": True,  "shared": True, "recorded": False, "last_rotated_days": 410},
  {"name": "svc-report",       "vaulted": True,  "standing": True,  "last_rotated_days": 30},
]

By hand, list the risk flags each account would receive and the order the function would return them in. State, for the worst account, which rung(s) of the §19.1 escalation ladder its flags most directly enable.

Part C — Harden it (fix the misconfiguration) ⭐⭐

11.† Harden it. A small team's privileged-access setup is described below. Identify every weakness and propose a fix for each, mapped to the right control from this chapter.

- The domain admin password is in a shared password manager known to 5 admins; last changed 8 months ago.
- Every workstation has the same local Administrator password (set by the imaging process).
- Admins use their domain admin accounts to log into their own laptops to check email.
- There is one "emergency" domain admin account; its password is in the same shared manager,
  exempt from rotation, with no alerting on its use.
- No privileged sessions are recorded.

12. Harden it. An organization "deployed JIT" but the configuration below has made it cosmetic. Identify what is wrong and rewrite the policy so JIT is meaningful.

- All admins are eligible for Domain Admins with a maximum activation window of 12 hours.
- Approvals are required, but every admin is also listed as an approver (they approve each other instantly).
- No ticket or justification is required to activate.
- Activations are logged but no alert fires on off-hours activation.

13. Harden it. Tiering exists "on paper": a policy document says admins should not use domain accounts on workstations, but nothing enforces it. List the technical enforcement mechanisms you would add to turn this paper policy into a real control, and name the one detection that should fire if the control is ever bypassed.

14. A PAW is provisioned but the admin has installed a web browser and an email client "to make it convenient." Explain precisely why this destroys the value of the PAW, and what the machine has now become in terms of the §19.1 ladder.

Part D — Design the architecture ⭐⭐–⭐⭐⭐

15.† Design it. Sketch (in words and a simple diagram) a three-tier administration model for Meridian. Place these systems in the right tier and state the logon rule between tiers: domain controllers; the core-banking app servers; user laptops; the AWS IAM root account and high-privilege roles; the PAM vault; the help-desk workstations. For Tier 0, specify the PAW requirement.

16. Design it. Design the privileged-access request flow for Meridian's domain admin role. Specify: who is eligible, what triggers an approval, who approves, the maximum window, what authentication is required at activation, and what gets logged. Draw it as a flowchart (you may adapt Figure 19.2).

17. ⭐⭐⭐ Design it. Meridian's infrastructure team resists PAM: "It will slow down every change and make outages worse." Design a rollout that both delivers the security benefit and addresses their legitimate concerns. Address: the break-glass path for when PAM itself is down; how you phase the rollout (what you vault first); how you keep activation friction proportionate to risk; and how you would measure that the program is working without being theater.

18. Design it. A vendor needs occasional administrative access to one Meridian application server for support. Design a privileged-access arrangement for this third party using the controls in this chapter (vaulting, JIT, session recording, tiering). What is different about a third-party privileged session versus an internal admin's, and what extra controls would you add?

Part E — Write the policy / rule ⭐⭐

19.† Write the policy. Draft a one-paragraph PAM policy statement for Meridian suitable for the security program document: what it covers, the default posture for privileged access (standing vs JIT), the vaulting/rotation requirement, the recording requirement, and the break-glass exception. Write it in plain language a board could read.

20. Write the rule. In pseudocode or plain structured language, write a detection rule that fires when an account is added to a highly privileged group (e.g., Domain Admins) outside the JIT/approval workflow. Specify the trigger, the condition that distinguishes legitimate (JIT-driven) from suspicious additions, the severity, and the response action.

21. Write the rule. Write a detection for out-of-band privileged logon — a privileged account authenticating without a corresponding vault checkout. State the data sources you must correlate, the matching window, why the rule is high-fidelity after PAM is in place, and one false-positive source you would tune out.

22. Write the policy. Draft the break-glass account standard: how many accounts, where the credentials are stored, their composition, the alerting requirement, and the testing/rotation cadence.

Part F — Analyze this / detect abuse ⭐⭐

23.† Analyze this log. The following (illustrative) events come from Meridian's privileged-access and authentication telemetry. All times UTC; source in 203.0.113.0/24. Identify what is most likely happening, which event is the strongest indicator, and which rung(s) of the §19.1 ladder you are seeing.

02:14:07  vault: (no checkout records in this window)
02:14:09  auth: account=DOMAIN\da-smith  logon_type=3  src=ws-1147 (Tier 2 laptop)  result=SUCCESS
02:14:31  auth: account=DOMAIN\da-smith  logon_type=3  src=srv-db-04 (Tier 1)        result=SUCCESS
02:15:02  edr:  host=srv-db-04  alert=LSASS_memory_read by da-smith
02:16:40  auth: account=DOMAIN\da-smith  logon_type=3  src=dc-01 (Tier 0 DC)         result=SUCCESS

24. Analyze this. A JIT system shows that one administrator activated Domain Admins for the maximum window on 19 of the last 20 business days, each time at 08:55, with the justification "daily admin." Is this an attack? What policy failure does it reveal, and what would you change? What would make the same pattern alarming?

25.† Respond to this incident. The out-of-band privileged-logon detection from Exercise 21 fires at 03:00 on a Sunday: DOMAIN\da-smith logged on to a domain controller with no vault checkout and no change ticket. Walk through your first five response actions, in order, and justify each. (This bridges to the incident-response lifecycle of Chapter 24.) Which PAM artifact from this chapter most accelerates your investigation, and why?

26. Analyze this. Your break-glass account fired an alert: it was used at 14:30 on a Tuesday during business hours, and a planned maintenance window is in progress with the PAM system reported "degraded." Is this benign? What do you verify before standing down, and why does every break-glass use get investigated regardless?

Part G — CTF-style challenge ⭐⭐⭐

27.† The invisible admin. During a review you find a service account, svc-legacy-sync, that: is a member of a group nested three levels deep inside Domain Admins; has a password set in 2019 that has never rotated; is not in the PAM vault; runs a scheduled task on six servers; and was created by an employee who left in 2021. No one currently claims to own it, and "we think an application needs it." Lay out the full risk this single account represents (walk the §19.1 ladder), explain why it is so dangerous specifically because it is a non-human account, and propose a safe remediation plan that will not break the unknown application. What would you have to discover before you could safely disable or vault it?

Part H — Interleaved & forward-looking ⭐⭐

28. (Interleaved with Ch.17–18.) Chapter 17 gave you RBAC/ABAC and separation of duties; Chapter 18 gave you the identity lifecycle and access reviews. Explain how PAM depends on both: where does the privileged-account inventory come from, and how does separation of duties show up in the JIT approval workflow? Write a short paragraph connecting all three chapters.

29. (Interleaved with Ch.11.) List three Chapter 11 host-hardening controls that are prerequisites for a trustworthy PAW, and explain what each one prevents on that specific machine.

30. Forward-looking. This chapter says JIT is "the first concrete step toward zero trust" (Ch.32). Based only on what you have learned here, write two sentences predicting what "never trust, always verify" might mean when applied not just to privileged access but to every access request.

31. ⭐⭐⭐ Open reflection. PAM imposes real friction on the people the organization most depends on in a crisis (its administrators). Write half a page on how you would balance security against operational resilience — the risk that locking down privileged access too hard could make a real outage worse. Where is the line, and what makes a break-glass design trustworthy rather than a loophole?

Solutions to daggered (†) problems are in the Answers appendix. The remaining problems are deliberately open — bring them to a study group or your instructor.