Azure Lighthouse–Enabling Centralized Management of Many Azure Tenants

In this post, I will discuss a new feature to Azure called Lighthouse. With this service, you can delegate permissions to “customer” Azure deployments across many Azure tenants to staff in a central organization such as corporate IT or a managed service provider (Microsoft partner).

The wonderful picture of the Hook Head Lighthouse from my home county of Wexford (Ireland) is by Ana & Michal. The building dates back to just after the Norman invasion of Ireland and is the second oldest operating lighthouse in the world.

Here are some useful web links:

In short what you get with Lighthouse is a way to see/manage, within the scope of the permissions of your assigned role, deployments across many tenants. This solves a major problem with Azure. Microsoft is a partner-driven engine. Without partners, Microsoft is nothing. There’s a myth that Microsoft offers managed services in the cloud: that’s a fiction created by those that don’t know much about the actual delivery of Microsoft services. Partners deliver, managed, and provide the primary forms of support for Microsoft services for Microsoft’s customers. However, Azure had a major problem – each customer is a tenant and until last night, there was no good way to bring those customers under the umbrella of a single management system. You had hacks such as guest user access which didn’t unify management – native management tools were restricted to the boundaries of the single customer tenant. And third-party tools – sorry but they’ll not keep up with the pace of Azure.

Last night, Microsoft made Lighthouse available to everyone (not just partners which the headlines will suggest!). With a little up-front work, you can quickly and easily grant/request access to deployments or subscriptions in other tenants (internal or external customers) and have easy/quick/secure single-sign-on access from your own tenant. What does that look like? You sign in once, with your work account, ideally using MFA (a requirement now for CSP partners). And then you can see everything – every tenant, every subscription, every resource group that you have been granted access to. You can use Activity Log, Log Analytics Workspace, Security Center, Azure Monitor across every single resource that you can see.

The mechanics of this are pretty flexible. An “offer” can be made in one of two ways to a customer:

  • JSON: You describe your organization and who will have what access. The JSON is deployed in the customer subscription and access is granted after a few moments – it took a couple of minutes for my first run to work.
  • Azure Marketplace: You can advertise an offer in the Azure Marketplace. Note that a Marketplace offer can be private.

An offer is made up of a description of:

  • The service you are offering: the name, your tenant (service provider)
  • The authorizations: who or what will have access, and what roles (from your tenant) can be used. Owner is explicitly blocked by Microsoft.

Here’s a simple example of a JSON deployment where a group from the service provider-tenant will be granted Contributor Access to the customer subscription.

I need to gather a bit of information:

  • mspName: The name of the managed services provider. Note that this is a label.
  • mspOfferDescription: The name of the service being offered.
  • managedByTenantId: The Directory ID of the managed services provider (Azure Portal > Azure Active Directory > Properties > Directory ID)
  • Authorizations: A description of each entity (user/group/service principal) from the MSP tenant being granted access to the customer deployment
    • principalId: The ID of the user, group, or service principal. Remember – groups are best!
    • principalIdDisplayName: A label for the current principal – what you want to describe this principal as for your customer to see
    • roleDefinitionId: The GUID of the role that will grant permissions to the principal, e.g. Contributor. PowerShell > (Get-AzRoleDefinition -Name ‘<roleName>’).id

