Delegate with Administrative Units and PIM
Scope admin permissions to specific departments with administrative units, and enforce just-in-time access with Privileged Identity Management.
Beyond roles: Scoping and time-limiting admin access
Roles tell an admin WHAT they can do. Administrative units tell them WHERE they can do it. PIM tells them WHEN they can do it.
Think of a hotel chain. A hotel manager role says “you can check guests in and manage rooms.” An administrative unit says “but only at the Auckland location.” PIM says “and only when you clock in for your shift — outside those hours, your keycard doesn’t work.”
Together, these three controls — role + scope + time — create the tightest possible admin access model.
Administrative units: Scoped delegation
What administrative units do
Without AUs, a User Administrator can manage ALL users in the tenant. With AUs, you scope that role to a specific set of users.
| Without AUs | With AUs |
|---|---|
| User Admin can reset passwords for all 20,000 users | User Admin scoped to “Singapore AU” can only reset passwords for the 3,000 Singapore users |
| Help Desk can manage groups across the whole tenant | Help Desk scoped to “Finance AU” can only manage finance department groups |
| No visibility boundaries between regions or departments | Each regional admin sees and manages only their scope |
Priya’s AU design for GlobalReach
GlobalReach has offices in 6 countries. Priya creates administrative units to delegate user management to regional IT teams:
| Administrative Unit | Contains | Scoped Admins | Role |
|---|---|---|---|
| AU-Singapore | 5,000 Singapore users + groups | Singapore IT Lead | User Administrator |
| AU-Sydney | 3,000 Sydney users + groups | Sydney IT Manager | User Administrator, Helpdesk Administrator |
| AU-London | 4,000 London users + groups | London IT Team | User Administrator |
| AU-Tokyo | 3,000 Tokyo users + groups | Tokyo IT Lead | User Administrator |
| AU-Mumbai | 3,000 Mumbai users + groups | Mumbai IT Team | User Administrator |
| AU-New York | 2,000 NY users + groups | NY IT Manager | User Administrator, Groups Administrator |
Now the Sydney IT Manager can reset passwords and manage groups for Sydney users only — they can’t see or modify Singapore users.
Creating and managing AUs
- Create the AU — Entra admin center > Administrative units > New
- Add members — manually select users/groups, or use dynamic membership rules (Entra P1+)
- Assign roles scoped to the AU — select a role, then scope it to the specific AU
- Restrict management — optionally mark the AU as “restricted” so only AU-scoped admins (and Global Admins) can manage its members
Deep dive: Dynamic vs static AU membership
Like groups, AUs support two membership types:
- Static (assigned) — manually add users and groups
- Dynamic — automatic membership based on user attributes
Dynamic AU membership rule example:
(user.country -eq "Australia") and (user.department -ne "Executive")This automatically places all Australian non-executive users in the AU. When someone transfers to Australia, they’re automatically added. When they leave, they’re removed.
Exam note: Dynamic AUs require Entra ID P1 or higher. The exam may ask which licensing is needed for dynamic administrative units.
Privileged Identity Management (PIM)
The problem PIM solves
Without PIM, admin roles are permanently assigned — the account has full admin rights 24/7, whether the person is actively doing admin work or watching Netflix. If the account is compromised, the attacker has standing admin access.
With PIM, roles are eligible — the admin must explicitly activate the role when needed, for a limited time, with optional approval.
PIM concepts
| Concept | What It Means |
|---|---|
| Eligible assignment | User CAN activate the role but doesn’t have it until they do |
| Active assignment | User HAS the role right now (permanent or time-bound) |
| Activation | The process of turning an eligible assignment into an active one |
| Activation duration | How long the role stays active (e.g., 4 hours, 8 hours) |
| Approval required | Whether another admin must approve the activation request |
| MFA required | Whether the user must complete MFA to activate |
| Justification | A reason the admin provides when activating |
PIM workflow example
Elena at MedGuard Health is eligible for Security Administrator but doesn’t have standing access:
- Elena opens PIM — Entra > Identity Governance > Privileged Identity Management
- Requests activation — selects Security Administrator, sets duration to 4 hours
- Provides justification — “Investigating potential phishing incident INC-2847”
- Completes MFA — verifies identity
- Approval — her manager (or a designated approver) approves the request
- Role activates — Elena now has Security Administrator for 4 hours
- Auto-deactivation — after 4 hours, the role is automatically removed
| Feature | Permanent Assignment | PIM Eligible Assignment |
|---|---|---|
| Role availability | 24/7 — always active | Only when activated (just-in-time) |
| Compromise risk | High — attacker gets immediate admin access | Low — attacker must also activate, pass MFA, and get approval |
| Audit trail | Limited — no activation events to log | Rich — every activation is logged with justification |
| Time-bound | No — permanent until removed | Yes — auto-deactivates after configured duration |
| MFA at activation | Not enforced at role use | Can require MFA for every activation |
| Approval workflow | Not available | Configurable — one or two approvers |
| Licensing | Included with Entra ID | Requires Entra ID P2 |
Configuring PIM role settings
For each role, admins configure:
| Setting | Options | Recommendation |
|---|---|---|
| Maximum activation duration | 0.5 to 24 hours | 4-8 hours for most roles |
| Require MFA on activation | Yes/No | Always Yes |
| Require justification | Yes/No | Always Yes |
| Require approval | Yes/No + designated approvers | Yes for high-impact roles (Global Admin, Exchange Admin) |
| Notification | Email on activation/approval | Enable for all roles |
| Eligible assignment expiry | Permanent or time-bound | Time-bound (e.g., 6 months with renewal) |
Exam tip: PIM for Global Administrator
The exam frequently tests PIM configurations for Global Administrator:
- Zero permanent Global Admins (except break-glass accounts) — use PIM for all active Global Admin access
- Require approval for Global Admin activation — a Security Admin or Privileged Role Admin must approve
- Maximum 2 break-glass accounts with permanent Global Admin — these should be cloud-only, excluded from CA policies, and monitored with alerts
- Activation duration — keep it short (4 hours max) for Global Admin
If the exam describes “reducing standing admin access risk,” PIM is almost certainly the answer.
PIM access reviews
PIM integrates with access reviews to periodically verify that role assignments are still needed:
- Who reviews: Self-review, manager, or designated reviewers
- Frequency: Weekly, monthly, quarterly, or one-time
- What happens if not reviewed: Auto-remove (recommended) or no action
- Scope: All eligible assignments, all active assignments, or specific roles
Priya runs quarterly access reviews for all PIM-eligible roles at GlobalReach. If a regional admin hasn’t activated their eligible role in 90 days, the eligible assignment is removed.
Key concepts to remember
Knowledge check
Priya wants the Sydney IT Manager to manage user passwords and groups for Sydney employees only — not for users in Singapore, London, or any other office. Which approach should Priya use?
Elena's organisation requires that Security Administrator access is never standing — admins must activate it when needed, provide a justification, complete MFA, and have their manager approve. The role should auto-deactivate after 4 hours. What should Elena configure?
🎬 Video coming soon
Domain 1 complete! Next up: Domain 2 — Prepare for Identity Synchronization — where hybrid identity begins.