7.1 Implementing & Managing Roles in M365 & Entra ID

Implementing & Managing Roles in Microsoft 365 and Microsoft Entra ID

Microsoft 365 administration rests on two parallel role systems that the MS-102 candidate must distinguish precisely: Microsoft Entra ID roles (the directory roles that power identity and access) and the workload-specific role models inside each service's admin center. Most "Microsoft 365 admin center roles" are, in fact, Entra ID built-in roles surfaced through the M365 admin center UI — Global Administrator, User Administrator, Billing Administrator, Exchange Administrator, SharePoint Administrator, Teams Administrator, Helpdesk Administrator, Security Administrator, and Compliance Administrator all live in Entra ID and are replicated to the M365 portal for convenience.

Entra ID Built-in Roles vs Custom Roles

Entra ID built-in roles are predefined by Microsoft with fixed permission sets. There are over 100 built-in roles today (Microsoft continually adds new ones), organized into categories like Identity, Service administration, and Privileged. Entra ID custom roles (sometimes called "custom directory roles") let you assemble a tailored permission set from the available role-definition actions when no built-in role is a good fit. Custom roles are created in Entra ID (or via PIM) by combining specific microsoft.directory/... actions, and they follow the same assignment model as built-in roles.

Workload-Specific Admin Centers

Beyond Entra ID roles, each workload has its own RBAC layer that grants data-plane permissions inside that workload:

• Exchange admin center uses RBAC role groups (e.g., Organization Management, Compliance Management, Discovery Management, Records Management, View-Only Organization Management). Role groups bundle management roles and are the primary permission container for Exchange Online.
• SharePoint admin center grants SharePoint admin roles (SharePoint Administrator at the tenant level, plus site-level permission levels like Full Control / Design / Edit / Read).
• Teams admin center exposes Teams Administrator, Teams Communications Administrator, Teams Communications Support Engineer, and Teams Communications Support Specialist.
• Purview compliance portal uses role groups such as Compliance Administrator, eDiscovery Manager, and Information Protection.
• Microsoft Defender XDR portal uses Entra security roles plus custom Defender RBAC roles.

Role-Assignable Groups (PAGs)

A role-assignable group (PAG) is an Entra ID group that can be assigned an Entra role. Microsoft's recommended best practice is to assign roles to groups rather than directly to users, then manage group membership to grant or revoke the role. This dramatically simplifies audits and delegation: a new regional admin is added to the "EMEA User Admins" group and immediately inherits the User Administrator role.

To make a group role-assignable, set isAssignableToRole=true at creation time — this property cannot be changed afterward. Both assigned and dynamic membership are supported, though dynamic membership for role-assignable groups requires careful planning because role activation is sensitive to group churn. A role-assignable group must be a security group (Microsoft 365 groups cannot be role-assignable).

Least-Privilege and Global Admin Reduction

The least-privilege principle is a recurring MS-102 theme: give each admin the narrowest role that lets them do their job. Global Administrator is the most powerful role in the tenant — it implicitly can do everything across every workload, and it is the only role that can administer every Microsoft 365 service — so Microsoft recommends fewer than five people holding standing (permanent) Global Administrator assignments in a typical tenant. The guidance is about permanent assignments: making a larger group of admins eligible for the role through PIM, so nobody holds it until they activate, is the pattern Microsoft actually recommends (section 7.4). The rest of your admins should receive scoped roles (User Admin, Security Operator, Compliance Administrator, and so on), ideally delivered through PIM as eligible assignments rather than standing active access.

Global Administrator also automatically gains the Privileged Role Administrator capability in Entra ID, which is the role that manages PIM itself — so granting Global Admin also grants control over who can be made eligible for privileged roles. This is a key reason to keep the Global Admin count low.

Assigning Roles

Roles can be assigned in three ways:

1. Direct user assignment — simple but hard to audit and remove; not recommended for privileged roles.
2. Group-based assignment via a PAG — recommended for standing access; the role is bound to the group and inherited through membership.
3. PIM eligible assignment — recommended for privileged roles; the user activates just-in-time with MFA, justification, and (optionally) approval.

The M365 admin center and Entra admin center both expose role assignment UIs; the Microsoft.Graph PowerShell module and the Microsoft Graph API are the automation path. When you assign a role, you can scope it tenant-wide or — for supported roles — to an Administrative Unit (covered in 7.3). Role assignments can also be time-bound (start and end dates) even outside PIM, but PIM is the recommended governance layer for privileged roles.

Practical Planning

A typical hardened tenant looks like this: 2–3 break-glass Global Administrator accounts stored in a password vault, a PAG named "Tier-0 Admins" whose members are eligible for Global Administrator through PIM, a PAG named "Regional User Admins" whose members hold User Administrator scoped to their respective Administrative Units, and workload-specific role groups in Exchange and Purview for the compliance and messaging teams. No standing admin except the break-glass accounts.