Azure Lighthouse: A comprehensive guide for MSPs

Introduction

As someone who’s gone through the spawning and evolution of an MSP (Managed Service Provider) looking to enhance the way they control, manage and delegate customer resources in Azure, I thought I’d collate all my thoughts, experiences, lessons learnt and knowledge dump for Azure Lighthouse with a comprehensive guide for MSPs.

Whether you’re a new MSP, small or large, who may already use Azure Lighthouse, maybe we can learn from each other and in turn help steer Microsoft to enhance this tooling through our experiences and feedback – but also shout about how great it is.

In this post, I’ll deep dive Azure Lighthouse from onboarding methods, best practices, lessons learnt and everything else in between.

What is Azure Lighthouse?

Gone are the days of your support and cloud teams relying on a named accounts in customer tenants as the only and primary way to support Azure resources for your clients. With Azure Lighthouse this is no longer necessary for the majority of business as usual support tasks.

Not to be confused with Microsoft 365 Lighthouse (or GDAP) which is a similar feature but for M365 instead.

How can Azure Lighthouse benefit your organisation?

• FREE to use
• Only requires Entra P2 licenses for PIM by the managing tenant – customers do not need this license requirement to wrap Azure Lighthouse with PIM
• Centralised management and governance
• Greater security and compliance (full logging/audit visibility)
• Reduces management complexity
• Value add to customers as a selling point of the above benefits
• Additional brand presence if you use the Azure Marketplace
• The customer is always in control of Azure Lighthouse delegation

Azure Lighthouse onboarding methods

Next, we’ll look at the ways to onboard customers onto your Azure Lighthouse offering and how each method has it’s own benefits and drawbacks.

Azure Marketplace offering

One of the most seamless ways to onboard customers is via the Azure Marketplace. This is an offering that customers can locate in the Azure Portal and automatically enrol and delegate to your Azure Lighthouse offering.

There are some requirements that must be met go do down this road which can be found here.

You can create your Azure Lighthouse offering in the Microsoft Partner Portal via Partner Center (microsoft.com), under ‘Managed service’ offer. Here, you can specify the offer name, search result summary, description, product information and everything else in between.

Once ready you can submit for publishing. This will go through various approval stages, with a mix of automatic and manual phases from Microsoft’s side. During this process you’ll be able to check your offering via the Azure Portal through Private Preview, before you ‘signoff’ and publish for go-live in the marketplace.

Private Preview audience

Furthermore, a key marketplace feature is being able to have a preview audience to test and verify updates and changes privately before you go-live on a test subscription.

This is now under the ‘Private offer management’ in the Azure Marketplace. You’ll be able to enrol to your private Azure Lighthouse Preview to test changes ahead of go-live.

Partner Portal Access & Roles

If you have an existing Azure Lighthouse offering in the marketplace, or are looking to create one you’ll need to get the ‘Developer’ role assigned to your MPN account roles to view the ‘marketplace offers’ area in Microsoft Partner portal.

Technical manifest

Next, we’ll go over the technical configuration for the offering. Within your offering, the ‘plan overview’ can be amended for the Azure Lighthouse technical configuration.

This is how you’re able to iterate and update the offering. From this page you’re able specify the PIM (Privileged Identity Management) authorisations, display names, the Entra object ID for the security groups you want to include in the offering, their role & the access type.

Enrolment

With a marketplace offering live customers can begin onboarding through the Azure Portal. To do this, they can simply search for your offering name in the search bar of the Azure Portal to begin.

The subscription selected is not the delegation – only the one associated to the service provider offering. By this, it means the ARM deployment, as such the region is somewhat irrelevant if you don’t change it – as it’s just where the deployment is running from only (in my experience anyway).

Additionally, I notice this triggers a Microsoft.ManagedService provider in this particular subscription as well.

The last review page will list all the authorisations specified from the technical manifest seen earlier in the blog and the corresponding Entra Object IDs and roles being offered for delegation.

Delegation

• Access Requirements: Azure subscription owner

After the offering has been enrolled the customer will need to delegate the resources it wants you (the managing tenant) to have access to. This can be as granular as a singular resource group, multiple resource groups and similarly with Azure subscription(s) too.

When delegating subscriptions customers must go and register the Microsoft.ManagedService provider in each subscription they are going to delegate excluding the one they ran the deployment association from. This can be done via PowerShell, Portal, etc so could be scripted

Without this, in my experience, it will fail to register this when you go to delegate automatically.

Updates

Once published a new or existing offering, you have to update the service provider offer in the Azure Portal here.

