Explaining the hierarchy of Azure management groups and subscriptions

  1. Home
  2. Explaining the hierarchy of Azure management groups and subscriptions

Go back to AZ-304 Tutorials

AZ-304 exam is retired. AZ-305 replacement is available.

In this article, we will learn about ways to efficiently manage access, policies, and compliance for those subscriptions. Moreover, we will understand the Azure management groups and organizing subscriptions.

Hierarchy of management groups and subscriptions

For organizing resources into a hierarchy for unified policy and access management you can build a flexible structure of management groups and subscriptions. The diagram below shows an example of creating a hierarchy for governance using management groups. However, you can create a hierarchy that applies a policy. And, this policy will inherit onto all the Enterprise Agreement (EA) subscriptions that are descendants of that management group. And, this will also apply to all VMs under those subscriptions. 

Azure management group and subcriptions
Image Source: Microsoft
Facts about management groups
  • Firstly, there can be 10,000 management groups in a single directory.
  • Secondly, a management group tree can support up to six levels of depth.
  • Thirdly, each management group and subscription can only support one parent. And, each management group can have many children.
  • Lastly, All subscriptions and management groups are within a single hierarchy in each directory. 

Root management group for each directory

Every directory has a single top-level management group called the “Root” management group. The root management groups are built into the hierarchy by having all management groups and subscriptions. Moreover, these groups give access to global policies and Azure role assignments to apply at the directory level. However, the Azure AD Global Administrator needs to elevate themselves to the User Access Administrator role of this root group initially. 

Facts about the Root management group
  • Firstly, by default, the root management group’s display name is the Tenant root group. The ID is the Azure Active Directory ID.
  • Secondly, to change the display name, your account should be assigned the Owner or Contributor role on the root management group.
  • Thirdly, the root management group cannot move or delete, unlike other management groups.
  • Fourthly, all subscriptions and management groups are folding up to the one root management group within the directory. And, all resources in the directory fold up to the root management group for global management.
  • Lastly, all Azure customers can see the root management group, but not all customers have access to manage that root management group.
AZ-304 Practice tests

Trouble seeing all subscriptions

You should know that a few directories that started using management groups could see an issue where not all the subscriptions were within the hierarchy. However, the process of having all subscriptions in the hierarchy was in place after a role or policy assignment was on the root management group in the directory.

Resolving the issue

There are two options you can do to resolve this issue.

Removing all Role and Policy assignments from the root management group

Firstly, by removing any policy and role assignments from the root management group, the service will backfill all subscriptions into the hierarchy the next overnight cycle. And, with this process there’s no accidental access given or policy assignment to all of the tenants subscriptions.However, the best way to do this process is without impacting services is to apply the role or policy assignments one level below the Root management group. As this will allow you to eliminate all assignments from the root scope.

Calling the API directly to start the backfill process

Customers in the directory can call the TenantBackfillStatusRequest or StartTenantBackfillRequest APIs. And, when the StartTenantBackfillRequest API is called, it kicks off the initial setup process of moving all the subscriptions into the hierarchy. However, this process also starts the enforcement of all new subscriptions to be a child of the root management group. The process can even work without changing any assignments on the root level. By calling the API, you’re saying it’s okay that any policy or access assignment on the root can be applied to all subscriptions.

Issues with the role definition and assignment hierarchy path

Role definition can be defined on a parent management group while the actual role assignment exists on the child subscription. Since there’s a relationship between the two items, you’ll receive an error when trying to separate the assignment from its definition.

Take a look at a small section of a hierarchy for a visual in the picture below.

Azure management group hierarchy path
Image Source: Microsoft

Let’s assume that there’s a custom role defined in the Marketing management group. And, that custom role is then assigned on the two free trial subscriptions. However, if we try to move one of those subscriptions to be a child of the Production management group. Then, this move would break the path from subscription role assignment to the Marketing management group role definition. In this situation, you’ll receive an error saying the move does not have access as it will break this relationship. There are various options for fixing this scenario that includes:

  • Firstly, removing the role assignment from the subscription before moving the subscription to a new parent MG.
  • Secondly, adding the subscription to the Role Definition’s assignable scope.
  • Thirdly, changing the assignable scope within the role definition. 
  • Lastly, creating an additional Custom Role that will be defined in the other branch. 

Moving management groups and subscriptions

For moving a management group or subscription to be a child of another management group, three rules need to be evaluated as true.

  • Firstly, management group write and Role Assignment write permissions on the child subscription or management group.
  • Secondly, the management group writes access to the target parent management group.
  • Thirdly, mManagement groups write access to the existing parent management group.

However, if there is inheriting of the owner role on the subscription from the current management group, with limited move targets. Then, you can only move the subscription to another management group where you have the Owner role. But, you can’t move it to a management group where you’re a contributor because you would lose ownership of the subscription. If there direct is assigning to the Owner role for the subscription, then you can move it to any management group where you’re a contributor.

Azure Management group in AZ-304 Online Course

Reference: Microsoft Documentation

Go back to AZ-304 Tutorials

Menu