Congratulations!, you got your Enterprise Agreement enhanced with Azure!, now what’s next, you got activation emails and you want subscriptions, but who manages subscriptions? what if the company is rather complex and you don’t want the IT admin in charge of all subscriptions let alone view the company global spending on Azure services? In short, what about the Enterprise Governance on Azure in an EA enrollment?
Apart from each service on the cloud to follow a governance and security model, it is vital that the “cloud” entry points also follow a governance model as determined by the company. After all, while cloud can encompass many services, itself is a service too that generates invoices which need to be controlled to avoid abuse and to ensure oversight is added. In this chapter, we describe the Azure model with regards to governance..
The main model for our topic on this post is based on the following picture
When enrolling for Azure through an EA (enterprise agreement), the (Microsoft) contract owner will be given an activation code by email to activate the Enterprise Enrollment. The activation email will provide access to the Enterprise Portal, from this enterprise portal customers can self-manage their Accounts and Subscriptions. The actual contract and the terms will also be available through the Enterprise Portal. The account initiating the Enterprise Enrollment is referred to as the Enterprise Administrator.
After activating the enterprise enrollment, multiple Enterprise Administrator accounts can be added to the enrollment to provide others with the same privileges.
From the Enterprise Portal, optionally departments can be created. Departments can be business units, geographical locations of the company or any other reason the company seems fit. Departments do offer the option of adding quotas to the underlying subscriptions for indication only. A department can view usage from all the assigned accounts under it. While the department is optional, it might be beneficial for very large companies to ensure a separation between entities is established, or if governance requires a separate (financial) view on multiple accounts within the company. It is not advised to use the departments to separate projects and teams, for this, accounts can be used. When a department is created it can have a Department Admin, and/or existing Account Admins can be assigned to a Department.
The Enterprise Admin (or department admins) can create Accounts. Accounts are user accounts that are granted the ability to create subscriptions. Usually they are the budget holders, responsible for allocating budget to different projects or services. While in the actual implementation Accounts are actual user accounts based on logins, in some cases you will find references that Accounts can be a representation of company departments or project teams or service administrators. In the end, Account (admins) are the ones that can create subscriptions and can view the cost of each of them[1]. Department Admins can view the costs of all subscriptions under the department made Accounts[1] and Enterprise Administrators can see all cost of all subscriptions.
[1] if allowed by the Enterprise Admin
An example: A very large company has multiple regions. In each region they have separate operational divisions that work individually from each other. In this case, the corporate HQ will own the EA subscription and is the Enterprise Admin. They create Departments for the country headquarters, which in turn create accounts for the divisions in their country (for example manufacturing, distribution and maintenance). From within the divisions, they can create multiple subscriptions to support their workloads and projects.
In this scenario, HQ can view all billing globally, the CountryHQ’s can view their national spending on cloud consumption and the divisions can maintain the cost of the individual subscriptions.
Accounts
As indicated, the Enterprise Admin can create Accounts or departments. Now the thing to remember here is that there are different Accounts in the portal. There is the Account Login, which is the actual login account of an administrator or user, and there is the Account which represents the logical container for the various subscriptions. The first (Login Account) is called Account Owner and the Login Account is based on either a School or Work Account or a Microsoft Login.
The Departments or Accounts created by the Enterprise Administrator are linked to an owner, who uses their School or Work Account or a Microsoft Login to gain access to the portals.
Once an account has been created and assigned to an owner (other than the Enterprise Administrator account), the Enterprise Administrator looses (or delegated is a nicer word) part of the visibility to the created subscriptions and the resources in that subscription. In other words, subscriptions are managed in the Account portal, and the Enterprise Administrator ONLY sees the subscriptions directly assigned to himself. NOT the subscriptions created by other Account managers. Through the EA portal, the Enterprise Admin can still see all the subscriptions created, and can view the invoice for all of them, but he does not have any control over the subscription owner, nor the security within the subscription. As a result, the Enterprise Admin cannot delegate control to a subscription if that subscription is not linked/assigned to his/her account. ONLY the account owner can set subscription owners (and thus access to).
In short, if the login credentials used for the Enterprise Portal are not assigned to an account, the Enterprise Admin will not see any subscriptions when logging into Account portal.
The above is the obvious example of the segregation of duties. The Enterprise Admin is not the equivalent of the Enterprise/Domain Admin in Active Directory. He does not have full control over everything but only has rights to delegate, and can create subscriptions himself (over which he has control in that case). But as soon as Accounts are created, part of the ownership and control is handed over to the account holder. It is therefore the Account owner that should be fully accountable for his subscriptions!
Through the EA portal, the Enterprise Admin (or Department Admin) is able to change the Account Owner for a particular account. Therefore revoking the previous account holder of his rights and providing a new account holder. Changing the Account Owner however, ALSO resets the subscription administrators and co-administrators in some cases. The new Account Holder will be the new subscription owner and therefore is granted the rights to restate the previous subscription owner or keep the defaults and himself be the subscription owner.
Subscriptions
The actual resources are deployed in subscriptions, a subscription is the container for the resources themselves and therefore also acts as the administration and billing containers. As the capacity for a subscription is not unlimited, it is primarily a capacity container. There can be multiple subscriptions on the same billing account and under the same administrative container.
While the subscriptions are on the lowest level in the above diagram, the architecture guidance is to keep the number of subscriptions as low as possible. Even within a subscription it is possible to further delegate administrative control and “tag” individual resources for billing, which keeps the upper delegation management and billing overview as simple as possible. As such, a subscription is not just for a single team or entity, but must be seen as a capacity container for multiple teams if so desired.
In short, it is possible to create departments under the main Enterprise enrollment and delegate departments the rights to create multiple accounts. But the Enterprise admin can also create Accounts directly. Per account it is also possible to create multiple subscriptions. A department can be a 1:1 representation of the company, and account could (or usually are) billing holders that are responsible for one or multiple subscriptions. Within each subscription it is possible to create multiple IT services and further delegate control over those resources.
As we can see from the image above, is that account holders can create subscriptions, but this not imply that they need access to the complete enterprise portal. For account holders there is the Account Portal. Within the account portal account holders can view/manage their subscriptions and their account themselves.
Note that it is all about governance and who is able to create new subscriptions and view usage, not the actual delegation or access to the resources themselves!
Creating subscriptions
The account owner is the only one that is capable of creating new subscriptions. Obviously, the same username can be used as Enterprise Admin and account owner, but most of the times these roles will be separated. The account owner can login to the same portal as the Enterprise Admin but will only see the details of his account and all the subscriptions that are managed.
When a new subscription is added, the account portal is opened, note that the initiation of creating a subscription is performed through the Enterprise Portal, the actual subscription is created in the account portal. The account portal by default will list the Enterprise Enrollment (linking the billing to the EA contract), but other offers may be visible too.
In the account portal, additional information on the owned subscriptions by the Account owner are displayed. This includes actual spending per resource type but also the initial service administrator. By default, this Service Administrator is equal to the account owner (who created the subscription), but may be altered to delegate someone else full permissions on the subscription.
Role matrix
The following table describes the (default) roles and their function:
| Role | Description | Corporate roles |
| Enterprise Administrator | The Enterprise Administrator has the ability add or disassociate Accounts and Departments to the enrollment, can view usage data across all Accounts and Departments, can view the monetary commitment balance associated to the enrollment. There is no limit to the number of Enterprise Administrators on an Enrolment. | – Finance department
– Licensing specialists – Procurement department – Global IT budget holders |
| Departments | Departments can be leveraged if an additional level to structure the Accounts and Subscriptions is needed. Cost center and Start/End date can be added as an attribute to the Department. | |
| Department Administrators | Department Administrators can manage Department properties, manage Accounts under the department they administer, download usage details and view monthly Usage and Charges associated to their Department IF the enterprise administrator has granted permission to do so. | – Project Portfolio Managers
– Budget holders
|
| Account Owner | The Account Owner can add Subscriptions to their Account, update the Service Administrator and Co-Administrator for an individual subscription, view usage data for their Account and view Account charges IF the Enterprise Administrator (or Department Administrator) has granted permission to do so. | – Project Managers
– IT staff (managers) |
| Service Administrator & co-administrators | The Service Administrator and up to 200 Co-Administrators per subscription have the ability to access and manage Subscriptions and development projects within the Azure Management Portal. The Service Administrator does not have to have access to the Enterprise Portal, unless they own one of the other roles. |
Further delegation of rights within a subscription can be granted by the Service Administrator or co-administrators. More information on delegating rights within a subscription can be found on: https://azure.microsoft.com/en-gb/documentation/articles/role-based-access-control-configure/
Billing
As indicated the Enterprise Admin can view all billing statements from all the subscriptions. Only deployed resources in a subscription incurs charges, hence the number of Departments or Accounts does not incur any. The Enterprise Administrators can set Spending Quota numbers on the created Departments. These spending quotas are however not enforced in the subscriptions. They do trigger alerts and show up in the reports of the Enterprise administrator, but the quotas are also shown on department and within the subscription.
If so desired, it is possible to disable the billing features for Departments or Account owners. In that case, only the Enterprise Admin is able to view the charges incurred.
MSDN
MSDN is another offer from Microsoft with regards to Azure (and other offers), that may be incorporated into the enterprise / account portal. If so configured on the contract, the Enterprise Admin can also delegate or assign Account owners are MSDN account owners. They can use extended benefits within their Azure subscriptions with regards to development and test environments.
If new Account owners are added based on their Microsoft Account (see below), and they have an MSDN activated Azure, their MSDN based Azure subscription will be absorbed in the enterprise agreement, which may cause loss of certain benefits depending on the contract.
In many cases, it is best to add Account holders based on their (Work/School account) corporate credentials if separate MSDN subscriptions are in use.
Identity based on AAD
Accounts being used within the Portals, Accounts or Subscriptions, are based on Azure Active Directory as a generic source of identities or LiveID (Microsoft) accounts. There is a difference between the two account types and it is possible for the Enterprise Portal, as well as all the other portals and subscriptions to use either one or both.
The two different type of accounts are:
- Microsoft Account – also known as a LiveID account. A regular e-mail address is enrolled in a Microsoft account. The username (email address) and password are stored on the Microsoft servers. This account can provide access to cloud services, like Skype, Office, Outlook.com and many others. While the email address may be equal to the corporate email address, there is no 1:1 relation with the on-premises account nor its password.
- Work or School Account – this is an account that is held in the Azure Active Directory (AAD) of a tenant. It is possible to “extend” the corporate credentials into the AAD, but in any case, the username and password are managed by the company or school. Contrary to the Microsoft account, they cannot be provisioned by end-users themselves.
When setting up Azure, it is important to know which accounts will be delegated access. While Microsoft accounts may seem easy to deploy, they are harder to manage and to revoke access during an automated process. Corporate credentials can be used as Work or School Account but it will require a deeper integration of the on-premises identity systems with the Azure Active Directory.
From the enterprise portal it is possible to determine the authentication levels, which types of accounts are allowed within the subscriptions and enterprise portals? For many corporate enterprises, the use of solely Work or School accounts will be their preferred setting.
Using Work or School accounts, means that the accounts used to give access are stored in an Azure Active Directory belonging to the company. This Azure Active Directory can be manually managed by the administrators, or it can be a representation of the on-premises Active Directory users and groups. In this scenario, all users and their passwords[2] are replicated to the Azure AD. However, when the passwords (hashes of) are not to be stored on the cloud in Azure AD, it is also possible to use a federated architecture. In this architecture the actual passwords of the users stay within the enterprise in the Active Directory (or equivalent system) and the actual authentication is performed against this system. In the figure below, these options are visualized:
When provisioning a new Azure subscription, a Microsoft account will be required to initially setup the portal and the subscription that will hold the corporate (work/school) accounts. After the Azure Active Directory has been setup in the desired way, the Microsoft accounts can be replaced by the corporate accounts and this option can be disabled.
[2] not the password itself is replicated, its actually the hash of the password hash, see https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-implement-password-synchronization/ (how password synchronization works)
Conclusion
Security, Transparency, Privacy and Compliancy are at the heart of every cloud provider, certainly Microsoft Azure. This document described the way Azure is controlled, how subscriptions can be activated and showed some options on how to map the existing governance structure in an organization into an Azure governance structure.
With regards to the Security, Transparency, Privacy and Compliancy of individual resources, it comes down to the architecture chosen for the implementation, based on the specific components. It is not so easy to just define a “standard” governance model for so many services that serve many different roles within an architecture. For every deployment it is best to review the requirements and ensure they are applied in the cloud solution, there are certainly multiple ways of implementing them, ensuring that compliancy is not affected.