Bookmark this! aka.ms/Azure/Administration

  • Článek

Overview

There are many different links out there that talk about how to administer Azure Resources.  What I have been looking for is putting all of the different Azure related administrative capabilities all together in one place.  Hopefully this post now does that for you too.  I am largely cross referencing all of the bits and pieces that are out there. There are four core Azure administrative categories to know and understand. They can further be subdivided into Subscription versus Azure AD categories.

SUBSCRIPTION ADMINISTRATION

  • Enterprise Agreement (EA) administrators
  • Subscription Administrators

AZURE ACTIVE DIRECTORY (AAD) ADMINISTRATION

  • Azure Active Directory Administration administrators
  • Role Based Access Controls (RBAC) on Azure Resources

EA

When beginning down your journey of building out your Azure Subscriptions, these all should be considered, planned and designed before creating anything.  Without an understanding of who can do what, where, when and how, your subscriptions can quickly get out of hand.  Anyone every had an Active Directory Forest/Domain assessment and discovered too many domain admins? Too many forests?  Too many domains? Say I!  Let us learn from the lessons of history and do it right from the beginning.  Already gone down this path....never too late to get back on track with understanding who does what and when.  Then sprinkle some Governance on top of it all to make sure that this all happens.  Remember ITIL? Learn more about the Enterprise Agreement and governance in this Channel 9 video on Azure enrolment: Management, Governance and Reporting.

Caveat - the very top level of these resource may not apply to your organization if you do not already have an Enterprise Agreement (EA) for Azure.  These resources include that agreement.  So if it doesn't apply to your organization, just kindly ignore that part.

The journey for larger organizations begins with the Enterprise Agreement, which creates 1 or more subscriptions. Each subscription has 1 Azure Active Directory tenant associated with it. And then either it leverages users that are synchronized from the on-premises Active Directory environment, or users created in Azure Active Directory, whic can then be assigned Role Based Access Control (RBAC) on any Azure resource.  The RBAC assignment can control who can do what at three different scopes:

  1. The Subscription
  2. Any Azure Resource Group
  3. Any Azure Resource

And like all good permissions, they are inherited from top down in the order above.

Let's break the responsibilities down

So what is the point of this discussion? If it didn't already hit you like a breath of foul air, let me share. Just one word; SECURITY. Who is going to control the whole enchilada? In our on premises worlds, we've had such emperors of our Directory kingdoms with titles such as The Might Enterprise Admin, The Magnificent SUDO,  and the Royal ROOT. With such powers, they can do almost anything in their associated environments. To quote a famous movie "with great power comes great responsibility" i.e. in our computer worlds, we have to know and understand who can do what, and limit the powers of certain accounts by Separation of Duties. Let's break these down for the four types of administration defined at the start of this thread.

Enterprise Agreement Roles

Enterprise Administrator

Has the rights to add additional Enterprise Administrators, Department Administrators, Departments and even associate accounts to the enrollment. An Enterprise Administrator can view usage and charges across all accounts and subscriptions.

Department Administrator

Can edit their assigned department details such as name and cost center, manage the department administrators and create accounts under the department within the enrollment and view department charges (if allowed by the Enterprise Administrator).

Account Owner*

Can create subscriptions under the account and manage the subscriptions Service Administrator and Co-Administrators. Usage data for the account can be viewed and charges (if enabled by the Enterprise Administrator).

Service Administrator**

Access and manage subscriptions they are assigned to.

As you can see in the first row above, that "Enterprise Administrator" doesn't have quite the same royal power as an administrator with the same name as in Active Directory.  In this case, it is more about seeing and viewing the billing details and managing costs within the Enterprise Agreement, and not owning Azure Resources within a subscription.  So it is an important role, but that likely belongs to a business or finance person that own$ the actual agreement.

NOTE: An Account Owner will become the Account Administrator of each subscription they create and be the initial Service Administrator AND Account Administrator for that subscription (See Below). It is good practice to make the Enterprise, Account and Service Administrators by creating ‘Service Accounts’ versus using individual accounts.

Subscription Administrators

Account *Administrator (AA)

1 per Azure account

This is the person who signed up for or bought Azure subscriptions, and is authorized to access the Account Center and perform various management tasks. These include being able to create subscriptions, cancel subscriptions, change the billing for a subscription, and change the Service Administrator.

Note: The difference is that if your organization does not have an EA agreement, and hence no EA Portal, then this is the account admin for managing costs and subscription details in https://account.windowsazure.com.

