We’ve published some updated guidance for Service Admin account management based on the new RBAC access control techniques now available in Azure. While the classic non-RBAC portal is required, the content in the post here is still very relevant though!

Overview

Over the years it has been drilled into me to use “Least Privilege” access whenever and however possible. Least Privilege is all about limiting users, systems, and services to only those privileges which are absolutely essential to get the job done. Microsoft Azure should be no different and some would argue even more important when it comes to Least Privilege. However what tends to happen in the cloud space is business units want to avoid/bypass IT Departments and setup in the case of this article Microsoft Azure subscriptions without much thought. This can lead to incorrect users having access to production services and once discovered is hard to correct as once services are deployed you can’t easily move services between subscriptions.

Microsoft Azure Subscription Components:

Enterprise Administrator

Standard Customer – Not Applicable

Enterprise Agreement Customers – The Enterprise Administrator has the ability to add or associate Accounts to the Enrolment, can view usage data across all Accounts, can view the monetary commitment balance associated to the Enrolment, and can provide Account Owner visibility to view charges.

There is no limit to the number of Enterprise Administrators on an Enrolment.

Account Owner

Standard Customer – The Account Owner is the Microsoft Account (formerly Live ID) or Azure Active Directory (AAD) Account that is responsible financially for the Microsoft Azure monetary commitment. Microsoft will send invoices to the email address associated with the Account Owner. The Account Owner can add Subscriptions for their Account, update the Service Administrator and Co-Administrators for an individual Subscription and view usage data for their Account.

Enterprise Agreement Customers – this definition changes slightly. The Account Owner (by default) will not have visibility of the monetary commitment balance unless they also have Enterprise Administrator rights. An Enterprise Administrator can choose to grant the Account Owner the rights to view the monetary commitment.

There is a limit of 1 Account Owner for each Account.

Subscription

A Subscription is a billing container for deployed Microsoft Azure services.

There is a limit of 1 Service Administrator for each Subscription.

There is a limit of 200 Co-Administrators for each Subscription.

Service Administrator

The Service Administrator can perform all functions within a Subscription including add/remove Co-Administrators. By default the Service Administrator will be the same as the Account Owner.

Co-Administrator

A Co-administrator can perform all functions within a Subscription except change the Service Administrator and add/remove other Co-administrators.

Use Multiple Microsoft Azure Subscriptions

Multiple Subscriptions allow a company to easy view billing for each Subscription and limit who can access the Microsoft Azure services associated with that subscription.

An example of using multiple subscriptions might be:

Subscription 1

  • Name: “Company – Project 1 – Development”
  • Service Administrator: Development Manager
  • Co-Administrators: Developers on Project 1

Note: A developer may not need to be a Co-Administrator but instead only require a Management Certificate as explained below.

Subscription 2

  • Name: “Company – Project 1 – Test”
  • Service Administrator: Test Manager
  • Co-Administrator: Testers on Project 1

Subscription 3

  • Name: “Company – Project 1 – Pre-Production”
  • Service Administrator: IT Manager
  • Co-Administrator: Senior IT Support Team (Level 3)

Subscription 4

  • Name: “Company – Project 1 – Production”
  • Service Administrator: IT Manager
  • Co-Administrator: Senior IT Support Team (Level 3)

Use Descriptive Names for Microsoft Azure Subscriptions

When it comes to naming a Microsoft Azure subscription, it is good practice to use descriptive names.

I typically recommend the following format, but as long as you develop a format that works for your company go for it.

My Recommendation:

<Company> – <ProjectName> – <Environment>

Explanation of My Recommendation

<Company> is the name of your company. You might be wondering “Why would I add my company name to my company’s Subscriptions that seems a little overkill”. The reason I recommend this is if/when you hire a contractor or outside company to assist you with your Microsoft Azure services you will most likely need to make then a Co-administrator on a particular Subscription. When that contractor/company logs into the Microsoft Azure portal they see a list of all subscription they are associated with. So they might see: CustomerASubscription1, CustomerASubscription2, CustomerBSubscription1, etc.

