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:

The difference between Azure AD and IAM

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.

What is Azure Active Directory ?

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
    <Service>/<resource>/<Action>
    Example: “Microsoft.Compute/disks/read”

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 NameRole TypeCapabilities
Global AdministratorAzure ADCan manage all aspects of Azure AD
Application AdministratorAzure ADCan manage applications identities
Global ReaderAzure ADCan read everything in Azure AD, without the ability to update
ContributorIAMCan manage all Azure services, without the ability to create role assignments
Storage Blob Data ReaderIAMRead, write, and delete storage
containers and blobs. A great example for a role with DataActions permissions
Virtual Machine ContributorIAMManage virtual machines, including
disks, snapshots, extensions, and password restoration

What is Azure IAM?

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 – asmith@orca.security
  • 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.

Important Roles in AAD

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 AdministratorApplication Administrator can manage applications credentials
Cloud Application AdministratorCloud Application Administrator can manage applications credentials, without the ability to manage proxies
User AdministratorUser Administrator can manage users and groups, including resetting passwords for limited admins
Helpdesk AdministratorHelpdesk Administrator can reset passwords for non-admin users and other Helpdesk Admins
Authentication AdministratorAuthentication Administrator can reset every authentication method (including passwords) for non-admin users in the AAD
Privileged Authentication AdministratorPrivileged Authentication Administrator can reset every authentication method (including passwords) for every user in the AAD
Password AdministratorPassword Administrator can reset passwords for non-admin users and password administrators
Global AdministratorGlobal 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 AdministratorPrivileged Role Administrator can assign themself or others additional roles
Groups AdministratorGroups Administrator can create and manage groups in the AAD

Role-Based Access Control Roles & Capabilities

OwnerFull management capabilities for all resources, including assigning roles
ContributorFull management capabilities for all resources, without the ability to assign roles
User Access AdministratorManage access to all resources
Account AdministratorOne 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 AdministratorOne of the three classic subscription administrative roles. There is a maximum of one per subscription.
Equivalent to the Owner role in the subscription.
Co-AdministratorOne 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.

Synchronization with On-Premises AD

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.

Summary

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.

Azure IAM and AD FAQ

What are the Azure AD pros and cons, benefits, and limitations?

Azure Active Directory (AD) is Microsoft’s cloud-based identity and access management (IAM) service; it can be used to manage secure user sign-in to thousands of external services, such as Microsoft Office 365, the Azure portal, and other SaaS applications. Azure AD is also used to manage IAM for internal services, such as a company intranet, corporate network apps, and private cloud apps. Built-in roles can be assigned to allow management of Azure AD res. Administrators can create custom roles, restrict scope of administrative unit control, assign application access, manage eligibility with privileged identity management (PIM), and delegate permissions to distribute identity management tasks.

Pros

  • Microsoft’s Azure AD is a top choice for administrators who need enterprise-level reliability and security beyond the basic requirements of running Microsoft programs, cloud, and on-premise offerings.
  • Microsoft’s zero-trust approach and uptime keep organizations securely operating around the world. This makes it a solid choice to manage security with IAM for cloud-native storage as well as internet-facing systems, users, and devices.

Cons

  • Its popularity makes Azure AD a target for nation-states and threat actors alike. A customer assumes such risk when using Azure and needs to manage it.
  • Microsoft’s shared responsibility model is set up to ensure it is not held responsible for its customers’ cloud security practices. The majority of responsibility falls upon an organization to securely manage its Azure services, data, and users, including critical AD management. Microsoft has added legal caveats to its terms and conditions to protect its liability; hence, a Microsoft cloud customer needs to know their specific cloud security responsibilities and manage their cybersecurity risks accordingly.

Benefits

Azure AD is a beneficial service for Microsoft customers to manage connected users, data, and network security. With IAM helping to oversee potential risk, AD helps streamline secure access to privileged res, data, and systems across the Microsoft cloud.

How does Azure AD authentication work?

Azure AD authentication provides verification of usernames and passwords. It also includes features to enable users and reduce help desk assistance calls. Azure AD authentication includes the following components: 

  • Azure AD multi-factor authentication (MFA)
  • Self-service password reset
  • Hybrid integrations to write and enforce password changes for on-premises environments 
  • Password-less authentication 

These features are combined to securely authenticate user identities.

Where can I find documentation and architectural information?

You can access res on the Azure Active Directory fundamentals section. Or you can find architectural diagrams and technology descriptions for reference architectures using the searchable Browse Azure Architectures library. It also includes solution ideas for common Azure workloads and real-world cloud architecture examples.

How does provisioning work on Azure AD?

To provision Microsoft cloud services, an administrator creates a tenant on Azure AD to manage the specific instance for an organization’s internal and external users. Administrators can leverage the step-by-step instructions in Quickstart: Create a new tenant in Azure Active Directory to set up their tenancy in the Azure portal. Once completed, they can manage users, groups, and group members from the Azure portal. 

What is Azure AD Connect?

Azure AD Connect is an on-premises Microsoft application that manages identities in a hybrid cloud environment; it connects on-premises identity infrastructure to Azure AD. Using a wizard, it deploys and configures components and prerequisites required for the connection – including sync and sign-on. Azure AD Connect includes the functionality released previously as DirSync and AD Sync.

How to use AD Connect

Azure AD Connect is part of the Azure subscription, and is used to help organizations manage identities across hybrid IT environments with federation integration, synchronization, health monitoring, and more. Azure AD Connect can be used to manage automatic synchronization of identity data, specifically between an on-premises Active Directory environment and Azure AD. This allows users to have the same credentials for on-premises applications and cloud services, such as Microsoft 365.