Case file 01
Privileged access you can explain
Architecture · Who, what, how, where
- Privileged identityMarcus Reed (Admin), separate from his workforce account
- User AdministratorBuilt-in role instead of broader authority
- PIM eligibleJust-in-time, no standing assignment
- AU-New YorkAdministrative Unit boundary
- New York identitiese.g. Jennifer Parker
Implementation
Separated workforce and privileged identities
Marcus Reed has a normal workforce account for daily work and a dedicated admin identity for IAM tasks, so routine activity never runs with privileged credentials.
Two emergency-access accounts
EA-01 and EA-02 hold Global Administrator for recovery only, with authentication and sign-in baselines reviewed.
Role is what.
Scope is where.
A Microsoft Entra role decides what an administrator can do. An Administrative Unit decides where they can do it. Least privilege needs both, so Marcus's User Administrator role only reaches AU-New York.
Delegated administration with an Administrative Unit
AU-New York sets a boundary around New York identities. The role says what an admin can do; the unit says where.
Least privilege on two axes
User Administrator scoped to AU-New York limits both the level and the reach of Marcus's authority.
PIM eligibility instead of standing access
The scoped role is assigned as PIM eligible, so privilege is activated when needed rather than held permanently.
Troubleshot a failed PIM assignment, then cleaned up
Audit logs surfaced a RoleNotFound condition. Microsoft Graph was used to inspect the role definition and eligibility schedules. Temporary privilege and Graph PIM write permission were removed after remediation.
Security principles applied
| Identity separation | Workforce and admin identities for the same person |
|---|---|
| Least privilege | User Administrator, not a broader role |
| Administrative scoping | Role limited to AU-New York |
| Reduced standing privilege | PIM eligible assignment |
| Emergency access | Two break-glass Global Administrators |
| Privilege cleanup | Troubleshooting access revoked afterwards |
Results
- A privileged-access model that answers who, what role, how it is granted, and where it applies.
- A documented failure, investigation and remediation path: failure, evidence, investigation, remediation, validation, cleanup.
- The environment returned to least privilege after troubleshooting.
Lessons learned
- Role and scope solve different problems.
- Administrative Units set administrative scope; they do not grant application access.
- Temporary privilege used for troubleshooting must not silently become permanent.
What this does not prove
- Cloud-only educational lab, not a production deployment.
- Cashville Financial Group and its people are fictional lab scenarios.