If you named your Subscription “Development” and some other company named their Subscription “Development” then the contractor/company would see “Development” and “Development” in the list. To me that adds a risk where they could accidentally perform some action on the wrong Subscription. The risk is pretty small as they would more than likely also need to know the service name such as storage account “XYZ”, but still a risk is a risk and when possible should be mitigated.

<ProjectName> is the name that your project is known by. You might have one project that is all about your company’s intranet which is called “Inside” and another project that is all about your company’s public web site. In this case you might have one set of service for “Inside” where you use “Inside” as the project name and another set of services for your public website where you might use the name “PublicWebsite” as the project name.

Now you might be thinking “That seems like I might end up with a lot of Subscription in the end which is pretty overkill”. Yes, you are correct you might, but then again I would rather have a lot of Subscriptions that I can control access to over, say, one big Subscription called “Production”. Plus do I really want the administrator of ProjectA having full access to ProjectB services in Production?

<Environment> is the name I choose to use because in most of the deployment of Microsoft Azure services I have worked with, that really is what it turns out to be. A group of Microsoft Azure services that all form part of “Development”, “Test”, or “Production”.

NOTE: I don’t recommend using an environment name of “Staging” because I feel that it can become confusing when Windows Azure deployments have two slots “Staging” and “Production”.

Use Named User Accounts

A named account is an account that is associated to a single person and typically named in such a way as to identify that person. Example: First.Last@outlook.com instead of SweetGuy88@outlook.com. You might know who SweetGuy88 is today but in six months times I bet you forget who that is and have to run around trying to figure it out. Save yourself the hassle and used named accounts day 1 where possible.

Another thing I recommend is that you setup named accounts @ your company name instead of @hotmail, @outlook, etc. When you setup a Microsoft Account, you are required to verify your identity which means Microsoft sends an email to first.last@company.com that you must click verify before the account is considered verified. When I use contractors or outside companies I recommend that they setup the accounts to be the same as the work email address I know them by. This helps me as an administrator identity who is inside my organisation and who isn’t.

Establish Guidelines for Microsoft Accounts (formerly Live IDs)

Microsoft Accounts are out of your company’s control for the most part. As such I recommend you establish some guidelines for Microsoft Accounts that you try and push your users to adopt. It would be nice if Microsoft had a way to setup Enterprise Microsoft Accounts that as an Enterprise I could better control. Federation with Microsoft Azure Active Directory helps in this matter but does not solve the problem 100%.

The Guidelines I personally use are:

  • Use a strong password. Example: 16 characters long with mixed case and numbers. The longer and more complicated the better. If this account is associated with your production Windows Azure subscription, then this account can access not only the Microsoft Azure services (Stop/Delete services) but also has access to all the data in your storage accounts within the associated Subscription.
  • Use a named account. Use an account name that is easy to identity. first.last instead of SweetGuy88.
  • Link to your company email. This way the account will have to be verified using a company email address they have access to. Also if the person leaves your organisation you may in some cases be able to reset the password if required.
  • Change Passwords Regularly. This is always a good practice but is becoming harder and harder to do when we have so many passwords to remember. If remembering passwords becomes an issue a tool such as LastPass or KeePass might provide assistance.
  • Add Alternate email address. I also associate with my Microsoft Account another email address so that if I forget my password, I have another ways to get back in.

Use Microsoft Azure Affinity Groups

Microsoft’s Definition – Affinity groups allow you to group your Microsoft Azure services to optimize performance. All services within an affinity group will be located in the same data center. An Affinity Group is required in order to create a virtual network.

Why is this a good practice? Originally when Microsoft Azure datacentres were built, latency between different parts of the datacentres could be high. Today this is less of a reason to use Affinity Groups as Microsoft datacentres are now built in a way to keep latency down. Affinity Groups are now used mainly to simplify deployment of services, instead of having to pick both a Region and Subscription you only need to pick an Affinity Group. Affinity Groups are used in all of Microsoft’s backend management logic of Microsoft Azure. When services are moved, restarted, restored, etc. an Affinity Group is taken into an account and treated as a set of services and kept close together and in the same physical datacentre. Once services are deployed you can’t move services easily into an Affinity Group.

Use Management Certificates

Microsoft’s Definition – Management Certificates permit client access to resources in your Microsoft Azure subscription. Management certificates are x.509 v3 certificates that only contain a public key, and are saved as a .cer file.

