Entra vs Azure RBAC: Why Global Admin Doesn’t Mean What You Think

I’ve been doing a lot of work recently on security and RBAC cleanups, and one thing kept coming up – “We’ve granted person X Global Reader in Entra, but they can’t see anything inside Azure”, or “I’ve got Global Admin, but I can’t set permissions inside Azure.” The misunderstanding between Entra roles and Azure roles is more common than most people admit. Factor in M365 and Defender, and the confusion escalates fast – especially when Microsoft uses the same role names across completely different systems.

In this post I want to cut through that confusion and explain the differences between roles and permissions across these platforms. Understanding where to set what is critical when designing an RBAC model. Without a well-defined approach, administrators either end up with too much access (a security risk) or too little, which just means frustrated people and support tickets.

Two Separate Planes, Two Separate Systems

The first thing to understand is that Azure and Entra are two separate entities. The Microsoft Defender suite is more complicated still, as it spans multiple systems and tools. The one thing all these platforms share is the identity layer, but that’s where the commonality ends.

• Entra ID controls the identity plane: users, groups, applications, and devices. It provides the authentication layer used across all Microsoft cloud stacks.
• Azure RBAC controls the resource plane: subscriptions, resource groups, and resources.
• Microsoft 365 and Defender each have their own roles and controls on top of this.
  

Being a Global Admin in Entra does not automatically grant any rights inside Azure. That’s the core of it, and everything else in this post builds on that foundation.

Entra Roles

At the time of writing there are over 120 built-in Entra roles, 27 of which are classified as privileged. A built-in role is one that exists in every Entra tenant and is managed by Microsoft. A privileged role contains permissions that Microsoft consider to grant a significant level of access, essentially a warning that you should only assign these where genuinely needed. Custom roles can be created where none of the built-in roles fit, though as a general rule I only go down that route when a built-in role would grant access that poses a real security risk.

Entra roles grant access to Entra itself and some tenant-related or Microsoft 365 services. Think of Global Admin as the equivalent of Domain Admin or Enterprise Admin in the traditional Active Directory world, it grants access across the entire tenant and most M365 services, but it does not pass into Azure. Similarly, Global Reader gives read access to everything in Entra and M365, but that doesn’t extend to Azure resources.

It’s also worth calling out that whilst a a Global Administrator can elevate themselves to User Access Administrator at the tenant root scope (if access management for Azure resources is enabled), which allows them to assign Azure RBAC roles.

An Entra role like Security Administrator grants access to security information within Entra and the M365 tenant, but it does not grant Security Administrator access to Azure or the Defender Unified Portal. More on that shortly.

If you’re working with non-human identities such as service principals or managed identities, the same planes apply, I covered this in detail in Entra Workload Identities Explained and Securing Workload Identities in Entra ID.

A full list of Entra roles is available here.

M365 Services

A number of M365-related roles, Exchange Admin, Teams Admin, SharePoint Administrator and others are surfaced as Entra roles, granting access to specific parts of Microsoft 365. Global Admin automatically inherits all of these.

One thing worth noting: certain roles exist within individual M365 services themselves – Exchange being a good example – and these are not replicated back into Entra ID. They’re scoped entirely within that service.

Entra Administrative Units

By default, when you assign an Entra role to someone, the scope is the entire tenant. Sometimes that’s too broad – you might only want a group of administrators to manage a subset of users or groups. That’s where Administrative Units come in.

Think of them as the Entra equivalent of Organisational Units in traditional Active Directory. An Administrative Unit is a container within Entra that holds a subset of the tenant’s resources – users or groups. You can then scope a role, such as Groups Administrator, so it only applies within that container. The result is that those administrators can only manage what’s inside the unit, nothing else.

More detail on Administrative Units is available here.

Azure RBAC – What Controls Azure Resource Access

Azure has its own set of built-in roles, completely independent of anything defined in Entra. The only point where Entra enters the picture is when selecting a user, group, or identity to assign the role to. A full list of built-in Azure roles is available here. The same principle applies as with Entra – only create custom roles when an existing one genuinely doesn’t meet your needs.

Control Plane vs Data Plane

Before going further, it’s worth understanding the difference between the Azure Control Plane and the Azure Data Plane, because this catches people out regularly. Two examples illustrate this well.

Key Vault: When you deploy a Key Vault, you’re managing two separate things – the resource itself (name, region, network configuration, security settings) and the data held within it (secrets, keys, certificates). Roles like Contributor or Owner manage the resource. They do not grant access to the data. I regularly hear “I’ve got Owner access to the Key Vault, but I can’t see any secrets” – that’s because you need a data plane role, such as Key Vault Secrets User, to access the contents.

Storage Account: The same principle applies. Contributor gives you control over the resource configuration, but not the data inside it. To read or write blobs, for example, you’d need a data plane role like Storage Blob Data Contributor alongside it.

Role Definitions: Azure role definitions break permissions into four categories:

