MSP: The well-tempered Azure tenant – Part 1

This post will be the first in a series that I’ve been thinking about putting together for a while now. The series is designed to bring together a number of concepts that can be used to manage your Azure tenants in a well regulated, controlled and consistent manner.

I am writing this series from the point of view of how a managed service provider (MSP) might like to onboard and manage their Azure customers from their own partner or management tenant.

In fact, this will be the subject of this first post in the series. Setting up your partner management tenant. One tenant to rule them all!

Thanks to the emergence of Azure Lighthouse we now have a means to do cross-tenant management at scale. Azure Lighthouse is a service that provides delegated resource access from a management tenant to Azure subscriptions deployed on different customer tenants. I have blogged about this previously which you can read here.

Before we get into deploying Azure Lighthouse in detail let’s first talk about setting up our management tenant.

Diagram illustrating Azure delegated resource management.

Part 1: The management tenant

Identity

Some MSPs prefer to use a separate management tenant, one that is completely isolated from the MSP’s own corporate tenant. This is not mandatory but for larger MSPs you may want to have a dedicated tenant just for your Azure managed service offering. From my experience the vast majority of MSPs instead just use their own corporate tenant accounts to manage their customers.

Either approach is fine but I generally recommend to use the existing corporate tenant so long as that tenant itself is well managed. One thing that is crucial here is that you need to make absolutely certain that the tenant you will be using for management is as secure as it possibly can be. If these accounts were to be compromised then you could potentially find that a bad actor has access to not only your account but to all of your delegated customer resources also. Therefore, how you choose to secure your own tenant is not only for the security of your business but for that of your customers as well. You do not want to just do the bare minimum here!

Do not use shared accounts – Every user should have their own account. This is important as not only does sharing accounts come with an increased security risk (e.g. using shared credentials) it also affects governance. If you have several users sharing an account called ‘admin’ then this the the identity that you will see in all of the activity logs. This makes auditing and accountability very difficult as you may not be able to distinguish which individual actually performed those activities. Using individual accounts also makes it easier to manage access control to individual users rather than having to reset shared account passwords whenever somebody leaves the organisation.

Security

It is in fact now one of the contractual requirements from Microsoft for CSP transacting partners to at a minimum implement multi-factor authentication. You can read about those requirements here.

For an MSP however, this alone really isn’t good enough these days. With Azure Active Directory Premium P1 licensing you will have the option to deploy conditional access policies. This will all you to apply additional conditional requirements such as only permitting access to trusted (and compliant) devices and allowing trusted locations only. This approach massively improves the security level for your access controls.

I would take this a step further still by using the features of Azure Active Directory Premium P2. This will provide additional security features around identity protection and identity governance including privileged identity management which is now supported by Azure Lighthouse though still in public preview at the time of writing.

The point to remember is that the security of the managing tenant is paramount as this contains the identities (human or automated) that will be used to manage the delegated customer resources.

Security groups and RBAC

MSPs come in all different sizes but in most cases not every employee will be responsible for managing the customers’ Azure tenants. As is always the case with security you should adopt the principle of least privilege. In other words, only provide each account with enough privileges to perform their duties.

As Azure uses role based access control (RBAC) to provide granular levels of access management then we need to start by setting up security groups within Azure AD on the MSP’s managing tenant.

Depending on the size of the MSP and the types of customers (e.g. if they are heavily regulated), you may require many different security groups with different sets of privileges assigned via RBAC role assignments. You may also want to grant access only to smaller subsets of your customers rather than granting access to all customers when this is not necessarily required for all users.

I usually start out by recommending that MSPs keep it simple and provision a minimum of two security groups for their users, one group with full contributor level access and another with just reader access. These two levels of privileges are always likely to be useful at a minimum and then it’s up to the MSP themselves to decide if they need more granular access levels in between. Larger MSPs will certainly want to do this where they have dedicated service teams performing specific management and monitoring tasks only.

If the MSP is going to use accounts (service principals) for automation purposes (and they should) then you may want to have a dedicated security group for this also.

Additional groups can be created at any stage but it’s important to note that adding or removing security groups or changing the access levels of existing groups requires re-onboarding of customers to Azure Lighthouse.

You will be able to add or remove members to and from existing security groups without re-onboarding however.

Partner earned credit

As a Microsoft partner you may be entitled to earn rebates from Microsoft directly or if you are transacting on CSP then you can earn discounted pricing through a system called partner earned credit. Either way, you should make sure that your partner MPN ID is linked to your management tenant.

Then through your Azure Lighthouse delegation your associated MPN ID will get passed through to the customer Azure resources that you are managing giving you recognition for providing managed services on those resources.

You can learn all about how to set this up here.

What’s next?

In the next blog post I will discuss how to onboard your customer tenants to Azure Lighthouse and some initial practices you may want to implement when onboarding new customers.

This blog featured as part of Azure Week. Find more great Azure content here.

About the Author:

My name is Alan Kinane and I’ve been working with Microsoft Azure since 2014. I now work as a technical consultant focused on Azure and I also provide technical training to customers.

The purpose of this blog is to document procedures, talk about new services and features and also post about any other useful pieces of information that I find interesting. This is something I expect to use as a reference guide for myself as something of a personal knowledgebase but I thought perhaps these posts might be of interest to others in the community also.

I live in Dublin, Ireland and you can get in touch with me via my Twitter or LinkedIn below.

Reference:

Kinan, A. (2022). MSP: The well-tempered Azure tenant – Part 1. Available at: https://azurealan.ie/2022/01/25/msp-the-well-tempered-azure-tenant-part-1/ {Accessed: June 28th 2022].

Share this on...