If a person requires the ability to deploy or change services running in Microsoft Azure but does not require access to the Azure Management Portal, then provide them only a Management Certificate. This scenario is common with a large development teams. A developer that needs to deploy to Microsoft Azure services through a tool such as Visual Studio may only require a Management Certificate.

NOTE: There is a limit of 100 management certificates per Microsoft Azure subscription. There is also a limit of 100 management certificates for all Subscriptions under a specific Service Administrator’s user ID. If the user ID for the Account Administrator has already been used to add 100 management certificates and there is a need for more certificates, you can add a Co-Administrator to add the additional certificates.  Before adding more than 100 certificates, see if you can reuse an existing certificate. Using Co-Administrators adds potentially unneeded complexity to your certificate management process.

Standard Customer – Good Practice Setup

Standard Customer - Good Practice Setup

Enterprise Agreement Customers – Good Practice Setup

Enterprise Agreement Customer - Good Practice Setup

Summary of Good Practices

  1. Use Multiple Microsoft Azure Subscriptions
  2. Use Descriptive Names for MicrosoftAzure Subscriptions
  3. Use Named User Accounts
  4. Establish Guidelines for Microsoft Accounts (formerly Live IDs)
  5. Use Microsoft Azure Affinity Groups
  6. Use Management Certificates.
We’ve published some updated guidance for Service Adminaccount management based on the new RBAC access control techniques now available in Azure. While the classic non-RBAC portal is required, the content in the post here is still very relevant though!
Category:
Azure Platform, Business
Tags:
, , , , , ,

