The power of Azure Lighthouse

The power of Azure Lighthouse

One of the biggest challenges facing partners offering support around Azure is how best to permission access across multiple customer tenancies. Specifically how to assign the correct level of permissions to users that require them and how to monitor the users once access is enabled.

Another problem that goes hand in hand with this is how to centrally manage and monitor large volumes of resources, spread across various customers, whilst using a single shared set of tools and dashboards.

Until Azure Lighthouse, access for support would often be configured in one of the following ways:

  • Dedicated accounts within the customer tenancy (Azure AD) for partners to use for support
  • Partner accounts added as guests to every customer tenancy using Azure B2B

Contacting customers every time the partner takes on a new member of the support team. Having permissions assigned to individual guest accounts rather than security groups. Support staff switching constantly between directories. Are just some of the problems that highlight that neither option is suited to offering support at scale.

CSP partner accounts with enough permissions can use Administer-on-Behalf-Of (AOBO) to offer support. AOBO offers access to customer subscriptions at an administrator level. This method of access is generally a concern to both customers and partners. Would you really want a backup admin having full access to all services?

Azure Lighthouse uses delegated resource management to project resources from customer Azure environments, into a single partner tenancy. Delegated partner accounts can then view resources from all customer tenancies within a single portal for centralised management.

At a high level, security groups are created in the partner’s tenant, based on support roles. Users are then assigned to those security groups. In the customer’s tenancy, the required amount of permissions can then be assigned to these security groups using RBAC roles. Delegate access for these groups can then be assigned at the subscription or resource group level.

Benefits include:

  • Resources spread across multiple customers can be managed from a single portal
  • Single instances of native Azure services can be used, for example, Service Health, Azure Advisor, Azure Monitor, Security Center (A full list of enhanced services can be found here)
  • Governance can be applied centrally across all of your tenants for consistency
  • Share dashboards can be populated with information from multi-customers
  • Azure security across the entire customer base is easily visible from one location
  • More opportunity for unified automation and reporting using scripting and APIs

Ultimately, this should enable easier management at scale across your entire customer base. No more switching directories!

Delegating access or “onboarding” can be done in one of two way.

  1. Deploying an ARM template into the client’s subscription to enable delegation management as defined within the template
  2. Customer offer that has been previously published to the Marketplace.

NOTE: It is not currently possible to do this via the portal, Azure CLI or cloud shell.

Using an ARM template to Onboard

Microsoft has made available various sample templates that can be found in this Github Repository. In the following example, I’m going to be onboarding a customer at the subscription level. I’ve downloaded the template that best fits this scenario and now need to modify it to represent the offer.

Each template comes with a parameters file which needs to be populated with the following offer information:

  • mspOfferName: Name describing the offer
  • mspOfferDescription: Description of the offering
  • managedByTenantId: Partner tenant ID
  • Authorizations:  Description of each entity (user/group/service principal) from the partner tenant being granted access to the customer deployment

Having gathered the information above, I can populate the parameters.json file.

Now that I have a template for the offer, I need to deploy the template in the customer’s tenant. Although I’m running it at the subscription level, if the customer has multiple subscriptions, this would need to be repeated for each.

I’m going to use PowerShell to kick off the deployment but it could as easily be done with Azure CLI.

Once the deployment has run, I can go ahead and confirm the delegated link has been properly established.

Logged in as the customer I can browse to the Service providers blade, click on Delegations and then select the respective offering to view what roles have been assigned to the partner.

The image below shows that the Tier 1 Support and Tier 2 Support groups have been successfully assigned with the roles outlined in the parameters.json file passed to the deployment.

Having seen how this appears to the customer, let’s now switch and take a look from the service provider perspective.

Once signed in to the Azure portal as the supporting partner, I browse to the My customers blade. From here I can see the customers who I have delegated access to manage, the role assignments and subscriptions or resources groups that the partner has permissions over.

If I switch to the Virtual machines blade, I can now view virtual machines provisioned across all of my customers from the single window. This shared experience is similar across all Azure services that are now integrated with Azure Lighthouse, for example, Azure Advisor, Security Center, etc.

Removing delegation

If support is no longer required by the customer, the offering or delegation can simply be removed. Browse to the Service provider blade within the portal, select the offering or delegation and then click on the Delete button.

As you would expect, it’s also possible to remove the delegation using PowerShell or Azure CLI as outlined in this Microsoft article.


When planning to integrate Azure Lighthouse for the first time, there are a couple of security recommendations and general best practices that are worth keeping in mind.

  • Multi-Factor Authentication should be enforced
  • Use the least privilege principle when assigning permissions
  • Consider using Privileged Identity Management (PIM)
  • Where possible try not to assign access to entire subscriptions unless required
  • Use Azure Policy to enforce standards across all of your customers
  • Include a user with the Managed Services Registration Assignment Delete Role
  • Any user who needs to view the My customer’s page in the Azure portal has the Reader role (or another built-in role which includes Reader access).

For a more in-depth look into the Azure Lighthouse service and what it offers, take a look at Microsoft docs:

Reader Comments

  1. Hi , first of all great article!

    i have a question regarding using PIM or integrate this. How did you implement this? do you activate this from the customer tenant or from the CSP point of view?


Leave a Reply

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