14.2 PIM for Groups, Approval & Audit

From role eligibility to group-based privileged access

Section 14.1 covered eligible vs active assignments and PIM for Entra roles vs Azure resources. Real enterprises rarely assign every privileged role to individuals one-by-one forever. They use groups—especially role-assignable groups—and PIM for Groups so membership itself becomes just-in-time. This section covers PIM for Groups, the request/approval workflow, notifications, audit history, access reviews of privileged access, and the full JIT admin model.

/practice/azure-sc-300Practice questions with detailed explanations

PIM for Groups explained

PIM for Groups (often discussed with privileged access groups) lets you make users eligible for group membership or group ownership, then activate that membership for a limited time under MFA, justification, ticket, and approval settings—parallel to role activation.

Why groups matter for privilege

Role-assignable groups are special: they can be assigned Microsoft Entra roles and have tighter creation controls (isAssignableToRole). SC-300 expects you to know that privileged directory roles are often assigned to a group, and that controlling membership of that group is as important as controlling the role assignment itself.

Eligible membership vs standing membership

Exam cue: “Users should not permanently belong to the group that is assigned Security Administrator” → PIM for Groups eligible membership + activation settings, not permanent group adds.

Configure PIM for Groups (conceptual workflow)

1. Create or identify a role-assignable security group (if directory roles will be assigned to it).
2. Assign the directory role (or Azure RBAC) to the group, not to dozens of individuals, when that is your operating model.
3. Bring the group under PIM for Groups / privileged access group management.
4. Configure member and owner activation settings: max duration, MFA, justification, ticket, approval, notifications.
5. Add users as eligible members (and eligible owners if delegated management is required).
6. Remove standing permanent members who should be JIT only.
7. Test: eligible user activates → appears as member → role effective → activation ends → membership removed.

Ownership activation matters because a permanent group owner can add permanent members and bypass the spirit of JIT. Treat privileged group ownership as carefully as the role itself.

Request and approval workflow

Whether activating an Entra role, an Azure resource role, or group membership, the human flow is a request → (optional) approve → activate → expire pipeline.

End-to-end activation request

1. Discover eligibility — User opens PIM My roles / My groups and sees eligible roles or groups.
2. Request activation — Chooses duration (up to max), enters justification, optional ticket number.
3. Satisfy authentication — Completes MFA (and any CA authentication context requirements if configured).
4. Approval gate (if required):
   • Request enters pending state.
   • Approvers receive notification.
   • Approver approves or denies with reason.
   • On denial, no privilege; on approval, activation proceeds.
5. Active window — User performs privileged tasks; still subject to Conditional Access on sign-ins.
6. Expiration — Automatic removal of role/membership at end of duration; user may request again if still eligible.
7. Extend (if allowed by product behavior and settings) — Treated as a governed re-authorization, not silent infinite access.

Approver design patterns

Anti-pattern: only one Global Administrator who is both the sole eligible admin and the sole approver with no monitoring—approval theater without separation.

Pending requests and operations

Stalled approvals are an operational risk: users escalate for standing permanent access “because PIM is too slow.” Fix the approver roster and SLAs, not by disabling approval on Global Admin.

Notifications

PIM notification settings keep humans in the loop so privilege is never silent.

Exam design answers often include configure alerts/notifications for privileged activations—not only “set eligible.” Pair notifications with SIEM/export of audit logs in larger environments (monitoring chapter).

Analyze PIM audit history

PIM audit history (and related Microsoft Entra audit logs for role assignment activities) answers investigatory questions:

• Who was made eligible or active for Global Administrator last quarter?
• Who activated Privileged Role Administrator at 02:00 UTC, and what justification did they enter?
• Which approver approved a subscription Owner activation?
• When were role settings changed to remove the approval requirement?
• Did a contractor’s eligible assignment end on the contract date?

SC-300 cue: “Investigate who elevated last night” → PIM audit / activation history, not company branding and not only Secure Score.

Correlate with sign-in logs when the question is about how they authenticated (MFA method, location, risk) after or during elevation. Audit tells you privilege state changes; sign-in logs tell you authentication context.

Access reviews of privileged roles and groups

Just-in-time activation does not remove the need to ask: should this person still be eligible at all? That is access reviews applied to privileged access.

What to review

Review outcomes

Recommended cadence for exam-level design: frequent reviews for Global Administrator and Privileged Role Administrator eligibility (for example monthly), slightly longer for lower-privilege admin roles, always with multi-stage or fallback reviewers so reviews complete. Link this to the access reviews chapter: same engine, higher criticality population.

Why reviews fix “eligible forever” drift

Without reviews, every project leaves behind eligible Global Admins “just in case.” Eligibility still expands the set of people who can request elevation (and who might be phished into approving or social-engineering approvers). JIT + reviews beats JIT alone.

The just-in-time admin model (end-to-end)

Assemble the full SC-300 story:

1. Inventory standing privileged assignments (Entra + Azure + privileged groups).
2. Reduce permanent active human admins; convert to eligible.
3. Harden role settings — short duration, MFA, justification, ticket, approval on Tier-0.
4. Use groups thoughtfully — role-assignable groups + PIM for Groups for cohort management.
5. Operate workflow — request, approve, activate, expire; monitor stalled requests.
6. Notify security on elevations and setting changes.
7. Audit activations and assignment changes; export for retention.
8. Review eligibility on a schedule; remove movers/leavers.
9. Complement with Conditional Access for admin portals, Identity Protection risk, and break-glass design (next section).
10. Never use entitlement-management employee packages as a substitute for PIM on Global Administrator.

Common exam traps

• Permanent members of a group that is assigned Global Administrator “because groups are best practice.”
• Turning on PIM but never reviewing eligibility lists.
• Approvers who never receive notifications and ignore pending requests until business demands permanent access.
• Investigating privilege only in sign-in logs while ignoring PIM activation audit.
• Using entitlement management alone for temporary Global Admin.
• Forgetting group owner eligibility can undermine member JIT controls.

Summary of section 14.2

/practice/azure-sc-300Practice questions with detailed explanations