This post is on request. After having drawn this on a whiteboard for the n-th time, I was asked if I couln’t write a blog post about it so it can be shared more broadly. There is nothing you can’t read elsewhere, but I think the reason I was asked to write this is that it serves as a intro to what I call the Holy Trinity of Azure.

The Hole Trinity of Azure?

Dispite sounding like a Monty Python movie, it is actually not something silly but rather important to understand to get the overall picture of how Azure hangs together. While the Christian religion has the The Father, Son and the Holy Spirit, Azure has the EA Enrollment, Azure Subscriptions and Azure AD.

The EA Enrollment is where you create Azure subscription and organize that into a structure that meets your enterprise’s need. To your help you have entities called Accounts, Departments and Cost Centers. The EA enrollment is also about billing, cost tracking and financial reporting. It has nothing to do with managing resources, like a Virtual Machine, etc. The EA Enrollment has its own management portal https://ea.azure.com

An Azure Subscription is where Azure resources are created and managed. It is not created to a specific location and is as naked as a child is when its born into this world, ie it has zero existing resources once it is created. At birth, the subscription is just a security and economical boundry – only authorized user can start working with it and costs incured will roll up into the Account in the the EA it belongs to. The Azure subscription has two portals where the old one is https://manage.windowsazure.com and the new one is https://portal.azure.com. The old portal do not understand RBAC/ARM as explained below.

The Azure AD plays a vital part, since although Azure has a legacy for using LiveIDs or Hotmail accounts (nowadays called Microsoft Accounts which is a name I really, really dislike and will therefor not use), is has now for 4-5 years had the ability to use Azure AD as it source of authorization. Using AAD makes so much more sense in the enterprise and when doing so it means that the identities you grant access to in the EA and in subscriptions will come from AAD which in 99% of the cases is sync’d with your corporate Active Directory. So if a person leaves the company, access to the EA portal and Azure subscriptions will also be revoked.

Roles of the Holy Trinity

Each of the three componants in the Holy Trinity has its own set of roles. Some are unique and exclusive and some live in two worlds so to speak. Knowing them will make your life so much easier, so let’s take a quick tour.

EA Enrollment Roles

Just like you have an Administrator in Windows and a root user in Unix/Linux, there has to be an initial user in the EA Enrollment. This user is named when Azure is added the EA (Enterprise Agreement) contract and history have tought us to pay attention to who it is, since that person needs to monitor its e-mail inbox to actually get initial access to ea.azure.com

• Enterprise Admin – the root user of the EA. The first task of the initial EA admin is to share the power and add other users as EA Admins so that you don’t have a singel point of failure. The EA Admin can also create Departments and assign users as Department Admins. The EA Admin can view consumption usage and billing charges across all Departments, Accounts and Subscriptions since it is the root user.
• Department Admin – The Department Admin is a recent invention to remedy that the EA structure previously was too shallow. It can edit details on the department, like CostCenter, and create EA Accounts under the department. The Department Admin can be granted the right by the EA Admin to view billing charges.
• Account Owner – (also called Account Admin) is the role that create subscriptions and assignes who is the Service Admin for the subscription (aka, root user). The Account Admin can be granted the right by the EA Admin (not Department Admin) to view billing charges on the account level. Without it, the Account Admin can see exact details of how much Azure resources are consumed, but not how much money it costs. This is a common source of irritation.
• Service Admin – root user of an Azure subscription assigned by the Account Admin. Can not to anything in the EA portal, really

Azure Subscription Roles

At the creation of an Azure subscription, there are only two roles, which are Account Owner and Service Admin. These two roles can easily be explained when you think of the fact that you can create a stand-alone, pay-as-you-go subscription with out an EA and just using your credit card.

• Account Owner – is the sponsor who puts in his/hers credit card info and can change that when the current credit card expires, etc. The Account Owner do not have any root-level access to resources and can not delete or modify anything provisioned. However, the Account Owner can replace the Service Admin and put in himself/herself and that way get access to the resources if needed.
• Service Admin – is the root user of the subscription and have full power of everything in the subscription EXCEPT the billing information. The Service Admin cannot edit or change the credit card information but can replace himself/herself as the Service Admin. The Service Admin can add Co-Admins to a subscription where the co-admins have the same powers as the original Service Admin, except that a co-admin can’t replace the original Service Admin. The co-admins have to come from the directory the subscription belongs to or be a LiveID (since all AAD tenants trusts LiveID)

In an EA enrollment environment, it is the EA Account Owner that creates a subscription that will be the Account Owner of the Subscription. Ie, this is a role that lives in two worlds, since it has both EA duties and also have access to the subscription. The Service Admin also live in two worlds, since the role is created in the EA portal when the subscription is created, but spends 99.99% of its time in the Azure subscription.

RBAC and ARM

Customer feedback was strong that the full powers of a Service Admin or co-admin inside a subscription was not a good thing. A co-admin could wreck havoc and delete stuff by accident. Microsoft listened to the feedback and the response was RBAC and ARM (Role Based Access Control and Azure Resource Manager).

With ARM, every resource in Azure belongs to a Resource Group and just like we are used to on Operating Systems like Windows and Linux, we can add users to a group with certain rights. This is the same with Azure Resource Groups.

/subscriptions/{guid}/resourceGroups/<resource-group>/providers/Microsoft.Web/sites/<resource-name>

The Service Admin and the co-admins still have full powers at the {guid} level and below, meaning that they are above the resource group stuff. But with Resource Groups you can add users and give them roles that meets their access level. For instance, you might add developers with Role as Readers to key infrastructure resources, like Virtual Network and Gateway componants. They are allowed to view them but cannot wreck havoc on them. This means that you only give users access to the resources they need instead of the entire subscription.