• Actions – grants control plane access
• NotActions – restricts control plane access
• DataActions – grants data plane access
• NotDataActions – restricts data plane access
  

NotActions and NotDataActions subtracts (removes) Actions or DataActions from a permission

Understanding which category a permission falls into explains a lot of the “I have access but I still can’t do X” conversations.

Assigning Roles

Roles in Azure can be assigned at four levels:

• Management Group
• Subscription
• Resource Group
• Resource
  

Assignments cascade down the hierarchy – a role granted at a management group applies to all subscriptions, resource groups, and resources beneath it. Getting the balance right between management overhead and over-granting access is a fundamental design decision.

One important nuance: roles in Azure are additive. When multiple roles are granted to the same user, the permissions combine. There are no native deny assignments you can create directly – the exception being deployment stacks, and certain services like Azure Databricks and Azure Policy that create deny assignments automatically to protect managed resources.

If you’re designing this from scratch, the management group hierarchy is a foundational decision – I covered how to structure that properly in Azure Landing Zones with Infrastructure as Code

Defender – The Most Misunderstood of All

The Microsoft Defender suite spans several systems and is constantly evolving, which makes understanding where to grant access genuinely difficult. Microsoft hasn’t helped by reusing the same role names across platforms – Security Administrator in Entra is a completely different thing to Security Administrator in Azure.

There are two distinct Defender products worth separating out.

Microsoft Defender for Cloud

Defender for Cloud provides Azure-native security posture management and is governed by Azure RBAC. You grant roles such as Security Admin or Security Reader at the Azure scope (management group, subscription, resource group, or resource), and these cascade down to child resources in the usual way.

Microsoft Defender XDR

Defender XDR covers endpoints, email, and identity, and is governed by either Entra ID roles or the newer unified Defender roles (more on that below).

A good example of where this causes problems: a SOC analyst with Security Administrator in Entra will not have access to Defender for Cloud resources or configuration. They might see alerts from Defender for Cloud surfaced within the Defender XDR portal, but if they drill into those alerts they’ll hit an access denied – because they have no Azure RBAC role granting visibility into the underlying Azure resources.

Unified RBAC in Defender XDR

Microsoft has been moving away from relying on the broader Entra security roles to control access to Defender XDR, replacing them with a dedicated unified RBAC model built into the Defender XDR portal itself.

This gives much finer-grained control. Rather than all-or-nothing Entra roles, you can now create custom roles scoped to specific workloads – an analyst can have full access to Defender for Endpoint but read-only access to Defender for Office 365 within a single role assignment. Permissions can also be scoped to device groups, which is useful in larger or more complex organisations.

A few things worth knowing before you start:

• It’s opt-in per workload. You activate it deliberately for each Defender product.
• Once activated, legacy Entra roles stop applying to that workload. This is effectively a one-way migration, so plan carefully. Any automation or third-party tooling relying on Entra roles for Defender access could break silently if you don’t account for it.
• Use it as an opportunity. Before transitioning, review your existing roles, do a clean-up, and import them into the new model with purpose rather than just lifting and shifting. Microsoft’s guide for importing existing roles is here.
  

Privileged Identity Management – Just-in-Time Access

This is slightly outside the core scope of this post, but it’s worth calling out. Assigning permanent roles to users and groups is rarely the right approach. Privileged Identity Management (PIM) grants roles only when needed and only for as long as needed – up to a maximum of 24 hours.

PIM works across Entra roles, Azure roles, and can be applied at the role or group level, with different configurations per role. It requires an Entra P2, Entra Governance, or Entra Suite licence.

I’ll cover how to implement PIM across Entra, Azure, and M365 in a follow-up post. In the meantime, Microsoft’s documentation is a good starting point here.

How to Think About It – A Simple Mental Model

Platform	What It Controls
Entra ID	Entra roles grant access to Entra, M365 core admin roles, and Defender XDR (when not using unified roles)
Azure	Azure roles grant access to Azure resources – applied at management group, subscription, resource group, or resource level
M365	Core M365 roles are Entra roles. Individual services like Exchange may have their own internal roles that don’t replicate to Entra
Defender XDR	Governed by Entra roles, or unified Defender RBAC roles when that model has been activated
Defender for Cloud	Governed by Azure roles

—

Summary

RBAC across Microsoft’s cloud services is genuinely complicated. The same role names appear in different portals with different meanings, the interfaces look similar enough to cause confusion, and the products themselves are constantly evolving.

Getting it right matters though. Too much access creates security risk. Too little access creates frustrated administrators and a culture of over-provisioning just to make things work. Getting the balance right between what you lock down and what you leave open is something I explored in When Cloud Guardrails Become Walls – it’s worth a read alongside this one.

Taking the time to define your RBAC model across all platforms – and reviewing it regularly – is one of the most valuable things you can do for the long-term health of your environment. It’s not a set-and-forget exercise.

Hopefully this has helped clear up some of the confusion. If you’ve got questions or have run into specific access issues in your own environment, drop them in the comments below.