RBAC (Role-Based Access Control)

Role-Based Access Control describes provisioning rights to users through assigned roles. Instead of managing individual permissions, you assign roles that bundle related permissions together.

How It Works

Security Principal - Who needs access (user, group, service principal)
Role Definition - What permissions are granted (Reader, Contributor, Owner, custom)
Scope - Where it applies (management group → subscription → resource group → resource)

Azure Roles vs Entra ID Roles

This is a common point of confusion. There are two separate role systems:

Entra ID Roles (Directory Level)

Manage Azure AD/Entra resources
Permissions start with microsoft.directory/*
Examples: Global Administrator, User Administrator, Application Administrator

Azure Roles (Resource Level)

Manage Azure resources (VMs, storage, networks)
Scope starts at subscription level (can be narrowed)
Examples: Owner, Contributor, Reader, custom roles

Application Administrator in Entra ID can manage App Registrations but has zero access to Azure resources by default.

Multiple Role Assignments

If a user has multiple roles assigned to a resource, permissions are merged (additive).

Example: If a user inherits Contributor permissions and you manually assign Reader, they still have Contributor access. Roles don’t subtract—they only add.

The Principle of Least Privilege

You should give users exactly the access they need—no more. RBAC makes this challenging because:

Built-in roles often have more permissions than needed
It’s tempting to assign broad roles for convenience
Custom roles require ongoing maintenance

Recommendation: Use Azure PIM (Privileged Identity Management) for just-in-time access to sensitive roles.

Administrative Units

Administrative Units let you delegate management of specific users or groups to specific administrators. Think of it as scoping Entra ID roles to subsets of your directory.

Use cases:

Regional IT admins managing only their region’s users
Department-specific help desk permissions