RBAC and Resource Groups can also be the answer for multi-tenancy within a subscription. You can host multiple applications in a singel subscription and guard them with Resource Groups, which is probably what you want to do if you are hosting a SaaS-solution. Combined with the Audit Log capability of Azure, the RBAC/ARM story is pretty strong.

Azure AD Roles

The third part in the Holy Trinity is Azure AD. It is probably the part that you pay the least attention to, but that’s expected since few people deal hands-on with Active Directory in the on-premises world. Roles to know about for AAD are:

• Billing Admin – Manages billing and support tickets for Office 365. Has nothing to do with the Azure EA Enrollment or Azure Subscriptions in general
• Global Admin – Has access to all AAD administrative features. This is the root user of AAD and is important for Azure applications since the Global Admin is the person that can create a Service Principal account for instance. Service Principals are service accounts that are used in batch or automation situations. It is also the way some Azure features authenticate themselves when interacting with each other, like Azure Data Lake. If you are using Azure Automation, you will probably need a Service Principal, so know who your Global Admins are and be nice to them!!If you create a Directory in one of the Azure portals, you will be the Global Admin of this AAD-tenant. For Dev/Test scenarios, this might not matter so much, but pay attention what account you are using if the AAD tenant is intended for more than just playing around since that guy will be the Global Admin of the AAD tenant and might have more powers than you care to like when you are in production.
• Password Admin – Pretty obvious by its name. Not important for Azure
• Service Admin – Should not be confused with the Service Admin role of an Azure subscription. This is a name reuse but in the space of AAD. An AAD Service Admin has nothing to do with the Azure EA or a subscription
• User Admin –  Manages users in the AAD. Not important for Azure.

Some common Scenarios

To help you navigate in this Holy Trinity, let’s run a fictional scenario in a fictional company.

A new proof-of-concept project is started in a new business unit and they have decided to use Azure and therefor need a subscription.

1. Find the EA Admin and discuss if you should create a new Department/Account or if you just should create a new subscription in an existing Account. If this was a 2nd POC, perhaps you would have the discussion with the Account Owner to just create another subscription.
2. The hint here is “new business unit”, so you need to find an owner for the Department and Account, create them in the EA portal and set the CostCenter. The Account Owner is probably connected to the POC and will be the person with a budget. Since the billing of consumed Azure resources is at the EA enrollment level, the Account Owner needs to do a handshake with the EA Admin that all costs incured from all subscriptions created under the Account will be covered by the budget and that all excess consumtion will also be the responsibility of the Account Owner.
3. The Account Owner creates a new subscription and assignes the Service Admin to the lead developer/architect. In many cases I’ve seen, the Account Owner invites the Services Admin into the EA portal granting this person the rights to view consumption and cost. This makes sense since the lead developer probably is going to help tracking the spendings of the POC.
4. The Service Admin adds co-admin(s) and then creates the resource groups that should make up the RBAC structure. The Service Admin may need to talk to the AAD Global Admin to set up Service Principal(s) for automation.
5. The Account Owner uses the EA portals reporting capabilities to track Azure consumption and costs incured. PowerBI has a great connector to Azure Consumption but to integrate billing data into PowerBI you need involvement of the EA Admin, since that role sits on the keys required to integrate with that data.

Addendum on Azure subscriptions

Addendum 1 – Most customers I’ve explained Azure to have a little bit of trouble understanding what an Azure subscription is. Most think that its a preset environment with networking, firewalls and load balancers that you get. Understanding that the subscription is empty and has nothing to begin with takes some time to understand, but it is true. An Azure subscription only gives you the right to provision stuff in all Azure datacenters around the world, but nothing is provisioned until you start doing so. Sure, Azure has some serious amount of infrastrucure world wide in its datacenters, like networking and firewalls, etc, but in your subscription there is nothing until you start provisioning your Virtual Machines, Load Balancers, etc. You don’t buy a dedicated rack in the corner with Azure – you buy the right to use any resource in any of the world wide datacenters Azure has.

Addendum 2 – An Azure subscription trusts one and only one Azure AD directory. This AAD trusts hotmail by default and this is why you can only grant access to users in this AAD tenant or hotmail accounts. If the Azure subscription was created with a hotmail account to begin with, which can be done even from the EA portal by assigning the Service Admin to a hotmail account, you will get an new stand-alone AAD tenant with the hotmail account created in it. Since AAD trusts and federates with hotmail, you can login using your hotmail account and hotmail as the IDP. Changing the directory that the subscription trusts is a manouver that requires changing who is the Account Owner and Service Admin. Changing that to a corporate AAD tenant will make the Azure subscription “move in” to control of the corporate AAD tenant and leave the hotmail stuff.

If you don’t want hotmail users, just talk to the EA Admin to disallow this in the EA portal, but before doing this, make sure you have “converted” all subscriptions as explained above. Otherwise you will shoot yourself in the foot and lock yourself out.

Addendum 3 – Every now and then the discussion comes up who can logon to a VM in an Azure subscription and the answer that it can be none of the users from The Holy Trinity is a bit suprising. But, if you have a local user on a VM that is publically accessable via RDP or SSH, you can login to that VM regardless of all the RBAC and EA portal in the world. This is nothing different from the on-premises world. It is configuration that the Service Admin and his friends do that determind this. It is not Microsoft or Azure.

References

Role of the (EA) Account Owner – Channel9 video
https://channel9.msdn.com/blogs/EA.Azure.com/EA-Portal-Role-of-the-Account-Owner

Azure AD roles
https://azure.microsoft.com/en-us/documentation/articles/active-directory-assign-admin-roles/

 

Continue reading “The Holy Trinity of Azure”