Role-Based Access Control (RBAC) is the backbone of identity governance in Microsoft Azure. It determines who can do what, on which resources, and under what conditions. When configured correctly, it enforces least privilege across your entire cloud estate. When misconfigured, it becomes one of the most exploited attack surfaces in cloud penetration testing engagements.
This blog breaks down Azure RBAC from the ground up, walks through how role assignments work, and exposes the misconfigurations that red teams and attackers actively look for. If you manage Azure environments or are evaluating your cloud security posture, this is essential reading.
If you want a professional assessment of your Azure RBAC posture before an attacker finds the gaps, Redfox Cybersecurity offers cloud penetration testing services built for exactly this.
Azure Role-Based Access Control is a system that provides fine-grained access management for Azure resources. Instead of granting blanket permissions, RBAC allows administrators to define exactly what actions a user, group, service principal, or managed identity can perform on a specific scope.
Azure RBAC is built on three core components: security principals, role definitions, and role assignments.
A security principal is the entity being granted access. In Azure, this can be:
A role definition is a collection of permissions. Azure ships with over 300 built-in roles. The most commonly used ones are:
Custom roles can also be created to express permissions with surgical precision, specifying allowed actions, not-allowed actions (notActions), data-plane permissions (dataActions), and data-plane exclusions (notDataActions).
A role assignment binds a security principal to a role definition at a specific scope. Scope in Azure is hierarchical:
Permissions inherited from higher scopes flow down. A role assigned at the subscription level applies to every resource group and resource within it.
Understanding what is assigned where is the starting point for any security review or pentest. Here are the commands you need.
az role assignment list --all --output table
[cta]
This returns every assignment across the subscription. The output includes the principal, role, and scope columns that matter most during a review.
az role assignment list --assignee <user-or-service-principal-object-id> --output json
[cta]
Replace the placeholder with a specific user's object ID to see all roles that principal holds across every scope.
az role definition list --custom-role-only true --output table
[cta]
Custom roles deserve extra scrutiny. They are often created in a hurry, with wildcard actions that no one remembers adding.
az role assignment list --resource-group <resource-group-name> --output table
[cta]
az role assignment list --all --query "[?roleDefinitionName=='Owner' || roleDefinitionName=='Contributor']" --output table
[cta]
This command is gold during pentesting. A long list of Owners and Contributors tells you the blast radius if any one of those identities is compromised.
If you prefer PowerShell or are working in an environment where the Azure CLI is unavailable, the Az module covers the same ground:
Get-AzRoleAssignment | Select-Object DisplayName, RoleDefinitionName, Scope | Format-Table -AutoSize
[cta]
To filter by role:
Get-AzRoleAssignment | Where-Object { $_.RoleDefinitionName -eq "Owner" }
[cta]
To check a specific user's assignments:
Get-AzRoleAssignment -SignInName user@domain.com
[cta]
This is where things get dangerous. The following misconfigurations are regularly discovered during cloud security assessments. Each one represents a real attack path.
Redfox Cybersecurity's cloud pentesting team encounters these patterns repeatedly across Azure environments of all sizes. Understanding them is the first step toward fixing them.
The Owner role grants the ability to assign roles to other principals. This means an Owner can escalate their own privileges, grant access to external accounts, or add backdoor identities. Many environments have dozens of Owners at the subscription level, often including former employees or service accounts with no documented purpose.
Run this to quantify your exposure:
az role assignment list --all --query "[?roleDefinitionName=='Owner']" --output table
[cta]
If the result has more than a handful of entries, that is a finding worth escalating.
Custom roles sometimes include permissions like:
"Actions": [
"Microsoft.Compute/*",
"Microsoft.Storage/*"
]
[cta]
Wildcard actions defeat the purpose of RBAC. They grant full control over entire resource providers, which is functionally equivalent to Contributor. Audit your custom roles with:
az role definition list --custom-role-only true --output json | grep -i '"actions"' -A 5
[cta]
Review any role definition that uses asterisk wildcards in its action list.
Service principals are application identities. They are supposed to hold scoped permissions relevant to the workload they represent. When a service principal holds Owner or Contributor at the subscription level, a compromised application credential translates directly into full cloud access.
Find these with:
az role assignment list --all --query "[?principalType=='ServicePrincipal' && (roleDefinitionName=='Owner' || roleDefinitionName=='Contributor')]" --output table
[cta]
Any match here warrants immediate investigation.
When a user or service principal is deleted from Azure Active Directory, the role assignment does not automatically disappear. These orphaned assignments appear as unknown principal IDs in the RBAC blade and in CLI output. They create noise in your security posture and, in edge cases, can be abused if object IDs are recycled.
Identify orphaned assignments:
az role assignment list --all --query "[?principalName==null || principalName=='']" --output table
[cta]
Clean these up on a regular schedule as part of identity hygiene.
The User Access Administrator role sounds less dangerous than Owner, but it carries the ability to assign any role, including Owner, to any principal at the scope it is held. This is a privilege escalation path in its own right.
az role assignment list --all --query "[?roleDefinitionName=='User Access Administrator']" --output table
[cta]
Treat this role with the same caution as Owner during reviews.
Management groups sit above subscriptions in the Azure hierarchy. An assignment at the management group level cascades down to every subscription, resource group, and resource underneath. A single overpermissive assignment here has blast radius spanning potentially dozens of subscriptions.
az role assignment list --scope /providers/Microsoft.Management/managementGroups/<management-group-id> --output table
[cta]
Most environments should have very few, carefully documented assignments at this level.
External collaborators (B2B guest users) are sometimes added to Azure AD for temporary purposes and then forgotten. If those guests hold Contributor or Owner roles on critical subscriptions, they represent a standing external attack surface.
az ad user list --filter "userType eq 'Guest'" --output table
[cta]
Cross-reference the guest user object IDs against role assignments to identify which guests hold what access.
During a cloud penetration test, RBAC enumeration is one of the first activities after gaining initial access. An attacker who compromises a low-privilege identity immediately runs enumeration commands to understand what roles are in play and where privilege escalation is possible.
Common escalation chains include:
These are not theoretical. They appear in real environments, and they are found during structured penetration tests.
If you want your Azure environment evaluated before an adversary maps these paths, book a cloud penetration test with Redfox Cybersecurity. The team specializes in cloud-native attack simulation across Azure, AWS, and GCP environments.
Assign roles at the resource group or resource level wherever possible. Avoid subscription-wide assignments unless the use case genuinely requires it.
Azure Privileged Identity Management (PIM) allows roles like Owner and User Access Administrator to be held in an eligible state rather than always-active. Users must activate the role, providing justification and triggering alerts. This reduces standing privilege and improves audit trail quality.
# Check if PIM is enabled for a specific role assignment
az rest --method get --url "https://management.azure.com/subscriptions/<sub-id>/providers/Microsoft.Authorization/roleEligibilitySchedules?api-version=2020-10-01"
[cta]
Azure RBAC now supports conditions that restrict when an assignment is effective. For example, you can scope a Storage Blob Data Contributor assignment to only apply to blobs with a specific tag value. This narrows the blast radius of individual assignments.
Build a scheduled process to review role assignments quarterly at minimum. Focus on:
Use Azure Policy to enforce naming standards and maximum role assignment counts at scale.
Role assignment changes should trigger alerts. Configure Azure Monitor to capture and alert on:
Category: Administrative
OperationName: Microsoft.Authorization/roleAssignments/write
OperationName: Microsoft.Authorization/roleDefinitions/write
Any new Owner assignment at the subscription or management group level should generate an immediate notification to your security team.
Azure RBAC is deceptively simple on the surface and deeply complex in practice. The gap between what organizations think their RBAC posture looks like and what it actually looks like is one of the most consistent findings in cloud security assessments. Wildcard custom roles, orphaned assignments, over-permissioned service principals, and escalation paths through automation accounts are not exotic findings. They are routine.
The commands in this blog give you a starting point for understanding your own environment. But enumeration alone does not surface chained privilege escalation paths, logic flaws in custom role definitions, or attack vectors that cross service boundaries.
That is where a structured penetration test adds irreplaceable value. Redfox Cybersecurity's pentesting services go beyond automated scanning to simulate how a real attacker would move through your Azure environment, identify every exploitable RBAC misconfiguration, and provide a prioritized remediation roadmap.
Your cloud access control posture is only as strong as the last time someone seriously tested it. Make that time now.
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
.avif)
