This post is part of a mini-series that explains how Microsoft Customers, Azure AD Tenants, Azure Subscriptions and Cloud Solution Providers all work together.
It is aimed at anyone who wishes to purchase Azure resources from a Cloud Solution Provider (CSP) such as NewOrbit, as well as Microsoft Partners who wish to understand the relationship between CSPs and Customers better.
This is an immensely confusing topic that often stumps people who have spent years working with Azure - even as Partners.
I focus on explaining the concepts rather than being 100% technically correct. This means some of the detail is glossed over or simplified.
This series focuses on Partners providing Azure to Customers, but the Microsoft 365 side is inherently linked to this so there will be some straying into that area as well.
As an Azure Customer, you can buy Azure directly from Microsoft in a number of different ways or from a Cloud Solution Provider. You can even mix and match who you buy from and you can buy from multiple Partners at the same time.
The general idea is that when you buy through a Partner, you get not just Microsoft Azure but additional services and expertise from the Partner. More about the general concept in a previous post. In this post, we will look at what it means to buy Azure from a Cloud Solution Provider as a Customer in a bit more detail.
It is your Azure subscription
Your organization should only have a single Microsoft Customer Record and you should (normally) only have a single Tenant. Every Cloud Solution Provider you buy Azure from should make sure they create the Azure Subscription(s) under your existing Tenant. This means that you will always have full access to your Azure resources and you stay in control.
Support and Consultancy
When you buy Azure from a Cloud Solution Provider, you will get support from the Partner rather than from Microsoft.
Your Cloud Solution Provider should have a separate Partner Support Contract with Microsoft that allows them to raise support tickets on your behalf. This means that you don’t need to have - and pay for - a support contract with Microsoft yourself. For example, NewOrbit has an Advanced Support for Partners contract with Microsoft that not only allows us to raise support tickets on your behalf but also to create Cloud Consults to get access to experts in Microsoft to help answer broader questions and get advice about the solutions you wish to build on Azure.
In addition, your Cloud Solution Provider should have their own support team that can help you with your Azure resources. This is a key differentiator between different Cloud Solution Providers. At NewOrbit, we have a dedicated support team that is available to help you with your Azure resources. We also have a dedicated team of Azure Architects who can help you with more complex questions and help you design your solutions, as well as various specialist teams focusing on such things as Security and Infrastructure-as-Code etc. Unlike most Cloud Solution Providers, we also design, develop and run solutions for our Customers, so we have a lot of experience in running Azure in production.
When you buy your Azure from a Cloud Solution Provider, the Partner - not Microsoft - will bill you for your Azure consumption.
In order for a Cloud Solution Provider to be able to help you with your Azure resources, they need to be able to access them. There are several different ways to do this. Crucially, Cloud Solution Providers do not need to be Global Admins in your Tenant. In fact, they can provide Azure without having any access to your Tenant at all.
Some key concepts before we dive in:
- Tenant and Azure Active Directory are treated as interchangeable terms in this series.
- You have a Tenant, which has all of your Users. The users in your Tenant can be given access to your Azure Subscriptions.
- The Cloud Solution Provider has their own Tenant where their users are managed.
- A “Principal” is a term used to describe a user, group or service principal.
- A “Service Principal” is just a “system user” - i.e. it is a user in your Active Directory that is not a real person.
A word of warning: Some of the ways in which Cloud Solution Providers can get access to your Azure Subscription are quite complicated and can be difficult to set up in a way that segregates access on the Cloud Solution Provider side appropriately. Check with your Cloud Solution Provider how they segregate this access, for each of the methods listed below.
At NewOrbit we set up different levels of access for different users to each Customer and review the current access every month to remove users who no longer need access. We have a very small number of highly trusted “break glass” users who can access all Customers’ Azure Subscriptions, but they are not allowed to use this access unless there is a critical issue that cannot be resolved any other way.
The following sections will give a brief overview of the different ways a partner can access your Azure resources. Each of these will be covered in more detail in individual posts in this series.
When a Cloud Solution Provider creates an Azure Subscription for you, a special “Foreign Principal” will be given Owner permissions to the new subscription. This Foreign Principal is actually a special security group in the Cloud Solution Provider’s Tenant. No users or groups are added to your Tenant to enable this.
Users from the Cloud Solution Provider who are in this special “Admin Agent” security group can access your subscription as an Owner. They don’t, however, have any access to your Tenant by default, which limits what they can do. For example, as they can’t see any users in your Tenant, they cannot give any of your users access to the Subscription.
There is only a single “Admin Agent” security group on the Cloud Solution Provider side, by design. This means that all users in the Cloud Solution Provider who are in this group will have access to all Azure Subscriptions created by the Cloud Solution Provider. It is important that your Cloud Solution Provider limits the number of people in this group to the bare minimum and uses other means of access for day to day operations.
Note: If required, you can reduce the permissions for this Foreign Principal. We don’t normally recommend you do this as it can make it harder for the Cloud Solution Provider to help you, but it is possible.
GDAP (and DAP)
Granular Delegated Access Privileges is a way to give very specific (granular) permission to the Partner’s Foreign Principal to access certain things in your Tenant. For an Azure Partner, the most useful permission you can give them is Directory Reader: This will allow the Cloud Solution Provider to see a list of users in your Tenant and to give those users access to your Azure Subscription. This, in itself, significantly simplifies the onboarding process for new Azure Subscriptions.
GDAP permissions automatically expire after a period of time, which is a good thing. In our experience, GDAP is mostly useful in the initial setup phase anyway: Once the Cloud Solution Provider has set up the Azure Subscription, they should use other methods to access it.
Delegated Access Privileges (DAP) gives the Partner full admin rights to your entire Tenant, which may be useful for Microsoft 365 support but is significant overkill for Azure. It is, in any case, deprecated and should not be used.
Lighthouse is a flexible but somewhat complicated way of giving a Cloud Solution Provider access to your Azure Subscriptions. It allows the Partner to specify specific permissions in your subscription to specific users or groups in the Partner’s Tenant. Done correctly, this is much more secure and flexible than Foreign Principal access. It is conceptually similar to the Foreign Principal, but more fine-grained and it allows the Partner to give different users different permissions to different Customers’ Azure subscriptions.
Unfortunately, it does not integrate with GDAP so a Lighthouse user cannot see users in your Tenant, nor can they manage Service Principals or Azure DevOps for you.
Lighthouse should be the preferred method for day-to-day access to your Azure Subscriptions from the Partner.
While Lighthouse is useful for everyday access and support, there are several things it cannot do. If your Partner carries out significant configuration work on your Azure or develops and deploys systems for you, it is often a good idea to create some Guest Users.
A Guest User exists in your Tenant, but it links to a user in the Partner’s Tenant. This means that the Partner user can log in with their existing credentials and security controls but work in your Azure subscription in a similar way to a “native” user in your Tenant - just with much fewer permissions by default.
This has a range of benefits, including allowing the Partner user to assign permissions to your users, manage Service Principals (as long as you give the Guest User the Application Developer role) and use your Azure DevOps.
It is possible for you to create a “Member” user in your Tenant for the Partner to use. This is not recommended as it means that the Partner user will have to manage a separate set of credentials and security controls. It also means that if the user leaves the Partner, they will still have access to your Azure Subscription unless you remember to remove them. In contrast, a Guest User will automatically be disabled when the Partner user leaves the Partner’s Tenant.
There are some rare scenarios where a Partner may legitimately need a Member user in your Tenant, but these are very rare and should be avoided if at all possible.
Working with a Cloud Solution Provider can bring you significant benefits compared to buying directly from Microsoft; You are buying from a smaller company and you can choose a Partner who knows your industry and challenges much better.
Done correctly, the Partner’s access to your Azure resources can be tightly controlled and proportionate. Just make sure you work with a Partner who understands the different access methods, when to use them and who has clear policies and procedures for managing access.
Don’t be satisfied with a Partner who wants to be a Global Admin in your Tenant (unless they are managing your Microsoft 365) or someone who insist you create a separate Tenant for the Azure they provide to you.