Ultimate Guide to Azure RBAC Troubleshooting

Azure RBAC problems fall into a short list of categories: access denied when permissions should be granted, propagation delays where correct permissions are not taking effect yet, conflicts between overlapping roles or deny assignments, and service principal and managed identity issues that behave differently from human accounts. Knowing which category you are in is most of the diagnosis.

This guide works through each one systematically.

Access denied errors

An access denied error means the identity attempting the operation does not have the necessary permission at the scope where the resource lives.

Check 1: Role assignment scope. RBAC permissions are inherited from parent scopes. A Contributor role at subscription level grants Contributor on all resource groups and resources within it. A Contributor role at a specific resource group does not grant access to other resource groups or subscription-level operations. If a user has a role on a resource group but gets access denied on a subscription-level operation (e.g., viewing billing data), the role needs to be assigned at the subscription level.

# List all role assignments for a user across all scopes
az role assignment list --all --assignee user@company.com \
  --include-inherited --include-groups \
  --query '[].{role:roleDefinitionName, scope:scope}'

Check 2: API permissions vs RBAC. For applications accessing Azure services via SDK or REST API, both RBAC (which controls Azure Resource Manager operations) and API permissions (which control data-plane operations) may be required. An application may have the Reader role on a Key Vault (allowing it to see the Key Vault resource in ARM) but still get 403 errors retrieving secrets, because secret retrieval is a data-plane operation governed by Key Vault access policies or Key Vault RBAC, which are separate from the ARM role. Check both layers.

Check 3: Conditional Access and IP restrictions. Conditional Access policies in Microsoft Entra ID can block access even when RBAC is correctly configured. A user who has the right role but is connecting from an untrusted network or an unregistered device may receive access denied because a Conditional Access policy requires a compliant device or a specific named location. Check the Entra ID sign-in logs for the affected user: Conditional Access policy details appear in the log entry.

Check 4: Deny assignments. Deny assignments block specific actions regardless of what role assignments grant. They take precedence over Allow rules. Check for deny assignments on the resource or its parent scopes:

az role assignment list --scope /subscriptions/{subId} \
  --query "[?roleDefinitionName=='Deny']"

Azure Blueprints and Azure Policy with deployIfNotExists or deny effects can create deny assignments. If a user has the right role but an unexpected deny assignment blocks the operation, the deny assignment takes priority.

Role assignment propagation delays

Role assignments in Azure can take up to 10 minutes to propagate after creation. Managed identity assignments may take longer. If a role was just assigned and access is failing, wait and retry before starting a deeper diagnosis.

To force a credential refresh for a human user in Azure CLI:

az account clear
az login
az account set --subscription {subId}

For service principals, the JWT access token has a fixed validity period (typically 1 hour). If a service principal's role assignment was changed after it acquired a token, the token continues to reflect the old permissions until it expires and is refreshed. For immediate effect, force token refresh in your application or wait for the token to expire.

For managed identities accessing Azure services, the credential is managed by the Azure infrastructure and refreshes automatically, but there is still a propagation delay between the role assignment being created and it being visible to the managed identity.

If delays persist beyond 30 minutes, check the Entra ID Audit Log for the role assignment creation. If the assignment appears in the audit log, propagation is underway. If it does not appear, the assignment creation may have failed silently.

Permission conflicts and overlapping roles

Azure RBAC is additive: a user's effective permissions are the union of all their role assignments. If a user has Reader on a resource group and Contributor on a specific resource within it, they have Contributor on that resource and Reader on everything else in the group.

Conflicts arise when:

A deny assignment blocks an otherwise permitted action. Check for deny assignments as described above. Deny assignments are rare in most environments but are created by Azure Blueprints, landing zone deployments, and certain Azure Policy effects.

A custom role is overly narrow. Custom roles define allowed actions as explicit lists. If the custom role does not include an action that a built-in role would grant, the user gets access denied for that action. Use the Portal's Check Access feature (on any resource, under Access Control (IAM) > Check Access) to see what specific actions a user has and does not have.

PIM eligibility vs active assignment. A user may have an eligible PIM assignment (they can activate the role but have not done so) rather than an active one. Eligible assignments grant no permissions until activated. If a user says "I have the right role" but cannot see the activation in PIM history for their current session, they may have activated the eligibility but the session token has not refreshed to include it. Log out and log back in after activation.

Service principal and managed identity issues

Service principals and managed identities behave differently from human accounts in a few ways that cause common troubleshooting issues.

Object ID vs Application ID. Service principals have both an Application ID (the ID of the app registration) and an Object ID (the ID of the service principal in the specific Entra tenant). Role assignments use the Object ID. When listing role assignments for a service principal, use the Object ID, not the Application ID, or assignments may not appear:

az role assignment list --assignee {objectId}

Multi-tenant service principals. An application registered in Tenant A creates a service principal in Tenant A. If the same application is used in Tenant B, a separate service principal is created in Tenant B. Role assignments in Tenant B's subscriptions must be on Tenant B's service principal object, not Tenant A's application registration.

Managed identity federation. User-assigned managed identities can be shared across multiple resources. A role assignment on the managed identity applies to all resources using it. If permissions need to differ per resource, use separate managed identities.

Just-in-time access for service principals. Service principals do not support PIM activation in the same way humans do. For high-privilege operations (e.g., a deployment pipeline needing temporary elevated access), use short-lived certificates or federated identity credentials rather than long-lived client secrets, and scope the role assignment tightly.

Diagnostic tools in order of usefulness

  1. Check Access (Portal): Navigate to any resource > Access Control (IAM) > Check Access. Select a specific user, group, or service principal. Shows effective permissions, including inherited assignments, and why any action is allowed or denied.

  2. Activity Log: Monitor > Activity Log, filtered to Microsoft.Authorization operations. Shows every role assignment change with caller, timestamp, and result.

  3. Entra ID Sign-in logs: Entra ID > Monitoring > Sign-in logs. Shows authentication failures, Conditional Access decisions, and the specific policy that blocked access.

  4. Azure CLI enumeration:

# What roles does this identity have?
az role assignment list --all --assignee {upn-or-objectid} --include-inherited

# What roles exist at this scope?
az role assignment list --scope /subscriptions/{subId}/resourceGroups/{rgName}

# What are the effective permissions on this resource?
az role definition list --name "Contributor" --query '[].permissions[].actions'
  1. Resource-level IAM blade: For any specific resource, Access Control (IAM) shows all role assignments at that scope plus effective assignments inherited from above.

Where Critical Cloud comes in

RBAC issues in regulated environments are not just operational inconveniences. A service principal with incorrect permissions fails silently in a deployment pipeline. An IAM misconfiguration that takes an engineer hours to diagnose is one that regulators will ask about if it caused an incident. We operate Azure identity and access as part of the managed service, with audited role assignments, PIM access reviews, and RBAC troubleshooting handled as a routine operational function. See how Critical Support works.