Learn › Exchange Online › 5 · Recipients & permissions

Exchange RBAC

Exchange invented M365's most granular permission model and still runs on it: roles made of cmdlet and parameter grants, grouped into role groups, boxed by scopes — the machinery under every admin action, every app-only connection, and our own read-only runner.

The model in four objects

Management role: a named set of CMDLET+PARAMETER entries (the atom of permission — down to 'may run Set-Mailbox but only the -Type parameter' granularity). Role assignment: role → assignee. Role group: the assignee bundle admins actually use (the ~30 in our nightly scan: Organization Management, Recipient Management, the View-Only family...). Scope: what objects the role bites on — org-wide default, or custom recipient/config scopes (OU-of-cloud-era: filterable recipient scopes for delegated admin).

The property that makes it studyable: what you can run IS the permission — Get-ManagementRoleEntry lists exactly which cmdlets a role grants; the reverse lookup (which roles grant cmdlet X) is one pipe. No other M365 workload lets you audit at verb-and-parameter resolution.

Where it surfaces daily

  • 'The cmdlet isn't recognised' in a delegated admin's session = RBAC, not modules — their roles don't include it, so the session literally doesn't load it.
  • App-only automation: the app's directory role or RBAC-for-Applications assignment resolves to exactly this machinery — the serv365 runner's Get-*-only posture is enforceable BECAUSE roles grant at cmdlet granularity (View-Only style assignments = the constitution as configuration).
  • Purview/Security portals run their OWN RBAC descended from this model — same concepts, separate assignments (the split our Purview scan's RBAC-gated findings documented).

Governance moves

Custom role groups from copied roles MINUS the cmdlets you fear (clone Recipient Management, strip the deletion verbs) — least privilege as subtraction; unscoped Organization Management membership as the crown-jewel audit (it's Exchange's Global Admin); and scopes for regional delegation where AUs don't reach the Exchange plane.

What to watch (proofs)

  • Who holds power: Get-RoleGroupMember across the privileged groups (scan holds the 30 groups; membership export quarterly) — the access review artifact.
  • The reverse lookup on scary verbs: which roles/groups grant Search-Mailbox, New-MailboxExportRequest, Set-TransportRule — every holder justified or removed.
  • App assignments: the service principals' Exchange roles (directory roles + RBAC-for-Applications) — serv365's own footprint is the worked example: enumerable, minimal, documented.
  • Admin-audit correlation: cmdlet writes (admin audit log) joined to the actor's role path — 'could they, and via what grant' as a queryable fact during incidents.

PowerShell for this concept

Discussion

No messages yet — start the thread.

Sign in with your email to join the discussion — we send a one-time link, no password.