Azure is Microsoft's comprehensive cloud computing platform that offers various services including virtual machines, databases, artificial intelligence, storage, and more. It serves as the foundation for hosting applications and managing infrastructure.
Entra ID (formerly Azure Active Directory or AAD) is a cloud-based identity and access management service that handles authentication and authorization for Microsoft services like Office 365, Azure, and third-party applications. It provides features such as single sign-on (SSO), multi-factor authentication (MFA), and conditional access policies.
Entra Domain Services (formerly Azure AD DS) extends Entra ID by providing managed domain services compatible with traditional Windows Active Directory environments. It supports legacy protocols like LDAP, Kerberos, and NTLM, allowing organizations to run older applications in the cloud without deploying on-premises domain controllers.
Azure Organization Hierarchy
Understanding the hierarchical structure of Azure resources is critical for identifying potential attack paths:
Management Groups: Contains other management groups or subscriptions, allowing governance controls such as RBAC and Azure Policy to be applied and inherited by all subscriptions in the group.
A single directory can support up to 10,000 management groups
Management group trees can be up to 6 levels deep (excluding root level and subscription level)
Each management group and subscription can have only one parent
All subscriptions within a management group must trust the same Entra ID tenant
Subscriptions: Logical containers where resources are deployed and billed.
Parent is always a management group
Can only trust one Entra ID directory
Permissions applied at this level are inherited by all resources inside
Resource Groups: Containers holding related resources that share the same lifecycle.
All resources must be inside a resource group
Resources can only belong to one group
When a resource group is deleted, all resources inside are also deleted
Every resource in Azure has a unique Resource ID with the format: /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/{resourceProviderNamespace}/{resourceType}/{resourceName}
Example for a VM named "myVM": /subscriptions/12345678-1234-1234-1234-123456789012/resourceGroups/myResourceGroup/providers/Microsoft.Compute/virtualMachines/myV
Entra ID Principals and Identity Components
Identity Principals in Entra ID (Azure AD) are security entities that can be authenticated and authorized to access resources.
Principals are the cornerstone of Azure's security model as they represent "who" is trying to access "what" resources. Understanding principals is crucial for red teamers and pentesters as they often represent potential entry points, privilege escalation paths, and persistence opportunities.
Every principal in Azure can:
Be assigned access rights through Azure RBAC roles and Entra ID roles
Be authenticated through various mechanisms (passwords, certificates, tokens)
Have their access restricted through Conditional Access Policies
Leave audit trails in logs when accessing resources
Users
Users are the most basic type of principal, representing human identities in the system.
Types of Users
Members – Regular users within the organization (employees, contractors).
Guests – External users invited from other organizations or personal accounts.
Category
Members
Guests (Default Limited Access)
Directory Read
Can read all users, groups, applications, devices, roles, subscriptions
Limited to own profile only
Group Management
• Create security groups
• Read non-hidden group memberships
• Add guests to owned groups
• Cannot create groups
• Can only see owned group memberships
Application
• Create new applications (configurable)
• Read all applications
Cannot create applications
Device
Can add up to 50 devices (configurable)
Cannot register devices
Guest Invitation
Can invite guests (configurable)
Cannot invite guests by default
Profile
Full access to own profile
Limited access to own profile
Portal Access
Access to admin portal (configurable)
Limited portal access
Resource Access
Requires explicit permissions
Requires explicit permissions
Note: All these permissions can be further restricted by administrators through organizational settings.
Groups
Groups are collections of users and other principals. There are 2 types of groups:
Security: This type of group is used to give members access to aplications, resources and assign licenses. Users, devices, service principals and other groups an be members.
Microsoft 365: This type of group is used for collaboration, giving members access to a shared mailbox, calendar, files, SharePoint site, and so on. Group members can only be users.
This will have an email address with the domain of the EntraID tenant.
There are 2 types of memberships:
Assigned: Allow to manually add specific members to a group.
Dynamic membership: Automatically manages membership using rules, updating group inclusion when members attributes change.
Service Principals
A Service Principal is an identity designed for applications, hosted services, and automated tools to access Azure resources. It functions similarly to service accounts in traditional Active Directory.
Service Principal access is controlled by the roles assigned to it, determining which resources can be accessed and their access levels.
It's possible to directly login as a service principal by generating it a secret (password), a certificate, or granting federated access to third party platforms (e.g. Github Actions) over it.
If you choose password auth (by default), save the password generated as you won't be able to access it again.
If you choose certificate authentication, make sure the application will have access over the private key.
App Registrations
App registrations are the configurations that allow applications to integrate with Entra ID. They are the "blueprint" from which service principals are created.
Key Components:
Application ID (Client ID): A unique identifier for your app in Azure AD.
Redirect URIs: URLs where Azure AD sends authentication responses.
Certificates, Secrets & Federated Credentials: It's possible to generate a secret or a certificate to login as the service principal of the application, or to grant federated access to it (e.g. Github Actions).
If a certificate or secret is generated, it's possible to a person to login as the service principal with CLI tools by knowing the application ID, the secret or certificate and the tenant (domain or ID).
API Permissions: Specifies what resources or APIs the app can access.
Service Principal: A service principal is created when an App is created (if it's done from the web console) or when it's installed in a new tenant.
The service principal will get all the requested permissions it was configured with.
Default Consent Permissions
Consent permissions define how users and administrators approve applications to access organizational data.
Organizations can control whether users can consent to applications requesting permissions to access their data. There are three main settings:
Setting
Description
Security Level
Do Not Allow User Consent
Only administrators can grant consent for applications. This ensures maximum control but increases administrative overhead.
🔒 High
Allow User Consent for Verified and Low-Impact Apps (Recommended)
Users can consent to apps from verified publishers, internal applications, and apps requesting only low-impact permissions.
🟠 Medium
Allow User Consent for All Applications (Default)
Any user can consent to any application requesting access to organizational data. This provides flexibility but increases risk.
🔴 Low
Low-Impact Permissions (Must Be Accepted as Low Impact)
Permission
Purpose
User.Read
Sign in and read user profile
offline_access
Maintain access to granted data
openid
Enable user authentication
profile
View basic user profile information
email
Access the user's email address
Admin Consent Requests
Setting
Description
Default (No Admin Consent Requests Allowed)
Users cannot request administrator approval for apps they are unable to consent to.
Admin Consent Requests Enabled
Organizations can allow users to request admin consent for restricted apps. Admins can define who can approve requests (specific users, groups, or roles) and configure email notifications and expiration reminders for pending requests.
Managed Identities (Metadata)
Managed identities are Azure's solution for secure service-to-service authentication without storing credentials. It's a solution for automatically managing the identity of applications.
This allows to remove the need of hardcoding cloud credentials in the code as the application will be able to contact the metadata service to get a valid token to perform actions as the indicated managed identity in Azure.
There are two types of managed identities:
System-assigned. Some Azure services allow you to enable a managed identity directly on a service instance. When you enable a system-assigned managed identity, a service principal is created in the Entra ID tenant trusted by the subscription where the resource is located. When the resource is deleted, Azure automatically deletes the identity for you.
User-assigned. It's also possible for users to generate managed identities. These are created inside a resource group inside a subscription and a service principal will be created in the EntraID trusted by the subscription. Then, you can assign the managed identity to one or more instances of an Azure service (multiple resources). For user-assigned managed identities, the identity is managed separately from the resources that use it.
Enterprise Applications
It’s just a table in Azure to filter service principals and check the applications that have been assigned to.
It isn’t another type of “application”, there isn’t any object in Azure that is an “Enterprise Application”, it’s just an abstraction to check the Service principals, App registrations and managed identities.
Administrative Units
Administrative Units (AUs) enable organizations to delegate role-based permissions over a specific subset of users, groups, or devices within an organization. This allows for granular administrative control without granting broad tenant-wide permissions.
Entra ID Roles & Permissions
Entra ID provides built-in roles that can be assigned to Entra ID principals to manage various identity-related functionalities.
Privileged Roles: Some roles are marked as PRIVILEGED, meaning they can lead to elevation of privileges if not properly secured. The most privileged role is Global Administrator.
Granular Permissions: Roles group specific permissions, which are listed in their descriptions.
Custom Roles: Administrators can create custom roles with specific permissions, although not all granular permissions are available.
Independence from Azure Roles: Entra ID roles are entirely separate from Azure roles. However, a Global Administrator in Entra ID can elevate to User Access Administrator in Azure.
Wildcard Usage: Wildcards cannot be used in Entra ID roles.
Azure Roles & Permissions
Role Assignment Model
Roles are assigned following the pattern: principal -[HAS ROLE]->(scope)
Principals can be users, groups, service principals, or managed identities
Group role assignments are inherited by all group members
Inheritance Structure
Roles inherit downward through the Azure hierarchy:
Management Groups → Subscriptions → Resource Groups → Resources
Example: A role assigned at subscription level applies to all contained resource groups and resources
Access to a resource requires an explicit role assignment. Deny assignments take precedence over role assignments, preventing access even if a role grants permission.
Deny Assignments
Just like role assignments, deny assignments are used to control access to Azure resources. However, deny assignments are used to explicitly deny access to a resource, even if a user has been granted access through a role assignment. Deny assignments take precedence over role assignments, meaning that if a user is granted access through a role assignment but is also explicitly denied access through a deny assignment, the deny assignment will take precedence.
Just like role assignments, deny assignments are applied over some scope indicating the affected principals and the permissions that are being denied. Moreover, in the case of deny assignments, it's possible to prevent the deny to be inherited by children resources.
Global Administrator
Azure Policies
Azure Policies are rules that help organizations ensure their resources meet specific standards and compliance requirements. They allow you to enforce or audit settings on resources in Azure. For example, you can prevent the creation of virtual machines in an unauthorized region or ensure that all resources have specific tags for tracking.
Azure Policies are proactive: they can stop non-compliant resources from being created or changed. They are also reactive, allowing you to find and fix existing non-compliant resources.
A Policy Definition specifies compliance requirements in JSON format. Policies are applied at a scope, such as a subscription or resource group.
Initiatives group multiple policies for broader enforcement.
Effects define policy actions, such as Deny, Audit, or Append.
Azure policy json example
{
"policyRule": {
"if": {
"field": "location",
"notIn": ["eastus", "westus"]
},
"then": {
"effect": "Deny"
}
},
"parameters": {},
"displayName": "Allow resources only in East US and West US",
"description": "This policy ensures that resources can only be created in East US or West US.",
"mode": "All"
}
Permissions Inheritance
In Azure permissions are can be assigned to any part of the hierarchy. That includes management groups, subscriptions, resource groups, and individual resources. Permissions are inherited by contained resources of the entity where they were assigned.
This hierarchical structure allows for efficient and scalable management of access permissions.
Azure RBAC vs ABAC
RBAC (role-based access control) is what we have seen already in the previous sections: Assigning a role to a principal to grant him access over a resource.
However, in some cases you might want to provide more fined-grained access management or simplify the management of hundreds of role assignments.
Azure ABAC (attribute-based access control) builds on Azure RBAC by adding role assignment conditions based on attributes in the context of specific actions. A role assignment condition is an additional check that you can optionally add to your role assignment to provide more fine-grained access control. A condition filters down permissions granted as a part of the role definition and role assignment. For example, you can add a condition that requires an object to have a specific tag to read the object.
You cannot explicitly denyaccess to specific resources using conditions.
Resources
Below is a quick overview of defult permissions for members and guest. More details can be found on this link:
for a full list of roles.
has several Azure that you can assign to users, groups, service principals, and managed identities.
Organizations can define in and Azure. Custom roles are created within a scope, such as management groups, subscriptions, or resource groups. They can include or exclude specific permissions. Azure roles support wildcards (*) for broad permission assignments. Permissions are categorized into :
This role grants complete control over the Entra ID tenant but does not provide default permissions over Azure resources. A Global Administrator can elevate to User Access Administrator in the Azure Root Management Group, allowing them to manage access across all Azure subscriptions. Elevation can be performed .