Armed with that information you can populate the fields in a JSON parameters file for delegating access to a subscription. Here’s a simple example:

    "$schema": "",
    "contentVersion": "",
    "parameters": {
        "mspName": {
            "value": "Cloud Mechanix"
        "mspOfferDescription": {
            "value": "An amazing service"
        "managedByTenantId": {
            "value": "12345678-1234-1234-abcd-efghijklmnop"
        "authorizations": {
            "value": [
                    "principalId": "abcdefgh-ijkl-mnop-1234-56789012345",
                    "principalIdDisplayName": "Tier 1+ Support By Cloud Mechanix",
                    "roleDefinitionId": "1a2b3c4d-1234-a1b2-c3d4-asdfghjkjlqwert"

And then you can deploy the above with the JSON file for delegating access to a subscription:

  1. Sign into the customer tenant using PowerShell
  2. Run the following:
New-azdeployment -Name "CloudMechanixDelegation" -Location westeurope -TemplateFile .\delegatedResourceManagement.json -TemplateParameterFile .\delegatedResourceManagement.parameters.json

Give it a few minutes and things will be in place:

  • The service provider will appear in Service Providers in the Azure Portal for the customer.
  • The customer will appear in My Customers in the Azure Portal for the service provider.
  • Anyone from the subscriber’s tenant in the scope of the authorization (.e.g. a member of a listed group) will have access to the customer’s subscription described by the role (roleDefintionId)
  • Any delegated admins from the service provider can see, operate. manage the customers’ resources in the Azure Portal, Azure tools, CLI/PowerShell, etc, as if they were in the same tenant as the service provider.

Once deployed, things appear to be pretty seamless – but it is early days and I am sure that we will see weirdness over time.

The customer can fire the service provider by deleting the delegation from Service Providers. I have not found a way for the service provider to fire the customer yet.

Azure Management Groups

Microsoft has created a new administrative model for organisations that have many Azure subscriptions called Management Groups. With this feature, you can delegate permissions and deploy Azure Policy (governance) to lots of subscriptions at once.

The contents of this post are currently in preview and will definitely change at some point. Think of this post as a means of understanding the concepts rather than being a dummy’s guide to mouse clicking. Also, there are problems with the preview release at the time of writing – please read Microsoft’s original article before trying this out.

Note: Microsoft partners working with lots of customers, each in their own tenant, won’t find this feature useful. But larger organisations with many subscriptions will.

The idea is that you can create a management/policy hierarchy for subscriptions, as shown in this diagram from Microsoft:


The hierarchy:

  • Can contain up to 10,000 subscriptions in a single tenant.
  • It can span EA, CSP, MOSP, etc, as long as the subscriptions are attached to a single tenant.
  • There can be up to 6 levels of groups, not including the root (tenant) and the subscription.
  • A management group can have a single parent, but a parent can have many children.


The tenant has a default root management group, under which all other management groups will be placed. Tenant = Azure AD so we see a cross-over from Azure to Azure AD administration here. By default, the Directory Administrator needs to elevate themselves to manage the default group. You can do this by opening the Azure Portal, browsing to Azure Active Directory > Properties, and setting Global Admin Can Manage Azure Subscriptions And Management Groups to Yes:


Now you have what it takes to configure management groups.


Allegedly today we can use Azure CLI or PowerShell to create/configure management groups, but I have not been able to from my PC (updated today) or from Azure Cloud Shell. However, the Azure Portal can be used. You’ll find Management Groups under All Services.

Creating a management group is easy; simply click New Management Group and give the new group a unique ID and name.


Here I have created a pair of management groups underneath the root:


To create a child management group, open the parent and click New Management Group:


I can repeat this as required to build up a hierarchy that matches my/your required administration delegation/policy model. How I’ve done it here isn’t probably how you’d do it.


This is what the contents of the Lab management group look like:


Delegating Permissions

In the old model, before management groups, permissions to subscriptions were created at the subscription level, leading to lots of repetitive work for large organisations with lots of subscriptions.

With management groups we can do this work once in the management group hierarchy, and then add subscriptions to the correct locations to pick up the delegations.

The “how” of managing the settings, memberships and permissions of a management group is not obvious. The buttons for managing a management group are hidden behind a “Details” link – not a button! See below:


Once you click Details, the controls for configuring the settings and subscription memberships of a management group are revealed in a new, otherwise hidden, blade:


Universal permissions should be assigned at the top level management group(s). For example, if I click Access Control (IAM) in the settings of the root management group, I can grant permissions to the root management group and, thanks to inheritance, I have implicitly granted permissions to all Azure subscriptions in my hierarchy. So a central Azure admin team would be granted rights at the default root management group, a division admin might be granted rights on a mid-level management group, and a dev might be given rights at a bottom-level management group.

Once you are in Details (settings) for a management group, click on Access Control (IAM) and you can grant permissions here. The users/groups are pulled from your Azure AD (tenant). As usual, users should be added to groups, and permissions should be assigned to well-named groups – I like the format of <management group name>-<role> for the group names.


Azure Policy

You can create a new Azure Policy and save it to a management group. Microsoft recommends that custom policy definitions are saved at a level higher than what you intend to assign it. The safe approach might be to save your custom policy definitions and initiative definitions at the root management group, and then assign them wherever they are required. Note that, just like permissions, any assigned initiative (recommended for easier ownership) or policy (not recommended due to ownership scaling issues) will be inherited. So if my organization requires Security Center to be enabled and OMS agents to be deployed for every VM, I can create a single initiative, stored at the root management group, and assign it to the root management group, and every VM in every subscription in the management group hierarchy will pick up this set of policies.

Here’s an example of where you can select a management group, subscription, or resource group as the target of an initiative definition assignment in Azure Policy:


Adding Subscriptions

Right now, we have a hierarchy but it’s useless because it does not contain any subscriptions. THE SUBSCRIPTIONS MUST COME FROM THE CURRENT TENANT.

Be careful before you do this! The delegated permissions and policies of the hierarchy will be applied to your subscriptions, and this might break existing deployments, administrative models, or governance policies. Be sure to build this stuff up in the management group hierarchy first.

To add a subscription, browse to & open the management group that the subscription will be a part of – a subscription can only be in a single management group, but it will inherit from parent management groups.

Click Add Existing to add a subscription as a member of this management group. This is also how you can convert an existing management group into a child of this management group. A pop-up blade appears. You can select the member object type (subscription or another management group). In this case, I selected a subscription.


The subscription will be registered in the management group hierarchy.



And that’s management groups. Don’t waste your time with them if:

  • You’re a Microsoft partner looking for a delegation model with customer’s tenants/subscriptions because it just cannot be done.
  • You have only a single subscription – just do your work at the subscription level unless you want to scale to lots of subscriptions later.

If you have a complex organisation with lots of subscriptions in a single tenant, then management groups will be of huge value for setting up your RBAC model and Azure Policy governance at the organisational and subscription levels.

Did you Find This Post Useful?

If you found this information useful, then imagine what 2 days of training might mean to you. I’m delivering a 2-day course in London on July 5-6, teaching newbies and experienced Azure admins about Azure Infrastructure. There’ll be lots of in-depth information, covering the foundations, best practices, troubleshooting, and advanced configurations. You can learn more here.