Entra ID Roles and RBAC

Entra ID roles (formerly Azure AD roles) are a set of built-in and custom roles that control permissions to manage the Entra ID directory itself. They are part of the identity plane, meaning they govern what administrators can do within the directory service—such as creating users, resetting passwords, managing groups, configuring conditional access policies, or assigning licenses. These roles do NOT grant access to Azure resources like virtual machines or storage accounts.

Microsoft provides approximately 60 built-in roles in Entra ID. Each built-in role is a predefined collection of permissions that cannot be modified. For example, the Global Administrator role has the broadest set of permissions, including the ability to reset passwords for all users, manage all directory settings, and assign roles to others. The User Administrator role can create and manage users and groups but cannot delete a Global Administrator or manage enterprise applications. The Privileged Role Administrator can manage role assignments in Entra ID and Azure AD PIM.

Custom roles allow you to define your own set of permissions from a list of over 1,500 individual permissions. These permissions are granular—for example, you can create a role that can only read user sign-in logs but not modify users. Custom roles are useful when built-in roles are too broad or too narrow.

When a user performs an action in the Entra ID portal, Microsoft Graph, or PowerShell, the system evaluates whether the user has a role assignment that includes the required permission. Role assignments are made at the directory level (tenant-wide) by default, but you can also assign roles to specific administrative units (AUs) to scope permissions. For example, you can assign the Helpdesk Administrator role scoped to only users in the 'US' administrative unit, so that helpdesk staff can only reset passwords for US-based users.

The role assignment process involves three components: - Principal: The user or group receiving the role. - Role definition: The set of permissions. - Scope: Where the role applies (tenant, administrative unit, or application).

When a request is made, Entra ID checks if the principal has a role assignment that includes the required permission at the appropriate scope. If yes, access is granted; if no, access is denied.

Azure RBAC (Role-Based Access Control) is an authorization system built on Azure Resource Manager that provides fine-grained access management for Azure resources. It controls who can perform actions on resources such as virtual machines, storage accounts, databases, and virtual networks. Azure RBAC does NOT control access to Entra ID directory settings.

Azure has over 70 built-in roles. The most common are: - Owner: Full access to all resources, including the ability to delegate access to others. - Contributor: Can create and manage resources but cannot grant access to others. - Reader: Can view existing resources but cannot make changes. - User Access Administrator: Can manage user access to Azure resources.

Custom roles allow you to define a set of actions (e.g., Microsoft.Compute/virtualMachines/start/action) that can be performed on a specific resource type. You can also define NotActions to exclude specific actions.

Azure RBAC is evaluated at the Azure Resource Manager level. Every request to create, read, update, or delete a resource goes through ARM, which checks the user's role assignments at the relevant scope. Scopes are hierarchical:

Permissions are inherited from higher scopes. For example, if a user is assigned Contributor at the subscription scope, they automatically have Contributor permissions on all resource groups and resources within that subscription.

When a user makes a request, ARM evaluates all role assignments that apply to the user (either directly or via group membership) at the effective scope. It then checks if any of those role assignments include the required action. If multiple role assignments apply, the union of permissions is granted (except Deny assignments, which take precedence).

| Aspect | Entra ID Roles | Azure RBAC | |--------|----------------|------------| | Controls access to | Entra ID directory (users, groups, apps, tenant settings) | Azure resources (VMs, storage, SQL, etc.) | | Scope | Tenant, administrative unit, application | Management group, subscription, resource group, resource | | Built-in roles | ~60 | ~70 | | Custom roles | Yes, from a list of permissions | Yes, from a list of actions | | Inheritance | Not inherited by default; scoping via AUs | Inherited from higher scopes | | Primary API | Microsoft Graph | Azure Resource Manager |

A common mistake is assigning a user both a broad Entra ID role (like Global Administrator) thinking it will give them Azure resource access. It does not. Conversely, assigning a user Owner at the subscription scope does not give them any Entra ID permissions. To manage both, you need separate role assignments.

PIM is a feature of Entra ID that provides time-based and approval-based role activation for both Entra ID roles and Azure RBAC roles. It reduces standing access by requiring users to activate their role for a limited time (e.g., 1 hour) before they can perform privileged actions. PIM also provides audit logs and alerts. For the exam, remember that PIM can manage both Entra ID roles and Azure RBAC roles, but it is an Entra ID feature.

Azure RBAC supports conditions (via Azure Attribute-Based Access Control, ABAC) that further restrict permissions based on attributes of the resource or request. For example, you can allow a user to read blobs only if the blob index tag equals 'Project=Blue'. This is beyond SC-900 but good to know.

To view role assignments for a user in Entra ID:

Get-AzureADUser -ObjectId user@domain.com | Get-AzureADUserMembership

Or using Microsoft Graph:

GET https://graph.microsoft.com/v1.0/users/{id}/memberOf

To view Azure RBAC role assignments:

Get-AzRoleAssignment -SignInName user@domain.com

In the Azure portal, the 'Roles and administrators' blade under Entra ID shows only Entra ID roles. The 'Access control (IAM)' blade on a resource or subscription shows Azure RBAC roles. This is a common exam hint.

A large enterprise with multiple subsidiaries each has its own Entra ID tenant. The central IT team needs to manage user accounts in each tenant. They cannot use a single set of Entra ID roles across tenants. Instead, they create guest user accounts in each tenant and assign them Global Administrator or User Administrator roles as needed. However, best practice is to use Microsoft 365 Lighthouse (for Managed Service Providers) or cross-tenant synchronization to manage role assignments centrally. Misconfiguration: if a guest user is assigned Global Administrator, they can modify the tenant's directory, which is a security risk. The solution is to use PIM with approval workflows for cross-tenant admin access.

A development team needs to create and manage VMs in a sandbox subscription but should not be able to delete resource groups or modify network security groups. The team is assigned Contributor at the subscription scope, but this allows them to delete resource groups. To limit this, the administrator creates a custom Azure RBAC role that includes only the actions Microsoft.Compute/virtualMachines/* and Microsoft.Network/networkSecurityGroups/read, and assigns it at the subscription scope. This gives developers the ability to create VMs and read NSGs but not delete resource groups. Common pitfall: forgetting to assign the role at the correct scope (e.g., assigning at resource group level instead of subscription) can break access to create resources in other resource groups.

A helpdesk team supports only users in the North America region. The administrator creates an administrative unit called 'North America' and adds all US and Canada users to it. Then they assign the Helpdesk Administrator role to the helpdesk group, scoped to that administrative unit. Now helpdesk can reset passwords only for North American users. If the administrative unit is not created correctly or users are not added, helpdesk may inadvertently gain tenant-wide access (if scoped incorrectly) or have no access. Performance considerations: administrative units can hold up to 100,000 users; beyond that, consider splitting into multiple AUs.