I find that getting to understand the differences between Azure AD Roles and Azure RBAC Roles with respect to the following levels are often overlooked or misunderstood:
- Tenant
- Root
- Management group
- Subscription
Those who have not yet had the opportunity to be exposed to larger organizations where multiple subscriptions and the use of management groups for organizing subscriptions may not realize the way in which all these components interact with each other so this blog post serves to provide an overview of them.
Let me begin by providing the official Microsoft documentation for each of the components and note that if you decide to reach all of them then you may not need to read this blog post.
Quickstart: Set up a tenant
https://docs.microsoft.com/en-us/azure/active-directory/develop/quickstart-create-new-tenant
What are Azure management groups?
https://docs.microsoft.com/en-us/azure/governance/management-groups/overview
Microsoft Azure glossary: A dictionary of cloud terminology on the Azure platform – Subscription
https://docs.microsoft.com/en-us/azure/azure-glossary-cloud-terminology#subscription
Associate or add an Azure subscription to your Azure Active Directory tenant
https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-subscriptions-associated-directory
Classic subscription administrator roles, Azure roles, and Azure AD roles (must read)
https://docs.microsoft.com/en-us/azure/role-based-access-control/rbac-and-directory-admin-roles
Note that there isn’t a Microsoft document that explains what the Root level is but the following diagram should explain what and where it sits among the other components:
Notice that I’ve included an on-premise Active Directory in the diagram to denote that domains within the traditional Active Directory Domain Services (AD DS) can be synchronized into Azure AD after they have been added as a custom domain. The user accounts, computer accounts and groups (also known as security principals) that are synchronized into AAD (Azure Active Directory) can be used to assign Azure permissions from various levels of the resources (e.g. Root, manage groups, subscriptions, and resources). As accounts are primarily synchronized from AD DS to AAD and not the other way around, you cannot grant permissions to your on-premise resources with AAD accounts. I’ve also included Office 365 in the diagram to depict how Azure AD roles for SaaS application management (O365, D365, PowerBi, Intune), which I will elaborate later in this blog post.
Azure account and Azure subscriptions
Before jumping into the roles used to manage Azure, it is important to understand that an Azure account represents a billing relationship. This essentially means that an Azure account is all of the following:
- A user identity
- One or more Azure subscriptions
- An associated set of Azure resources.
The administrator who creates the account is the Account Administrator for all subscriptions created in that account as well as the default Service Administrator for the subscription.
Azure subscriptions help administrators accomplish the following:
- Organize access to Azure resource
- Control how resource usage is reported, billed, and paid for (https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/view-all-accounts)
An example can be where there are multiple environments for a project and each environment’s budget should be billed separately for their own Azure consumption. Having multiple subscriptions under the same tenant would allow the access to resources and billing costs to be isolated.
Lastly, each subscription is associated with an Azure AD directory and cannot have more than one even though an Azure AD directly can be associated to more than one subscription. The following is a diagram that depicts the relationship between the Azure AD tenant owner, the subscription and the resources.
The Beginning of Azure – Classic Subscription Administrator Roles
When Azure was first released, access to resources was managed by only the following three administrator roles:
- Account Administrator
- Service Administrator
- Co-Administrator
Those who got into Azure later (after RBAC roles were introduced) will see references to these accounts in the Classic administrators tab:
Or alternatively some CSP subscriptions such as the one below provides the informational message indicating:
This type of subscription does not support classic administrators.
The Evolution of Azure Roles with RBAC
Having only the 3 type of roles to manage the full scope of Azure resources did not scale very well so Microsoft later added Azure role-based access control (Azure RBAC) to provide a more fine-grained access management to resources. Azure RBAC provided 70 built-in roles that could be assigned at different scopes (Management Group, Subscription and Resources), and allows the creation of custom roles. There are four fundamental Azure roles. The first three apply to all resource types:
| Azure role | Permissions | Notes |
| Owner |
|
The Service Administrator and Co-Administrators are assigned the Owner role at the subscription scope
Applies to all resource types. |
| Contributor |
|
Applies to all resource types. |
| Reader |
|
Applies to all resource types. |
| User Access Administrator |
|
The rest of the 66 roles can be found here: https://docs.microsoft.com/en-us/azure/role-based-access-control/built-in-roles Being familiar with these roles is useful for the AZ exams.
While most of the new environments should have move away from the Azure classic deployment model, it is important to note that only the Azure portal and the Azure Resource Manager APIs support Azure RBAC. Users, groups, and applications that are assigned Azure roles cannot use the Azure classic deployment model APIs. I would highly recommend the following document to understand the differences:
Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources
https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/deployment-models
Azure RBAC roles are available throughout the Azure portal via the Access control (IAM) blade for management groups:
… subscriptions:
… resource groups:
… other resources (a disk resource in the screenshot below):
In the Azure portal, role assignments using Azure RBAC appear on the Access control (IAM) blade. This blade can be found throughout the portal, such as management groups, subscriptions, resource groups, and various resources.
What is RBAC?
As a refresh, RBAC abbreviates for Role-Based Access Control, which is used to define what the security principal that is assigned the RBAC role, can perform. The nuts and bolts of how RBAC work in Azure is where a built in or custom role has a definition with a collection of permissions. The definition lists the operations that can be performed and these can include read, write, and delete. One of the ways to review the definition is to use the Get-AzRoleDefinition cmdlet with a specified role such as Contributor as shown below:
PS C:> Get-AzRoleDefinition “Contributor” | ConvertTo-Json
{
“Name”: “Contributor”,
“Id”: “b24988ac-6180-42a0-ab88-20f7382dd24c”,
“IsCustom”: false,
“Description”: “Lets you manage everything except access to resources.”,
“Actions”: [
“*”
],
“NotActions”: [
“Microsoft.Authorization/*/Delete”,
“Microsoft.Authorization/*/Write”,
“Microsoft.Authorization/elevateAccess/Action”,
“Microsoft.Blueprint/blueprintAssignments/write”,
“Microsoft.Blueprint/blueprintAssignments/delete”
],
“DataActions”: [],
“NotDataActions”: [],
“AssignableScopes”: [
“/”
]
}
List Azure role definitions
https://docs.microsoft.com/en-us/azure/role-based-access-control/role-definitions-list?tabs=roles
Note the Actions that are allowed (the * denotes all actions) and the NotActions that are not allowed (granting authorization, elevating access, and Blue Print write and delete).
What are Azure AD Roles? They should not be mistaken for Azure Roles (RBAC)
It is important to recognize that Azure AD roles and Azure roles (RBAC) are not the same. Azure roles are as described from the previous sections, while Azure AD roles are used to manage Azure AD resources in a directory such as create or edit users, assign administrative roles to others, reset user passwords, manage user licenses, and manage domains. Think of them as the traditional Active Directory but a modernized version used in the cloud with a drastically different architecture. The following table describes a few of the more important Azure AD roles.
| Azure role | Permissions | Notes |
| Global Administrator |
|
The person who signs up for the Azure Active Directory tenant becomes a Global Administrator. |
| User Administrator |
|
|
| Billing Administrator |
|
The Azure AD roles can be found in Roles and administrators blade:
The complete list of Azure AD roles can be found here: https://docs.microsoft.com/en-us/azure/active-directory/roles/permissions-reference
Differences between Azure roles and Azure AD roles
Microsoft’s official documentation states that at a high level, Azure roles control permissions to manage Azure resources, while Azure AD roles control permissions to manage Azure Active Directory resources with the following table highlighting some of the differences:
| Azure roles | Azure AD roles |
| Manage access to Azure resources | Manage access to Azure Active Directory resources |
| Supports custom roles | Supports custom roles |
| Scope can be specified at multiple levels (management group, subscription, resource group, resource) | Scope can be specified at the tenant level (organization-wide), administrative unit, or on an individual object (for example, a specific application) |
| Role information can be accessed in Azure portal, Azure CLI, Azure PowerShell, Azure Resource Manager templates, REST API | Role information can be accessed in Azure admin portal, Microsoft 365 admin center, Microsoft Graph, AzureAD PowerShell |
Are there any overlaps between Azure roles and Azure AD roles?
One of the common questions I get asked about Azure roles and Azure AD is whether they overlap and the short answer is no as shown in the diagram I presented earlier:
Azure AD role permissions can’t be used in Azure custom roles and vice versa. The only situation where Azure AD spans into the resources that Azure RBAC roles manage is if a Global Admin elevates their access by activating the Global Admin can manage Azure Subscriptions and Management Groups switch in the Azure portal as shown in the following screenshot:
Access management for Azure resources
Terence Luk can manage access to all Azure subscriptions and management groups in this tenant.
https://docs.microsoft.com/en-us/azure/role-based-access-control/elevate-access-global-admin
Enabling this option will grant the user the Azure RBAC role named User Access Administrator role to all subscriptions for the tenant as shown in the screenshot below:
Notice that there is a Foreign Principal for ‘Tec… labeled above. The subscription in this example was provisioned by the CSP partner Tech Data and by accepting the invite, they were granted Owner permissions to the subscription. It is also important to note that the User Access Administrator role allows the user to grant other users access to Azure resources, which is only a permission an Owner has.
Azure AD and Office 365
Those who work heavily in the Office 365 space will recognize that some Azure AD administrator roles span into Microsoft Office 365. These roles include the Global Administrator role and the User Administrator role. The following is a screenshot of the Roles listed in the Microsoft 365 admin center Roles portal:
This list is can be expanded to show the rest of the non-administrative roles:
Notice how there is a Billing admin in the Microsoft 365 roles. This is the same role as the Billing Administrator in Azure AD and assigning this role in either Azure AD or Microsoft 365 will have the other reflect the same change:
This is also the same for the Global Administrator role in Azure AD and in Office 365:
CSP Permissions for Subscriptions
Having worked for CSP over the past few years, one of the most common questions I get asked by the client we as the CSP is trying to establish a relationship with is what type of permissions are granted when they accept us (the vendor) as the their CSP and the answer is that we are granted Global Administrator and Helpdesk admin roles as shown in the Microsoft 365 admin console screenshot below:
Which can be removed if required:
As well as a Owner as shown in the Azure portal below:
Here are some useful reference documents about this topic:
Azure subscriptions and resource management
https://docs.microsoft.com/en-us/partner-center/customers-revoke-admin-privileges#azure-subscriptions-and-resource-management
Delegated admin privileges in Azure AD
https://docs.microsoft.com/en-us/partner-center/customers-revoke-admin-privileges#delegated-admin-privileges-in-azure-ad
Invite a customer to establish a reseller relationship with you
https://docs.microsoft.com/en-us/partner-center/request-a-relationship-with-a-customer#invite-a-customer-to-establish-a-reseller-relationship-with-you
Transitioning to CSP for Seat-based services
https://docs.microsoft.com/en-us/partner-center/transition-seat-based-services
Multi-partner functions in CSP
https://docs.microsoft.com/en-us/partner-center/multipartner
I hope this blog post has been informative for anyone who may be looking for information about the differences between Azure AD roles and Azure RBAC roles.
