Correct PIM-for-Groups credential-protection scope: eligible members and owners are protected - #2049
Conversation
|
Learn Build status updates of commit e058d87: ✅ Validation status: passed
For more details, please refer to the build report. |
|
@microsoft-github-policy-service agree |
|
Mike Crowley (@Mike-Crowley) : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. Ken Withee (@kenwith), Amson Liu (@amsliu) |
|
Mike Crowley (@Mike-Crowley) : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change. Ken Withee (@kenwith), Amson Liu (@amsliu) |
|
Ken Withee (@kenwith) Amson Liu (@amsliu) Can you review the proposed changes? Important: When the changes are ready for publication, adding a #label:"aq-pr-triaged" |
There was a problem hiding this comment.
Pull request overview
Updates Microsoft Entra Privileged Identity Management (PIM) for Groups documentation to reflect that credential-protection for role-assignable groups applies to eligible members/owners (not only active ones), and to remove a stale example about Helpdesk Administrator capabilities.
Changes:
- Rewords the PIM-for-Groups include note to focus on role-assignability as the control boundary (instead of a specific Helpdesk Administrator example).
- Updates the PIM for Groups concept article to state credential protection applies to eligible members and owners (before activation) for role-assignable groups.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| docs/includes/pim-for-groups-include.md | Rewords the security note to remove a stale Helpdesk Administrator example and emphasize role-assignable groups. |
| docs/id-governance/privileged-identity-management/concept-pim-for-groups.md | Updates the role-assignable-group protection description to include eligible members/owners (before activation). |
| > For groups used for elevating into Microsoft Entra roles, we recommend that you require an approval process for eligible member assignments. Assignments that can be activated without approval can leave you vulnerable to a security risk from less-privileged administrators, who might be able to reset a user's credentials and then activate the assignment on their behalf. | ||
| > | ||
| > Confirm that groups used for role elevation are created as [role-assignable](~/identity/role-based-access-control/groups-concept.md). Only the Privileged Authentication Administrator and the Global Administrator can change the credentials of members and owners of a role-assignable group. |
There was a problem hiding this comment.
Good catch on both — taken in e2ad34b.
Bumped ms.date to 07/29/2026, and replaced "Only the Privileged Authentication Administrator and the Global Administrator can change the credentials..." with the canonical phrasing from groups-concept.md:
You must be assigned at least the Privileged Authentication Administrator role to change the credentials of members and owners of a role-assignable group.
You were right that "only" was wrong, and for a reason beyond the inconsistency: the Who can reset passwords matrix notes that the (deprecated) Partner Tier2 Support role can also reset credentials for administrators, so an absolute "only X and Y" is inaccurate regardless. "At least" avoids that and keeps the two articles consistent.
| Role-assignable groups benefit from extra protections compared to non-role-assignable groups: | ||
|
|
||
| - **Role-assignable groups** - only the Global Administrator, Privileged Role Administrator, or the group Owner can manage the group. Also, no other users can change the credentials of the users who are (active) members of the group. This feature helps prevent an admin from elevating to a higher privileged role without going through a request and approval procedure. | ||
| - **Role-assignable groups** - only the Global Administrator, Privileged Role Administrator, or the group Owner can manage the group. Also, no other users can change the credentials of the users who are members or owners of the group. This protection also covers principals who are eligible for membership or ownership of the group through PIM, before activation. This feature helps prevent an admin from elevating to a higher privileged role without going through a request and approval procedure. |
There was a problem hiding this comment.
Agreed — reworded in 5d2125f. Dropped "principals" and the separate follow-on sentence, and used consistent member/owner terminology as suggested:
Also, no other users can change the credentials of the members and owners of the group, including eligible members and owners who haven't activated yet.
That also collapses my original two sentences into one, which reads better next to the parallel non-role-assignable bullet below it.
|
Ken Withee (@kenwith) Amson Liu (@amsliu) — both review comments addressed in e2ad34b and 5d2125f; details in the threads above. Diff is now +5/-3 across the two files. One thing worth raising directly, since it's the part only the product team can settle: was this behavior remediated at some point? The wording change is downstream of a measurement, not a style preference. A tenant-scoped Helpdesk Administrator was denied That contradicts the note as written, and it also means Rogier Dijkman's April 2022 MSRC report no longer reproduces. If the platform was hardened between 2022 and now, a line in the article confirming that would be worth more than my rewording — it would let people stop designing around a gap that's been closed. If instead the note was written for the nested case (a non-role-assignable group as an eligible member of a role-assignable group, per Compass Security, March 2026), then please keep the warning and scope it explicitly — the current phrasing gives no hint that nesting is the operative condition, which is precisely how I misread it. Either outcome is a good one from my side; I'm not attached to my wording. Caveats stand: commercial cloud only, Helpdesk Administrator only, Graph only. |
|
Learn Build status updates of commit e2ad34b: ✅ Validation status: passed
For more details, please refer to the build report. |
PRMerger Results
|
|
Learn Build status updates of commit 5d2125f: ✅ Validation status: passed
For more details, please refer to the build report. |
PRMerger Results
|
Summary
Two related statements about credential-management protection for PIM for Groups appear to describe platform behavior that no longer exists. Both currently read as saying that a user who is only eligible for membership in a role-assignable group is exposed to password reset by a less-privileged administrator. Testing against a live tenant shows they are protected.
Issues are disabled on this repo, so I'm raising this as a PR. I'd genuinely welcome the product team correcting me — if the original statements are still accurate in some configuration I didn't cover, the right fix is to scope them rather than take my wording.
What the docs currently say
docs/includes/pim-for-groups-include.md(transcluded intoconcept-pim-for-groups.mdandidentity/role-based-access-control/groups-concept.md):docs/id-governance/privileged-identity-management/concept-pim-for-groups.md:The parenthetical implies eligible members fall outside the protection, and the note states a specific capability for the Helpdesk Administrator.
What I measured
Commercial cloud, 2026-07-28. Attacker was a real tenant-scoped Helpdesk Administrator in a separate delegated session (not app-only auth, not a reused admin token). Reset attempted via
PATCH /v1.0/users/{id}withpasswordProfile.All denials returned
Authorization_RequestDenied/ "Insufficient privileges to complete the operation." Controls T1 and T7 succeeded, confirming the attacker genuinely held effective Helpdesk Administrator; T2 and T4 were denied, confirming the protection logic was active during the run.T5 and T9 are the cells that contradict the current text. T3 additionally shows the protection covers direct PIM role eligibility, which isn't documented anywhere I could find.
Why I think the text is stale rather than wrong-from-birth
The include file carries
ms.date: 01/31/2023and its body hasn't had a content edit since the PIM-for-Groups launch. Rogier Dijkman documented a real bypass in this area (reported to MSRC April 2022, published January 2023) — an eligible owner of a Privileged Access Group reset by a User Administrator. That doesn't reproduce today either (T9 covers the Helpdesk variant).So the most likely history is that the platform was hardened between 2022 and now and the documentation was never revisited. If that's right, a note in the article confirming the remediation would be more valuable than the wording change alone.
What this PR changes
Deliberately conservative — I did not delete the security recommendation, because removing a caution on the strength of one tenant's results would be the wrong direction if I've missed a configuration.
docs/includes/pim-for-groups-include.md— keeps the approval-process recommendation and the "less-privileged administrators" risk framing, but replaces the specific Helpdesk Administrator claim with a pointer to the control that actually governs this: role-assignability. Adds a sentence naming Privileged Authentication Administrator / Global Administrator as the roles that can change those credentials, consistent with the Who can reset passwords matrix.concept-pim-for-groups.md— removes the(active)qualifier on the role-assignable bullet and states that the protection also covers PIM-eligible members and owners. Left the parallel(active)on the non-role-assignable bullet alone, since it's inert there.Scope limits — please read before merging
Why this matters beyond wording
Reading these two passages literally led me to file cisagov/ScubaGear#2072 against a CISA federal baseline, reporting an escalation path that doesn't exist. A Microsoft engineer spent time trying to reproduce it and correctly could not. At least one third party has since merged a detection rule built on that issue. The documentation understates the protection Entra actually provides, which is the safe direction for a security doc, but it still produced a false vulnerability report and downstream work.