When an update to the marketplace offering is available, customers will see a small ‘update’ icon in which they can enrol the new technical manifest to receive the updates (which may be new roles, access types, etc.).

If you are fortunate enough to have GDAP setup (granular delegated admin privileges) for the customers you may be able to update the manifest on their behalf (with their consent and awareness, of course). Otherwise the customer must run the update process to get the new offering update.

With this in mind, it’s best to limit your updates to keep things consistent across the board.

Pros & cons

To conclude the marketplace offering method I’ll detail the pros and cons of this method. Note that the cons aren’t necessarily a reason to not use this – I think organisations should have a marketplace offering published but there are some considerations.

Pros

• Brand presence on the Azure Marketplace
• Easy to onboard due to Azure Portal ClickOps
• Central update mechanism in the Microsoft Partner Portal
• Good for small to medium MSPs who want less management overhead maintaining ARM / Bicep Template(s)

Cons

• No customisation per customer – not geared for Enterprise use cases
• Updating the technical configuration is not a very good experience in the Partner Portal
• MS Partner Portal can be a bit convoluted to navigate, and menus/pages change occasionally making it a pain to revisit months later

ARM / Bicep Template onboarding

Alternatively onboarding purely via ARM / Bicep templates is viable and recommended, as well. I’ll try not to regurgitate what the Microsoft docs have on this as they are pretty good and instead focus on examples and my experiences.

Essentially you have two ways to perform the creation of the templates:

• Via the ‘My Customers’ page in the Azure Portal which gives us a GUI representation of the ARM template for visual creation which is here. This can be good for those still early in their IaC adoption or want to visually view the authorisations.
• Or manually creating the templates yourself in your favourite code editor like any other ARM or Bicep template.

I would strongly recommend checking out the Azure-Lighthouse-samples GitHub project from Microsoft themselves: Azure/Azure-Lighthouse-samples: Provide samples for understanding managed service solutions (github.com) to get a feel and flavour for the different scenarios. Their are already many templated examples to take and customise to your organisations specific needs.

Params

In the parameters file you can specify the Entra security group principleId, role definition(s) that these security groups are associated with and their display name.

