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.

6 thoughts on “Azure Lighthouse–Enabling Centralized Management of Many Azure Tenants”

  1. Hello Aidan,


    just my two cent for the minimal improvement you need :
    for the service provider to revoque delegation of the customer subscription there is a trick (documented by Microsoft)

    source from :

    i quote : We recommend assigning the Managed Services Registration Assignment Delete Role when onboarding a customer, so that users in your tenant can remove access to the delegation later if needed. If this role is not assigned, delegated resources can only be removed by a user in the customer’s tenant.

    kind regards and keep up the great work !

  2. Hi,

    Great post. I have followed the ARM template process to implement lighthouse in two different free trail accounts, but post deploying the script in powershell, i can see the MSP details from customer side, but cant see any customer details from MSP side.

    I went ahead from customer side to delegate permissions from service provider page by clicking the + button at the right most end of the screen and then added MSP subscription. But i got ended up with this error saying that delegation failed. Can someone pls enlighten me where i did wrong 🙁

    Another registration assignment present at this scope ‘/subscriptions/1e************76’ for registration definition ‘/subscriptions/1e***********76/providers/microsoft.managedservices/registrationdefinitions/479****************f7’. Multiple registration assignments are not allowed.

  3. Our client will be migrating from their existing azure subscription to the CSP subscription that we have stood up, which is where Microsoft Sentinel lives. The clients VM‘s specifically servers live in their existing subscription if I want to connect the AMA security events, data connector what permissions are required to pass validation? At the moment, validation is failing specifically on servers VM‘s that live in the clients existing azure subscription.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.