Whether you are dipping your toe or diving headfirst into Azure, one of the points of confusion is the relationship between Azure Active Directory and Azure subscriptions. Azure subscriptions may be referred to as subscriptions, or sometimes even just Azure. An Azure Active Directory tenant, which is the cloud identity provider, is usually referred to as Azure AD or AAD, or sometimes just tenant.
While Microsoft has decent documentation on the relationship, I tend to find that drawing analogies along with additional visuals can help really drive the relationship home for folks. For the MS Docs article, see Add an existing Azure subscription to your tenant – Azure AD – Microsoft Entra | Microsoft Learn.
A Look at Pre-cloud Infrastructures
When we take a look at very classic on-premises infrastructure, if it’s a Microsoft shop we’ll almost always have Active Directory, an identity provider, usually running on physical or virtualized servers in a high availability architecture. For purposes here, we’ll abstract it from the underlying server infrastructure:
Likewise, we have all sorts of servers running, again possibly a mix of physical servers, as well as virtualized servers (even though the hypervisor itself is running on some form of physical server). Below we have a simple example of a Windows Server that is running Hyper-V, andhas four virtual machines running:
When we connect these two systems, Active Directory and the Windows Server, we form a trust relationship between the two. The trust relationship is represented in Active Directory by the computer object that represents that Hyper-V server.
To expand this out a bit further, we likely have several different servers running several different types of workloads in our environment:
The one commonality is that regardless of the type of workload running on the server, we have that trust relationship between Active Directory and each server.
Translating to the cloud trust model
With our understanding of having that trust relationship between Active Directory and each Windows Server, we can translate this to a similar trust relationship between our Azure Active Directory tenant and Azure Subscriptions.
In our example below, we see that a subscription can be mostly analogous to a Windows Server. They both contain virtual machines, and both the subscription and the server have their own type of trust relationship to their relative identity provider:
Similar to how we may run several different workloads on several different servers, we can have several different subscriptions that are managing several different workloads:
Similar to Active Directory, where you can only domain join a Windows server to one domain, an Azure subscription can only have one trust relationship to an Azure AD tenant.
Unlike Active Directory, where the trust relationship is observable as a computer object, the subscription won’t be something that you’ll see represented in Azure AD itself, but with the right permissions you’ll be able to observe all subscriptions associated with that tenant when you sign into the Azure portal.
With Windows servers, we occasionally may run into instances where we wanted to migrate a Windows server from one Active Directory Forest to another. Similarly, we can migrate an Azure subscription relationship from one Azure AD tenant to another:
In both models, the trust relationship is changed, because we can still only have one trust relationship between a subscription and a tenant.
Similar to Active Directory and changing the associated forest, depending on the types of workloads in the subscription, there may be post migration work that needs to happen. At the very least, we will need to re-assign the appropriate permissions to the subscription.
The Permission Confusion
Not only is the relationship between a tenant and subscription confusing, but so is the permission model, and where things should, or should not, crossover.
With Active Directory, in a properly tiered permission model, Domain Administrator should primarily be used for management of Active Directory, and nothing more. All of those servers joined to Active Directory should use a separate set of permissions, many times referred to as a Server Administrator. Domain Administrators have no business logging onto the member servers, and Server Administrators have no business managing Active Directory. This all becomes really important when you start talking about least privilege and privilege separation.
You can think of the fact that each Windows server has it’s own set of local permissions you can delegate and control on the server. And those permissions are managed local to that server. While you may create groups of objects in Active Directory, say, Hyper-V Server Administrators, you then assign that group local on each Hyper-V server to have the necessary rights.
The same goes in Azure subscriptions. Subscription Owners are effectively the Local Administrators, and the permissions themselves are assigned on the subscription. While the permissions may be abstracted in the sense that you use a single portal or command across multiple subscriptions, the permissions are still encompassed around that subscription.
And just like Active Directory, you generally do not need to assign a Global Administrator any permissions into or over a subscription. While some organizations may accept the risk with a limited number of Global Administrators, the problem becomes pervasive in organizations that believe they need to continue to hand out Global Administrator roles just so that subscription ownership can happen.
While it is a shift in how organizations work and operate, overly permissive models with a lack of privilege separation are a great way to help threat actors into your environment.
Digging Deeper
Our examples are simple, to help build an understanding of the relationship model. And just like we may divide server workloads up by application groups or regions, and how we likely architect web farms and Hyper-V clusters, elaborate subscription models require thoughtful architecture behind them. This is where the Microsoft Cloud Adoption Framework and Azure Landing Zones come into play.
You can find more information on these here, Microsoft Cloud Adoption Framework for Azure – Cloud Adoption Framework | Microsoft Learn, and here, What is an Azure landing zone? – Cloud Adoption Framework | Microsoft Learn.
It’s especially important from an identity and security perspective to architect the security properly of your subscriptions – many organizations have overly permissive architectural designs around their subscription permissions, including on items of critical infrastructure, such as Active Directory Domain Controllers running as virtual machines in Azure.
For further information on securing privileges access, take a look at Securing privileged access overview | Microsoft Learn.
One Last Point – Language Matters
This is one of those areas where language matters, especially if you are an identity practitioner or working in a role where you help manage and service your customers Azure subscriptions and Azure AD tenant(s).
It is not:
- Azure tenant
- Azure AD subscription
- AAD subscription
- Azure directory
It is:
- Azure AD tenant
- Azure subscription
While for some organizations you may be able to get away with interchanging terminology, if you were to have a project assigned to you, or scope a project for a customer, and the details were similar to “perform an audit of the AAD subscription and make recommendations on a privilege model“, would you be talking about auditing the permissions in Azure Active Directory? In an Azure subscription? Which Azure subscription if the organization has multiple? You can see where this is going.
About This Posts Featured Image
The chosen photo is the work of Jason Richard, used under the Unsplash license.