Service Administrator (SA)**

1 per Azure subscription

This role is authorized to manage services in the Azure portal. By default, for a new subscription, the Account Administrator is also the Service Administrator. Note: this is the same administrative account as exists above in the EA Portal.

Co-administrator (CA) in the Azure classic portal

200 per subscription

This role has the same access privileges as the Service Administrator, but can’t change the association of subscriptions to Azure directories.

Just because you CAN create 200 co-administrators, doesn't mean you should. Think of these like domain administrators.  You need a couple for backup, but you really don't want more than a small handful unless absolutely necessary. As mentioned in the section above this, consider making a service account for the Account Administrator and also the Service Administrator.  Example account names could be something like aa_azure@contoso.com and sa_azure@contoso.com. For all other delegation of administration you will leverage the following two capabilities: the Azure Active Directory (AD) roles and then for more granular control, RBAC.

Azure Active Directory Administrative Roles

These administrative roles, along with RBAC below, are separate and distinct from any administrative roles for the "subscriptions" above.  These control authentication to Azure Resources either through the pre-defined roles below or through more granular controls further below in RBAC.

Global administrator

Has access to all administrative features. The person who signs up for the Azure account becomes a global administrator. Only global administrators can assign other administrator roles. There can be more than one global administrator at your company.

Billing administrator

Makes purchases, manages subscriptions, manages support tickets, and monitors service health.

Password Administrator

Resets passwords, manages service requests, and monitors service health. Password administrators can reset passwords only for users and other password administrators. In Microsoft Graph API, Azure AD Graph API and Azure AD PowerShell, this role is identified as "Helpdesk Administrator".

Service Administrator

Manages service requests and monitors service health.

User Administrator

Resets passwords, monitors service health, and manages user accounts, user groups, and service requests. Some limitations apply to the permissions of a user management administrator. For example, they cannot delete a global administrator or create other administrators. Also, they cannot reset passwords for billing, global, and service administrators.

Security Reader

Read-only access to a number of security features of Identity Protection Center, Privileged Identity Management, Monitor Office 365 Service Health, and Office 365 Security & Compliance Center.

Security Administrator

All of the read-only permissions of the Security Reader role, plus a number of additional administrative permissions for the same services: Identity Protection Center, Privileged Identity Management, Monitor Office 365 Service Health, and Office 365 Security & Compliance Center.

The details and specific capabilities of each of the Azure AD roles above are further detailed out at https://aka.ms/Azure/AD/Roles.

Role Based Access Control (RBAC)

This is where you get more granular delegation.  RBAC can start at the top level (subscription), be applied at a Resource Group, or down to any specific Azure Resource you create.  You can add either synchronized AD users or Cloud accounts i.e. those only created directly in Azure AD. These are the default permissions:

Owner

Has full access to all resources including the right to delegate access to others.

Contributor

Can create and manage all types of Azure resources but can’t grant access to others

Reader

Can only view existing Azure resources

To read more about Built in versus custom roles, see the RBAC resource links below.

But wait, there's more!

These are the most recent announcements, so for now will just link them, but you will definitely want to check these out as well!

  1. Roles in Azure AD Privileged Identity Management
    • Azure AD Privileged Identity Management (PIM) manages policies for privileged access for users in Azure AD. PIM assigns users to one or more roles in Azure AD, and you can assign someone to be permanently in the role, or eligible for the role. When a user is permanently assigned to a role, or activates an eligible role assignment, then they can manage Azure Active Directory, Office 365, and other applications with the permissions assigned to their roles.There's no difference in the access given to someone with a permanent versus an eligible role assignment. The only difference is that some people don't need that access all the time. They are made eligible for the role, and can turn it on and off whenever they need to.
  2. Administrative units management in Azure AD - Public Preview

Here are resources to dive into the various administrative capabilities from the EA portal down to the Azure Resources. This also gives credit to the sources for all the information listed above.

Comments

  • Anonymous
    November 08, 2017
    Hi, I found that the first link within the resource links section doesn't show an overview of all EA roles but an example Azure infrastructure walkthrough for Linux VMs. Can you please update?The link description sounded promising, so I'd be super interested to have it. Thank you in advance.
    • Anonymous
      May 05, 2018
      Sorry for the delayed response. I found that link you mentioned, but it seems that the original reference I had no longer exists. I've found that most EA links now only exist in the help file in the EA portal :( Which I never have access to.