Join the conversation! 29 Comments

  1. Hi! I could have sworn I’ve been to this website before but after browsing through some of the post I realized it’s new
    to me. Nonetheless, I’m definitely delighted I found it and I’ll be bookmarking and checking back often!

    Reply
    • I am glad you have found our blog posts helpful.

      Reply
    • Time for an update. I would think most of this article will change with the advent of resource groups/templates, network security groups and RBAC. I am in the process of rolling out an environment for our enterprise that looks more like a dev/dmz split, but shared nonetheless. Also, my advise differs from your own regarding naming conventions. I went with a strict naming model that looks more like site codes. This allowed me to automate more predictably and removes less guess work for administrators. Regarding contractors, the only co-administrators in our subscription are IT. This prevents people from adding their “buddys”. We use federation and all contingent workers, must use a domain account. This ensures access is removed from all systems when employment is terminated.

      Reply
    • I have a user who has role of owner at a subscription level.
      He is using SQL stretch database – and getting error- you do not have any subscription .

      Only work around we have found is adding him as co-admin – but does not seem to be a best practice.
      Is there any other way or work around ?

      Reply
  2. Outstanding write-up. The one thing I would add for Enterprises is that it is now possible to be completely free of Microsoft accounts and use organizational IDs via ADFS to manage the Enterprise Portal as well as Subscriptions. This represents the best option as it allows you the ability to expire accounts and manage passwords and is really a no brainer for Enterprise customers.

    Reply
    • Hi Kelly,

      I agree that using ADFS could help to reduce the dependency around Microsoft accounts. I didn’t add good practices in this blog post relating to ADFS because I personally haven’t worked with ADFS and Windows Azure for management of Azure portal. My understanding from Microsoft is that some accounts are still required to be Microsoft Accounts so I am not sure if you can move away completely.

      Kind Regards,
      David

      Reply
    • Except when there’s an issue with the ADFS configuration in Azure and you have no Microsoft accounts to log in with 🙂

      Reply
  3. Fantastic summary, you literally saved me days of research. One thing I can add that i’ve learned about an enterprise account is that when signing up you can have a systems architect on-site for a day to discuss deployment strategies.

    Active Directory is also a huge benefit for an enterprise account, but it looks like MSFT is heading towards Azure Active directory with app integrations, so maybe WAAD can help provision and suspend windows live accounts.

    Billing management was another key differentiation, but this seems like a reasonable work around.

    Reply
  4. […] Good Practices for Managing Windows Azure Subscriptions | Kloud Blog (blog.kloud.com.au) […]

    Reply
    • Great post!

      Do you know, does volume monthly commitment and corresponding discount apply at the account or subscription level?

      Reply
      • Hi Jon,

        Thank you. I will try and answer your question.

        Q: Does volume monthly commitment and corresponding discount apply at the account or subscription level?
        A: Volume monthly commitment applies at the subscription level. If you do a large commit with Microsoft on an Enterprise Agreement, then this is applied at the Account level.

        Hope this is helpful.

        Kind Regards,
        David

  5. can we add sub subscriptions to an EA account at any later stage ? and how can we do that ?
    Also, if an EA account bought let’s say $75K of Azure, how can we add subscriptions and allocate usage quota for each, let’s say add a subscription and give it $25k of azure to spend and add another with $75k to spend.

    Reply
    • Hi Rami,

      Sorry for the delay in responding, I had to do some research on your questions.

      Q: Can we add sub subscriptions to an EA account at any later stage?
      A: Yes you can

      Q: How can we do that?
      A: When you are logged into the Enterprise Azure Portal, you will have the option.

      Q: EA account bought let’s say $75K of Azure, how can we add subscriptions and allocate usage quota for each, let’s say add a subscription and give it $25k of azure to spend and add another with $75k to spend
      A: At this point you do not have the ability to allocate quota’s by subscription. You can run reports showing subscription spend to date.

      Hope this is helpful.

      Kind Regards,
      David

      Reply
  6. […] shared 3 times • blog.kloud.com.au Good Practices for Managing Windows Azure Subscriptions | Kloud Blog […]

    Reply
  7. I enjoyed this blog. A few thoughts:

    EA accounts expire eventually, so if you sign up for one then you don’t renew, you will have to work through the process of moving those subscriptions to another place. This isn’t difficult unless you have PAAS services, which makes the migration tougher.

    Microsoft won’t let you “bundle” Azure spend to get discounts. In other words, if your finance department isn’t good at sorting out use and billing-back, its best each business gets its own EA. If one EA buys the minimum to get the ~33% discount and another does not, they don’t both get the discount just because its the same company. Because of this, we are using Account Portals vs. Enterprise Portals unless we’re guaranteed to have the minimum and a multi-year commitment.

    You should use an OrgID for Account sign-up. This puts your ADFS/SSO WAAD as the anchor of your Azure account and subscriptions. Signing up with LiveID and trying to do this later doesn’t work.

    You should use service accounts for azure account owners. This way if someone leaves the company you aren’t disrupting access. It is not an easy step to change Azure account owners.

    Reply
  8. The above description of the Enterprise Administrator, indicates the ability to provide Account Owner(s) visibility to view charges. Is there a blog post, MSDN, or TechNet document discussing how to do this and other Enterprise Admin tasks?

    Reply
  9. Would love to see you update your description.
    1) The enterprise admin can enable the Account owner to see the costs associated with their subscriptions.
    2) It is no longer 9 co-admins but 199

    Reply
  10. Cool, this is the way we are using Azure subscription as well. As an EA customer it was very difficult for us to track our costs. Because of that we invited a free services to manage Azure cost consumption when working with an EA contract. Just visit https://costs.azurewebsites.net

    Reply
  11. […] subscription and service management. In a previously well-received blog post, one of my colleagues provided good guidance around subscription management as it applied to Azure at that […]

    Reply
  12. Can a single email address be registered as the account owner of multiple azure subscriptions?

    Reply
  13. Anyone know how many subscription we can create under single EA?

    Reply
    • Not sure of the exact limit, but, Microsoft recommend as a best practice to limit the number of subscriptions. In most cases, a single subscription is recommended (which is also the case for any new customers to Azure). However, having worked with customers with one and up to a dozen subscriptions, the old saying of “less is more” certainly is true.

      Reply
  14. I have 5 different Azure environments to manage, do you know of a tool to easily switch between them? I now have 3 different browsers in 6 modes to be able to login, it’s a hassle.

    Reply
    • Hi Rick, I’d leverage Azure AD B2B. That way you can have a common set of credentials that spans across your subscriptions. In the Azure portal, you can then switch subscriptions easily via clicking on your name. Secondly, when in Powershell use “select-AzureRMSubscription -SubscriptionName “.

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: