A hitchhiker's guide to the Azure Terminology
A hitchhiker's guide to the Azure Terminology Fundamentals
The adoption rate of Azure has really increased during the last few years and we are constantly in dialogues with customers that are either new to Azure and wants help to get started or already using Azure and wants help to either manage their existing environments, set up additional environments or migrate from an existing offer to the Cloud Solution Provider (CSP) offer. There are often people from all parts of an organization involved in these kinds of discussions and without a substantial amount of Azure experience many find themselves in a sea of new words which can be a barrier and source of both misunderstandings and frustration.
To lessen the amount of misunderstandings and frustration caused, our own Azure expert Simon Wåhlin has taken upon himself to explain some fundamentals of Azure Terminology. Simon is a Chief Technical Architect with Advania and more of his post can be found at his personal blog https://blog.simonw.se.
Major components of the Microsoft Cloud
When using services in the Microsoft Cloud, a few core-components are often discussed, and it is not unusual to get these parts mixed up. I usually try to describe the Microsoft Cloud offering consisting of three major components, a tenant, the Microsoft 365 services and Azure Subscriptions. I choose to split them into these three because you should always have a tenant, which makes this the first major component.
In each tenant, you can attach various services. The services in the Microsoft 365 offering (Office, Intune, Multifactor Authentication and such) are permanently attached to a tenant and all share a common administrative portal and administrative roles, which leads me to group them into the second major component.
Azure Subscriptions are containers for various infrastructural services like for example virtual machines, networks, websites, kubernets clusters, storage and databases. Subscriptions have their own RBAC roles and are more loosely associated with a tenant, so I group these into a third major component.
A tenant is a dedicated instance of an Azure Active Directory that enables users to log in to your services in the Microsoft Cloud. A tenant needs a unique name and id that both can be used to identify the tenant. The tenant name combined with onmicrosoft.com makes up the default domain name for your tenant and will appear visible to users in some places like URLs for example. Choose your tenant name wisely, it cannot be changed and migrating to a new tenant can involve a lot of work. Usually a company has one production-tenant holding user accounts for all employees but there could also be other tenants such as test-environments. When you sign up for Azure, Microsoft (Office) 365, Dynamics CRM Online or Intune, an Azure Active Directory is created for you automatically if you don’t already have one.
As described above, each tenant gets a default domain name that ends with “.onmicrosoft.com”, but you can add any custom domain that you own as long as it is not associated with another tenant. To add a custom domain, you need to prove ownership by creating a DNS record. Once a domain added to a tenant and verified, it cannot be moved to another tenant without first removing any reference to it and then removing it from the first tenant. It might take a while between a domain name is removed from one tenant until it is considered available for another tenant. Moving a domain from one tenant to another can be a cumbersome procedure.
Once a tenant exists, services can be added to it by buying licenses. Example of such services are Office 365, various security services and services for client management. To buy a license, a payment method needs to be set up. This can for example be Pay-As-You-Go (PAYG), Enterprise Agreement (EA) or Cloud Service Provider (CSP). It is easy to switch licenses from PAYG or EA to CSP. Once a service is set up in a tenant it cannot be moved to another tenant without substantial effort. For example, moving your Office 365 licenses to a new tenant might involve migrating mailboxes, OneDrive-data and SharePoint sites.
An Azure Subscription is a container for Azure resources. Once you have a subscription, resources like virtual machines, storage accounts, virtual networks, databases and a whole lot of other things can be created. I like to think of a subscription as one of my own virtual geo-distributed datacenters. Subscriptions comes in different flavors called offers, common offers are Pay-As-You-Go (PAYG), Enterprise Agreement (EA) and Cloud Solution Provider (CSP). An offer is what determines payment method and price.
Only PAYG subscriptions can be converted to other offers, if you have a subscription in an EA agreement and want to change to for example CSP, a new subscription has to be set up and all your resources has to be moved there. Most resources can be moved from an EA subscription to a CSP subscripting using Azure Resource Move which is only a meta-data operation and should not affect the availability of your resources. There are however a few caveats, for example all dependencies to a resource have to be moved together with the resource, some resources can't be moved with certain custom configurations and some resources cannot be moved but has to be re-created in the new subscription. Depending on how the current subscription is organized, which resource types that are used and how they were created and how they have been managed, moving from an EA subscription to a CSP could involve some work.
A subscription has a trust type relation to a tenant, meaning that each subscription is associated to a tenant that is used to manage authentication for users. Access to a subscription can be granted with RBAC principles on the whole subscription, Resource Groups or individual resources to accounts in the associated tenant. A subscriptions association can easily be changed to another tenant with an action called Change directory. This will remove all current administrators and all RBAC access on the subscription.
To help manage resources within a subscription we group everything into logical containers called Resource Groups. One or more subscriptions can also be grouped into logical containers called Management Groups. Resources groups cannot be nested, but management groups can be nested up to six levels (not counting the "root" management group that is created by default).
Administrative roles and access
Roles in a tenant
There are a few highly privileged roles that are often discussed when planning new tenants and subscriptions or migrations between offers. These roles apply to management and administration of Azure Active Directory and some of them are described below. There are a few dozen other roles that give access to manage parts of Azure Active Directory or any licensed service in your tenant. None of these roles gives by default any access to your Azure Subscriptions (except for Global Administrators who can elevate themselves to gain control of any subscription). Subscriptions have their own set of roles.
- Global Administrator
Global administrator is a role in Azure Active Directory that gives full admin access to your tenant to for example manage users, groups, licenses and billing together with managing all the less privileged roles like administrators for specific Office 365 services (like Exchange Online). Ideally you should have one or very few of these. A Global Administrators does not by default have access to Azure subscriptions but can self-elevate their account to gain the role User Access Administrator in all subscriptions associated with their tenant (see description of User Access Administrator role below).
- User Administrator
This role can manage users and groups and reset passwords for any user that does not have a higher administrative role. This access it typically given to support organizations.
- License Administrator
Can manage license assignments to users and groups.
- Billing Administrator
Manages billing information and can purchase additional licenses.
RBAC roles in Azure Subscriptions
Access to resources managed with the Azure Resource Manager API (ARM) can be granted using RBAC roles. At the time of writing this, there are 93 pre-defined roles that can be used to give granular access at several different scopes and if that isn't enough custom roles can be defined. But don't be alarmed, it is not as hard to grasp as it might seem at first glance.
Before we look at roles, let's talk a bit about scopes. Access to resources in Azure subscriptions can be granted at certain scopes and only applies to resources within that scope. A scope can be a Management Group, Subscription, Resource Group or specific Resource. Access assigned to a scope is inherited to all child scopes within the assigned scope. The default Root Management Group ("/") will have its access assignments inherited to all subscriptions associated with the tenant, be very careful when assigning access at this level.
The four notable roles User Access Administrator, Owner, Contributor and Reader are described below. Most of the remaining 89 built-in roles are a combination of a resource type and one of Owner, Contributor or Reader, for example Virtual Machine Contributor. These roles are fairly self-explanatory. Then there are also quite a few roles that is named with a resource type together with "Operator" which usually gives access to "operate" that resource type by using actions like start, stop and resume. Apart from these there are a few more specific roles like for example Application Insights Snapshot Debugger which gives access to download debug snapshots from Application Insights.
- User Access Administrator
This role gives read access to anything within the assigned scope and access to manage access and support tickets for anything in that scope. Any user with the role Global Administrator in your tenant can take this role at the root management group ("/").
Assigning the role owner at a scope grants full access to anything within that scope including access to manage access to resources.
Gives full access to manage everything within the assigned scope, except for managing access.
Gives access to read everything that is not considered a secret.
Classic access roles in Azure Subscriptions
There are a few highly privileged roles that dates way back to the previous generation of Azure (ASM). These are often still referred to even if they really aren't needed that much now a days and they don't apply to the CSP model at all since CSP only supports the resources managed with Azure Resource Manager (ARM). To bridge the gap between ASM and the newer ARM, all service administrators and co-administrators in ASM are also given the Owner role on the subscription scope to be able to manage ARM resources. These roles are:
- Account Administrator
Owns the billing for a subscription. This user does not have access to the Azure Portal or any resources therein.
- Service Administrator
The user that creates a subscription becomes Service Administrator. This is the owner and highest privileged user of a subscription and there can only be one. This role cannot be assigned, it is only given to the use creating a subscription. A subscription can be transferred to another service administrator at any time.
This role has almost the same access as Service Administrator but cannot transfer the subscription to another service administrator or change the directory associated with the subscription. One subscription can have many co-administrators.
Chief Technical Architect