Oct 19, 2021
If you’re new to Azure Active Directory and Identity and Access Management (IAM), you’ll quickly realize that there are a lot of roles to keep straight. This introduction should help, while also laying the groundwork for my future blog posts on Orca’s research into privilege escalation methods on Microsoft Azure. If you’re already familiar with how Active Directory and IAM work on Azure, then you can review areas you need to freshen up on by jumping to the various sections using the following links:
According to Microsoft documentation, Azure AD is an identity management service, and IAM is used for access control. This means that Azure AD is responsible for authentication, and Azure IAM is responsible for authorization.
We will delve deeper into both of these technologies to properly understand them. But first, let’s take a quick glance at the Azure resource hierarchy terminology:
Tenant Root Group – The top-level management group, which contains all the other management groups and subscriptions in the environment.
Management Groups – Containers that organize subscriptions for better management capabilities, such as policies.
Subscriptions – As the name suggests, a subscription is the billing unit in Azure. Subscriptions contain resource groups and resources and must be connected to a credit card.
Resource Groups – Logical units for resource management. Resources share their lifecycle with the Resource Group.
Resources – Virtual machines, storage blobs, databases, etc.
Azure Active Directory (AAD) is the identity service in Azure environments. An AAD instance is called a tenant and is attached to the root management group. AAD authenticates users and applications and allows them to access resources in Azure.
The following terms are useful for familiarizing yourself with AAD:
User – An identity that represents a worker in the organization
Application Object – A global representation of a software application.
Service Principal – An identity for an application, to allow it perform actions without the user’s involvement. In a cross-tenant application, there will be a service principal in each tenant.
Managed Identity – Logical object that links a service principal object to Azure resource object. There are two types of Managed Identities, User-Assigned and System-Assigned.
Group – A collection of identities, for better permissions management. There are two types of groups in AAD: O365 and Security.
Role – A set of permissions that can be assigned a specific identity. There are different roles for AAD and IAM. In case there is no suitable role for a given set of requirements then there is an option to create a custom role.
Permission – A permission is a string in the following format
There are a variety of AAD roles that are used to manage Azure AD resources. It is essential to understand that there are separate permissions for AAD resources and for Azure resources, and the roles are different. The Azure AD roles grant permissions to manage AD objects (such as users or groups) while the role-based access control (RBAC) roles grant permissions to manage Azure resources (such as storage accounts and virtual machines).
A few examples of roles:
|Role Name||Role Type||Capabilities|
|Global Administrator||Azure AD||Can manage all aspects of Azure AD|
|Application Administrator||Azure AD||Can manage applications identities|
|Global Reader||Azure AD||Can read everything in Azure AD, without the ability to update|
|Contributor||IAM||Can manage all Azure services, without the ability to create role assignments|
|Storage Blob Data Reader||IAM||Read, write, and delete storage
containers and blobs. A great example for a role with DataActions permissions
|Virtual Machine Contributor||IAM||Manage virtual machines, including
disks, snapshots, extensions, and password restoration
The Azure Role-Based Access Control (RBAC) service allows us to manage permissions for resources at any level. Permissions can be granted at the Management Group, Subscription, Resource Group or resource level.
A role is described in its Role Definition and consists of the following fields:
assignableScopes – The level in the hierarchy that the role can be assigned. For example, we can define a role that could be assigned at the Resource Group level only.
actions – Permissions at the resource level, such as creating a VM or deleting a Key Vault.
notActions – Permissions that are not allowed at the resource level. Used mostly in permissive roles, where instead of giving a never ending list of permissions we can exclude the unwanted ones.
dataActions – Permissions at the data level, such as reading data from a Storage Blob or Key Vault. There is a logical division between the services and the user data that is stored in them.
notDataActions – Permissions that are not allowed at the data level.
The effective permissions are the subtraction of NotActions/NotDataActions from Actions/DataActions (respectively).
Let’s look at the role definition of Storage Blob Data Reader as an example.
For the sake of reading the data that is stored in the Storage Blobs, the role grants the read action for Storage Containers. It also grants the read dataAction for Storage Blobs, which is the actual storage unit.
In the image below, there is the role definition of Contributor Role. Contributor Role is a permissive role that allows a variety of actions across many services. Instead of specifying each one of them, there is a ‘*’ and the list of actions it doesn’t allow.
There are many built-in roles, but there is also an option to create custom role definitions to satisfy specific requirements. We can create, for example, a role that grants permission to read all Storage Blobs and Key Vault secrets.
To grant permissions we create a Role Assignment, which is assembled from AAD Identity, Role, and Scope.
Identity – User, Security Group, Service Principal, or Managed-Identity
Role – Built-in or Custom Role
Scope – The hierarchy level to be affected by this Role Assignment
For example, we can create the following Role Assignment:
User – email@example.com
Role – Owner
Scope – Resource Group named Orca-Security
Creation using az cli, the Azure command line interface:
To create the Role Assignment using the portal, navigate to the resource page, in our case the Resource Group. In the IAM blade, add a new Role Assignment.
There are a number of powerful roles in Azure that should not be assigned without careful consideration. If one of these roles is compromised, an attacker has virtually unlimited permissions.
Azure Active Directory Roles & Capabilities
|Application Administrator||Application Administrator can manage applications credentials|
|Cloud Application Administrator||Cloud Application Administrator can manage applications credentials, without the ability to manage proxies|
|User Administrator||User Administrator can manage users and groups, including resetting passwords for limited admins|
|Helpdesk Administrator||Helpdesk Administrator can reset passwords for non-admin users and other Helpdesk Admins|
|Authentication Administrator||Authentication Administrator can reset every authentication method (including passwords) for non-admin users in the AAD|
|Privileged Authentication Administrator||Privileged Authentication Administrator can reset every authentication method (including passwords) for every user in the AAD|
|Password Administrator||Password Administrator can reset passwords for non-admin users and password administrators|
|Global Administrator||Global Administrator has access to all administrative features in AAD and can elevate themself to manage all Azure subscriptions and management groups.
In most teams, this is the Domain Admin of Azure AD.
|Privileged Role Administrator||Privileged Role Administrator can assign themself or others additional roles|
|Groups Administrator||Groups Administrator can create and manage groups in the AAD|
Role-Based Access Control Roles & Capabilities
|Owner||Full management capabilities for all resources, including assigning roles|
|Contributor||Full management capabilities for all resources, without the ability to assign roles|
|User Access Administrator||Manage access to all resources|
|Account Administrator||One of the three classic subscription administrative roles. There is a maximum of one per Azure account. Able to create new subscriptions and manage them.|
|Service Administrator||One of the three classic subscription administrative roles. There is a maximum of one per subscription.
Equivalent to the Owner role in the subscription.
|Co-Administrator||One of the three classic subscription administrative roles. There is a maximum of 200 per subscription.
Same permissions as Service Administrator but can’t change subscription directory association.
Cross-Tenant Access – Sometimes there’s a need to grant permissions to an external party. This can be achieved with a cross-tenant connection.
Guest User – By inviting a user to our tenant, we create an object in our directory to represent the external user. We can grant the user permissions, and they can login to our tenant. Because of the inherent dangers, there are some best practices recommended to manage guest users. The most important ones are allowing only administrators to invite users and limiting guest users’ permissions.
Multi-Tenant Application – A Multi-Tenant Application can use several service principals, one for each tenant. The application can authenticate to its service principal, and use its permissions. There are two kinds of app permissions: delegated and app-only. Delegated permissions give the app the permissions of the logged user and app-only permissions are given directly to the app.
Lighthouse – An Azure service for enhanced management capabilities of multiple tenants. By using it, a user can manage hundreds of customers from a single tenant.
You can synchronize an on-premises deployment of AD with Azure AD by using Azure AD Connect. The advantage of AD Connect is the union of identities between on-prem and the cloud. In many cases, the user won’t need to re-authenticate.
There are three possible sign-in methods in Azure AD Connect:
Password Synchronization – Full sync between the directories. The on-prem password hashes (stored in NTDS.dit) are sent to Azure.
Pass-Through Authentication – In the Azure authentication process
the password is checked against the on-prem AD.
Active Directory Federation – The most complicated synchronization option. Create a Federation trust between Azure AD and your on-prem environment.
You should now have a basic understanding of Azure AD and IAM as they pertain to Azure. More importantly, we have set the stage to talk about some of Orca’s security research and findings in this area.