Az - Basic Information
Organization Hierarchy
Management Groups
If your organization has many Azure subscriptions, you may need a way to efficiently manage access, policies, and compliance for those subscriptions. Management groups provide a governance scope above subscriptions.
Note that 10,000 management groups can be supported in a single directory and a management group tree can support up to six levels of depth.
From the docs: Each directory is given a single top-level management group called the root management group. The root management group is built into the hierarchy to have all management groups and subscriptions fold up to it. This root management group allows for global policies and Azure role assignments to be applied at the directory level. The Azure AD Global Administrator needs to elevate themselves to the User Access Administrator role of this root group initially. After elevating access, the administrator can assign any Azure role to other directory users or groups to manage the hierarchy. As administrator, you can assign your own account as owner of the root management group.
The root management group can't be moved or deleted, unlike other management groups.
Management groups give you enterprise-grade management at scale no matter what type of subscriptions you might have. However, all subscriptions within a single management group must trust the same Azure Active Directory (Azure AD) tenant.
Azure Subscriptions
In Azure, a subscription serves as a logical container for the purpose of provisioning business or technical resources. This container maintains the details of resources such as virtual machines (VMs), databases, among others. Upon the creation of an Azure resource, like a VM, the subscription associated with it is specified. This structure facilitates the delegation of access, utilizing role-based access-control mechanisms.
Resource Groups
From the docs: A resource group is a container that holds related resources for an Azure solution. The resource group can include all the resources for the solution, or only those resources that you want to manage as a group. Generally, add resources that share the same lifecycle to the same resource group so you can easily deploy, update, and delete them as a group.
All the resources must be inside a resource group and can belong only to a group and if a resource group is deleted, all the resources inside it are also deleted.
Administrative Units
From the docs: Administrative units let you subdivide your organization into any unit that you want, and then assign specific administrators that can manage only the members of that unit. For example, you could use administrative units to delegate permissions to administrators of each school at a large university, so they could control access, manage users, and set policies only in the School of Engineering.
Only users, groups and devices and be members of an administrative unit.
Therefore, an Administrative unit will contain some members and other principals will be assigned permissions over that administrative unit that they can use to manage the members of the administrative unit.
Azure vs Azure AD vs Azure AD Domain Services
It's important to note that Azure AD is a service inside Azure. Azure is Microsoft's cloud platform whereas Azure AD is enterprise identity service in Azure. Moreover, Azure AD is not like Windows Active Directory, it's an identity service that works in a complete different way. If you want to run a Domain Controller in Azure for your Windows Active Directory environment you need to use Azure AD Domain Services.
Principals
Azure support different type of principals:
User: A regular person with credentials to access.
Group: A group of principals managed together. Permissions granted to groups are inherited by its members.
Service Principal/Enterprise Applications: It's an identity created for use with applications, hosted services, and automated tools to access Azure resources. This access is restricted by the roles assigned to the service principal, giving you control over which resources can be accessed and at which level. For security reasons, it's always recommended to use service principals with automated tools rather than allowing them to log in with a user identity.
When creating a service principal you can choose between password authentication or certificate authentication.
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.
Managed Identity (Metadata Creds): Managed identities in Azure Active Directory offer a solution for automatically managing the identity of applications. These identities are used by applications for the purpose of connecting to resources compatible with Azure Active Directory (Azure AD) authentication. By utilizing managed identities, applications can secure Azure AD tokens while eliminating the need to handle credentials directly. 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, an identity is created in Azure AD. The identity is tied to the lifecycle of that service instance. When the resource is deleted, Azure automatically deletes the identity for you. By design, only that Azure resource can use this identity to request tokens from Azure AD.
User-assigned. You may also create a managed identity as a standalone Azure resource. You can create a user-assigned managed identity and assign it 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.
Roles & Permissions
Roles are assigned to principals on a scope: principal -[HAS ROLE]->(scope)
Roles assigned to groups are inherited by all the members of the group.
Depending on the scope the role was assigned to, the role cold be inherited to other resources inside the scope container. For example, if a user A has a role on the subscription, he will have that role on all the resource groups inside the subscription and on all the resources inside the resource group.
Classic Roles
Owner |
| All resource types |
Contributor |
| All resource types |
Reader | • View all resources | All resource types |
User Access Administrator |
| All resource types |
Built-In roles
From the docs: Azure role-based access control (Azure RBAC) has several Azure built-in roles that you can assign to users, groups, service principals, and managed identities. Role assignments are the way you control access to Azure resources. If the built-in roles don't meet the specific needs of your organization, you can create your own Azure custom roles.
Built-In roles apply only to the resources they are meant to, for example check this 2 examples of Built-In roles over Compute resources:
Provides permission to backup vault to perform disk backup. | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 | |
View Virtual Machines in the portal and login as a regular user. | fb879df8-f326-4884-b1cf-06f3ad86be52 |
This roles can also be assigned over logic containers (such as management groups, subscriptions and resource groups) and the principals affected will have them over the resources inside those containers.
Find here a list with all the Azure built-in roles.
Find here a list with all the Azure AD built-in roles.
Custom Roles
Azure also allow to create custom roles with the permissions the user needs.
Permission Denied
In order for a principal to have some access over a resource he needs an explicit role being granted to him (anyhow) granting him that permission.
An explicit deny role assignment takes precedence over the role granting the permission.
Global Administrator
Users with the Global Administrator role has the ability to 'elevate' to User Access Administrator Azure role to the root management group. This means that a Global Administrator will be able to manage access all Azure subscriptions and management groups. This elevation can be done at the end of the page: https://portal.azure.com/#view/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/~/Properties
Azure Policies
Azure policies are a set of rules and regulations in Microsoft Azure, a cloud computing service, that help manage and enforce organizational standards and to assess compliance at-scale. These policies enforce different rules over your Azure resources, ensuring that those resources stay compliant with corporate standards and service level agreements.
Azure policies are crucial for cloud governance and security, helping to ensure that resources are used properly and efficiently, and that they comply with external regulations and internal policies. Som examples:
Ensuring Compliance with Specific Azure Regions: This policy ensures that all resources are deployed in specific Azure regions. For example, a company might want to ensure all its data is stored in Europe for GDPR compliance.
Enforcing Naming Standards: Policies can enforce naming conventions for Azure resources. This helps in organizing and easily identifying resources based on their names, which is helpful in large environments.
Restricting Certain Resource Types: This policy can restrict the creation of certain types of resources. For example, a policy could be set to prevent the creation of expensive resource types, like certain VM sizes, to control costs.
Enforcing Tagging Policies: Tags are key-value pairs associated with Azure resources used for resource management. Policies can enforce that certain tags must be present, or have specific values, for all resources. This is useful for cost tracking, ownership, or categorization of resources.
Limiting Public Access to Resources: Policies can enforce that certain resources, like storage accounts or databases, do not have public endpoints, ensuring that they are only accessible within the organization's network.
Automatically Applying Security Settings: Policies can be used to automatically apply security settings to resources, such as applying a specific network security group to all VMs or ensuring that all storage accounts use encryption.
Note that Azure Policies can be attached to any level of the Azure hierarchy, but they are commonly used in the root management group or in other management groups.
Permissions Scope
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 deny access to specific resources using conditions.
Default User Permissions
A basic user will have some default permissions to enumerate some parts of AzureAD:
Read all users, Groups, Applications, Devices, Roles, Subscriptions, and their public properties
Invite Guests (can be turned off)
Create Security groups
Read non-hidden Group memberships
Add guests to Owned groups
Create new application (can be turned off)
Add up to 50 devices to Azure (can be turned off)
You can see the full list of default permissions of users in the docs. Moreover, note that in that list you can also see the guests default permissions list.
Remember that to enumerate Azure resources the user needs an explicit grant of the permission.
Privileged Identity Management (PIM)
Privileged Identity Management (PIM) in Azure is a tool that manages, controls, and monitors privileged access in Azure Active Directory and Azure. It enhances security by providing just-in-time and time-limited privileged access, enforcing approval workflows, and requiring additional authentication. This approach minimizes the risk of unauthorized access by ensuring that elevated permissions are granted only when necessary and for a specific duration.
Authentication Tokens
There are three types of tokens used in OIDC:
Access Tokens: The client presents this token to the resource server to access resources. It can be used only for a specific combination of user, client, and resource and cannot be revoked until expiry - that is 1 hour by default. Detection is low using this.
ID Tokens: The client receives this token from the authorization server. It contains basic information about the user. It is bound to a specific combination of user and client.
Refresh Tokens: Provided to the client with access token. Used to get new access and ID tokens. It is bound to a specific combination of user and client and can be revoked. Default expiry is 90 days for inactive refresh tokens and no expiry for active tokens.
Information for conditional access is stored inside the JWT. So, if you request the token from an allowed IP address, that IP will be stored in the token and then you can use that token from a non-allowed IP to access the resources.
Check the following page to learn different ways to request access tokens and login with them:
pageAz - AzureAD (AAD)The most common API endpoints are:
Azure Resource Manager (ARM): management.azure.com
Microsoft Graph: graph.microsoft.com (Azure AD Graph which is deprecated is graph.windows.net)
References
Last updated