All authorisations in the normal "authorizations": { block are permanent role authorisations. Be careful about which roles you want to be here.

Some are necessary, for Partner Earned Credits to be acquired by your managing tenant you’ll need the least privileged role available which is the Support Request contributor.

All authorisations under "eligibleAuthorizations": { will be PIM-enabled delegations and those groups will need to use PIM to enable the roles.

My example shows some of the roles have time limits applied by default such as 1 or 2 hours. This is good practice from a security point of view so you don’t have accounts lingering in roles after work has been completed or for longer than necessary.

Example Lighthouse parameter JSON file uploaded to my GitHub Gist:

Deployment

Requirements:

• Azure subscription owner
• Registered Microsoft.ManagedService provider in each Azure subscription that will be delegated

There are multiple ways to deploy the templates. The customer must do this on your behalf so whoever runs the template(s) will need the prerequisite permissions to perform the deployment.

• Azure PowerShell
• Azure CLI
• Direct from the Service providers Azure Portal page here under the add offer button

More information on these can be found on the Microsoft docs.

If you’ve gone down the template route, your organisation may want to consider expanding on the ARM/Bicep template to automate the resource provider registration and other values like subscription value, id, etc.

Security benefit

One of the key benefits for using a template approach over the marketplace offering method is for some additional security. If you are using automation, CI/CD, other DevOps style approaches to customers you’ll want to secure the identities that run in those environments.

Using the ARM/Bicep templated approach, you’ll be able to include a Service Principle or Workload Identity in a specific Entra security group that is just for that customer. This way you are declaring individual service identity context on a per customer basis.

If you were to do the following in the Azure Marketplace offering you’d have to use the same identity to perform these actions for ALL customers which is not ideal when you’re designing with zero-trust in mind. This is because the marketplace manifest is a ‘catch-all’ config rather than a per-customer-basis deployment.

However, this approach does come with drawbacks such as complexity and management overhead.

Pros and cons

Pros

• Security enhancement: ability to define and declare service principals on a per customer basis
• Flexibility: to adjust the standardised template to suit a particular customer use case
• Ease: to adjust templates compared to the Partner Portal configuration
• Enterprise use cases

Cons

• No central update mechanism like the Azure Marketplace offering (that I’m aware of?)
• Manual updates to customers for changes to the offering
• Can be overwhelming to manage for small MSPs due to lack of resource etc

Azure Lighthouse & PAL (Partner Admin Link)

Traditionally, being recognised for Partner Admin Link for revenue would entail a consultant manually entering the MPN ID on the customers tenant to get recognised for the revenue. With Azure Lighthouse you can combine PAL to ensure this is no longer needed to be done manually on a per customer basis and the process can be automated.

Here’s a list of the PEC RBAC eligible roles that you’ll need to use in our Lighthouse manifest. Using one of these roles (I strongly recommend Support Request Contributor), you can assign to the Entra security group, of which you’ll have a Service Principal with a linked MPN Id associated to it included in this group.

Here’s a quick how-to on that using Azure CLI:

az login
az ad sp create-for-rbac --display-name "SPN for PAL & PEC eligibility in Az Lighthouse"

// Now login as the SPN context to associate with your MPN ID
az login --service-principal --username servicePrincipal --password secret --tenant tenantId
az account show
az managementpartner create --partner-id YOURMPNID
az managementpartner show

Lastly, add the SPN into your Entra group that is assigned the Support Request Contributor role (must be an perm/active assignment or it will not work). This will make sure your organisation benefits from this automatic PAL association through this SPN context, eliminating the older manual approach.

In addition to this, it’s good to get your admins to link the MPN ID to their accounts too so you’re not solely reliant on the service principal.

I really recommend reading through the Azure Citadel section on Partner / Azure Lighthouse PAL link to gain more insight: Combining Lighthouse and PAL • Azure Citadel if you’re after a bit more information beyond the detail I’ve gone into above.

Azure Lighthouse – Best practices

• A MUST: Setup PIM-enabled delegations for Entra groups with Azure Lighthouse that have business agreed default PIM elevation time limits, MFA requirements and approvals
• Use least privilege roles. Define what requirements the business and support teams have and define these roles for your Azure Lighthouse offering to reduce changes down the line
• Setup an permanent role for the Support Request Contributor (least privileged PEC eligible role) to ensure your organisation is eligible for PEC (Partner Earned Credit) for Microsoft recognition for the revenue
• Setup Service Principal Name (SPN) that has associated MPN ID of your managing tenant that sits in an active group with the least privileged role for Partner Earned Credit (see PAL section above for more info)
• Make sure you have the Managed Services Registration Delete role defined so you (the managing tenant) are not reliant on the customer to action the removal of the offering to keep things in order
• Use User Access Administrator role with delegated contributor privileges to mimic owner rights via Managed Identities for remediation tasks via Azure Policy and others
• Assign roles to Microsoft Entra security groups using the least privileged roles necessary (e.g. VM Contributor or Backup operator) vs blanket Contributor because it’s ‘easy’ (remember custom roles are not supported)

Gotchas and limitations

• Contributor is the highest RBAC level – Owner is not available!
• Only supports Azure Subscriptions and Resource Groups – no management groups
• DataAction permissions are currently still not supported – that means no data plane actions like Storage Account or Key Vault (ways around this, using the concept I’ve linked for the Azure Policy at scale, and checkout the note below for workarounds)
• Microsoft.Authorization/* actions are not supported
• Azure IAM blade will only show your perspective of the RBAC from your Entra tenant
• Azure Lighthouse puts the customer in control and they can remove delegation when they want
• To be eligible for Partner Earned Credit you must use an ACTIVE role
• MPN developer role to view marketplace offerings
• Entra security groups only (so no M365 groups!)
• Must register the Microsoft.ManagedServices resource provider for each Azure subscription manually to avoid failures
• Custom roles not supported
• No central update button for templated offerings vs marketplace
• GDAP can help bridge the gap between those who need Owner level roles to act on behalf of the customer without a named account
• Don’t amend the mspOfferName in the ARM template manifest, otherwise it will treat you as a new provider instead of updating existing offerings

There are some potential dataAction workarounds with some roles, as noted on the Microsoft docs:

Removing delegations

Providing you have an Azure Lighthouse offering which includes the ‘Managed Services Registration Delete’ role, as the managing tenant you have the ability to remove the customer from your side. This can be useful if the customer lacks the know-how, for example. It enables the managing tenant to remove this without the customer doing any actions on their part.

Azure Portal:

Navigate to My Customers > Delegations and you should see a ‘trash’ icon at the far right of each subscription of which you are elevated for the managed service registration delete role.

Azure CLI:

az login
az managedservices assignment delete --assignment "subId"
az managedservices assignment list

How do I ‘PIM’ up for different delegations?

The PIM Portal experience can be a bit clunky if you have a lot of customers – finding roles for a specific customer doesn’t feel very intuitive, so here’s my tip:

In the Azure Portal search for PIM, under Manage click ‘Azure Resources’:

Once within the Azure resources view you’re able to scope down by subscription/resource group for the particular customer and hitting the ‘manage resources’ button. This will take you to the PIM view for that customers subscription, allowing you to navigate to the ‘My roles’ and view only that customers eligible and active assignments.

Azure Lighthouse with CI/CD

Since you’ve onboarded customers Azure subscriptions to Azure Lighthouse you’re now able to see all the delegated subscriptions from the managing tenant. This means you can utilise DevOps pipelines to automate and deploy from the managing tenant (Infra-as-Code (Bicep/Terraform, Azure Policy as Code, etc).

If deploying resources using IaC templates (or other automation methods) you’ll be able to bake in a customer specific Service Principal to our Azure Lighthouse ARM template. I would recommend:

1. Create SPN per customer and add a variable to your Azure Lighthouse template so you can change this on a per customer deployment basis
2. Have a process ready to deal with SPN secret rotation / expiration(s)
3. When creating your pipelines make sure the SPN is specified as the authenticating mechanism in the YAML azureSubscription: ($yourSpnServiceConnectionName) for example

I would also further recommend if you are exploring this route to setup Azure DevOps/GitHub “environments” so you can set approvers, restrictions and have an audit log of deployments on a per customer basis for the pipeline runs.

Azure Policy at scale with Lighthouse

As above, with the delegations to our managing tenant you’re able to use Azure Policy remediation at scale.

You don’t have the owner role available but using a combination of User Access Administrator with delegated roles like Contributor and Log Analytics contributor will allow us to utilise a Managed Identity that can act with the right roles to perform Azure Policy remediation at scale.

I’ve previously written a blog post on how to do this which you can read here.

Azure Monitor & Observability at scale with Lighthouse

Furthermore, with all the subscriptions delegated for customers you’re able to get a centralised overview for Azure Monitor alerts. This is where as an MSP things can really start to level-up.

Utilising Azure Monitor workbooks you’re able to give ourselves powerful insights to Azure Monitor log and metric data that can be filtered per customer or for all customers.

Here’s the GitHub repository that has a bunch of out the box workbooks for use to install to your managing tenant (or you can go custom entirely and build your own to suit your needs).

microsoft/Application-Insights-Workbooks: Templates for Azure Monitor Workbooks (github.com)

With this in mind, you’re able to spin up a ton of workbooks and dashboards in your managing tenant that your teams can use to help oversee the delegated estate and proactively monitor.

Further to this, all other management tasks become available in the Azure Portal for greater observability such as Azure Update Manager and Azure Backup Center as you can filter on all delegated subscriptions.

Lastly, I would recommend checking out a few articles below on this subject which have fantastic coverage on the subject. In summary, from my point of view and experience:

1. Create log analytics workspaces per customer to pipe alerts into Azure Monitor (avoid using one central ALA for all customers in the managing tenant as this has cost complexity, data governance and security concerns so I would advise against).
2. Create Action groups per customer that hooks into your ITSM tooling (such as ServiceNow) via secure webhook
3. Setup Azure Diagnostics to pipe to the customer ALA and create your alerts based on these (check out Azure Monitor Baseline Alerts for a good starting point if you’re starting out)
4. Setup relevant alerts via Azure Policy initiatives (DeployifNotExists) or building out your KQL queries to setup alerts to pipe to Azure Monitor

After this is setup and aligned, Azure Monitor with Azure Lighthouse delegation means you will have a really fantastic overview of all customers from one singular pane of glass.

Monitor delegated resources at scale – Azure Lighthouse | Microsoft Learn

MSP: The well-tempered Azure tenant – Part 5 (azurealan.ie)

Azure Cost Management Overview for Customers

Granular cost overview is also possible since delegated subscriptions are visible under the root billing account for your Microsoft Partner account. By navigating to ‘Cost Management + Billing’ > Cost management > Cost analysis you can scope down using filters to review customer costs (or multiple at the same time):

Conclusion and closing thoughts

Phew, if you made it this far then I’m surprised! But thank you if you did, and I really do hope it was a useful read and insightful.

To conclude, for me at least, Azure Lighthouse is simply a must for any MSP to leverage. Not only does it build credibility with your customers as you’ll be harnessing PIM to access their environment but it also has full audit logging capabilities whilst leaving the customer in control at all times. Additionally worth pointing out Lighthouse isn’t exclusively just for MSPs though, anyone can take advantage of it for delegated access – however this guide was specifically geared from an MSP point of view.

If you’re an MSP using Azure Lighthouse or looking to adopt it I strongly recommend getting all relevant stakeholders together and onboard to get behind using Azure Lighthouse, what roles and groups you want to setup and your PIM thresholds/settings/approvals/groups/memberships/access reviews and more.