Reviewing Azure RBAC role assignments: scopes, Owner sprawl, and custom roles

Principal, role, scope

An Azure role assignment binds a security principal (user, group, service principal, or managed identity) to a role definition at a scope. Scopes nest: management group, subscription, resource group, resource. An assignment at a higher scope is inherited below it. Azure RBAC is additive: a principal’s effective permissions are the union of all its assignments, minus any deny assignments.

Azure RBAC roles control Azure resources. Entra ID roles, such as Global Administrator, control the directory. They are separate systems, though a Global Administrator can elevate to User Access Administrator at the root scope.

Roles to watch

Owner and User Access Administrator can grant access to others, so they are the roles that lead to privilege escalation. Contributor can change almost everything but cannot assign roles. Custom roles with Actions of "*" or Microsoft.Authorization/*/write deserve the same scrutiny as Owner.

Lab: list privileged assignments

In a sandbox subscription, run the Azure CLI commands below to list Owner and User Access Administrator assignments including inherited ones, then list custom roles. For each assignment, record who holds it, at what scope, and whether it should be eligible through PIM instead of permanent.

az role assignment list --all --include-inherited \
  --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='User Access Administrator'].{who:principalName,type:principalType,role:roleDefinitionName,scope:scope}" -o table

az role definition list --custom-role-only true --query '[].{name:roleName,actions:permissions[0].actions}' -o json

Cleaning up

Assign roles to groups instead of individuals, at the narrowest scope that works. Replace permanent Owner assignments with PIM-eligible ones. Remove assignments whose principalName is empty: these often belong to deleted identities and show up as “Identity not found”.