Azure Lighthouse Not Working? Fix Delegation Errors Fast

Microsoft Fix Intermediate 15 min read Official Docs Grounded Updated April 20, 2026

What's in This Guide

Why This Happens
The Quick Fix
Step-by-Step Solution
Advanced Troubleshooting
Prevention & Best Practices
FAQ

Why Azure Lighthouse Delegation Keeps Breaking

Picture this: you've just spent three hours configuring an Azure Lighthouse onboarding deployment for a new managed services customer. You deploy the ARM template, everything says it succeeded, and then you open the My Customers page in the Azure portal , and nothing is there. No delegated subscriptions. No resource groups. Just a blank page staring back at you.

I've seen this exact scenario on dozens of engagements. And the maddening part? Azure gives you almost zero helpful feedback when Azure Lighthouse delegation fails. The error messages are generic at best. At worst, the deployment shows "Succeeded" and the delegation simply doesn't appear on either side , not in the managing tenant's portal, and not in the customer's Service Providers page either.

Azure Lighthouse works by establishing Azure delegated resource management, a mechanism that lets a managing tenant (usually a service provider or enterprise IT team) operate on resources inside a customer's tenant without ever needing to switch directories or log in with guest accounts. It's genuinely powerful. But because it spans tenant boundaries and relies on Azure Resource Manager templates, ARM parameter files, and role definition IDs that must be exactly correct, there are a lot of places for things to go sideways.

Here are the root causes I see most often when Azure Lighthouse setup problems surface:

Mismatched tenant IDs in the ARM parameter file, The managing tenant ID in the parameters file doesn't match the actual tenant running the deployment.
Invalid built-in role definition IDs, Role definition IDs are GUIDs that are globally consistent across Azure, but if you copy them wrong or reference a custom role that doesn't exist in the managing tenant, the whole deployment fails silently.
Deploying at the wrong scope, Subscription-level onboarding and resource group onboarding use different template files and different deployment commands. Using the wrong one is extremely common.
Marketplace offer parameter mismatches, If you published a managed services offer to Microsoft Marketplace and the parameter values in your template don't exactly match what was published, onboarding through the offer will break.
Cross-tenant propagation delays, Even after a successful deployment, role assignments across tenant boundaries can take 5–30 minutes to propagate. Many engineers assume it failed and start re-deploying, which creates conflicts.
National cloud boundary violations, Azure Lighthouse explicitly cannot delegate resources across a national cloud (like Azure Government) and the Azure public cloud. Attempting this fails with confusing errors.

Who hits these problems? Mostly managed service providers (MSPs) onboarding new customers, enterprise IT teams managing resources across multiple business unit tenants, and ISVs trying to automate customer resource management through Marketplace offers. If that's you, you're in the right place. Browse all Microsoft fix guides →

The Quick Fix, Try This First

Nine times out of ten, Azure Lighthouse delegation failures come back to one thing: a parameter file that has at least one value wrong. Before you do anything else, validate your parameters against your actual tenant.

Open Azure Cloud Shell or a local terminal with the Azure CLI installed and run this to confirm your managing tenant ID:

az account show --query tenantId --output tsv

Now open your subscription.parameters.json (or whichever parameter file you're using) and verify that the managedByTenantId value matches exactly what you just got back. One wrong character breaks everything.

Next, check every roleDefinitionId in your authorizations array. Built-in Azure role IDs are globally consistent GUIDs. Here are the ones MSPs use most:

# Contributor
b24988ac-6180-42a0-ab88-20f7382dd24c

# Reader
acdd72a7-3385-48ef-bd42-f606fba81ae7

# Owner (use sparingly, grants full control)
8e3af657-a8ff-443c-a75c-2fe8c4bcb635

# Monitoring Reader (common for observability-only access)
43d0d8ad-25c7-4714-9337-8ba259a9fe05

Once you've confirmed both values, redeploy using the correct template for your scope. For a full subscription:

az deployment sub create \
  --name "LighthouseOnboarding" \
  --location "eastus" \
  --template-file subscription.json \
  --parameters @subscription.parameters.json

After deployment completes with a genuine success status, wait at least 10 minutes before checking the My Customers page in the Azure portal. Cross-tenant role assignment propagation is not instant, give it time before concluding something is wrong.

Pro Tip

Run az deployment sub validate with the same template and parameters before actually deploying. It catches parameter mismatches and invalid role definition IDs without making any changes to the environment, a 30-second check that can save 30 minutes of debugging.

Confirm Your ARM Template Matches Your Onboarding Scope

This is the step most engineers skip. Azure Lighthouse uses different template files depending on whether you're delegating an entire subscription or one or more resource groups. Using the wrong file causes the deployment to either fail outright or succeed without actually creating the delegation.

From the Azure Lighthouse samples repository on GitHub, grab the correct template:

To delegate an entire subscription: use subscription.json and deploy at subscription scope.
To delegate a single resource group: use rg.json and deploy at resource group scope.
To delegate multiple resource groups in one shot: use multi-rg.json.

For subscription-level deployment via PowerShell:

New-AzDeployment `
  -Name "LighthouseOnboarding" `
  -Location "eastus" `
  -TemplateFile ".\subscription.json" `
  -TemplateParameterFile ".\subscription.parameters.json" `
  -Verbose

For resource group scope via PowerShell:

New-AzResourceGroupDeployment `
  -ResourceGroupName "my-customer-rg" `
  -TemplateFile ".\rg.json" `
  -TemplateParameterFile ".\rg.parameters.json" `
  -Verbose

Notice the difference: New-AzDeployment (subscription scope) versus New-AzResourceGroupDeployment (resource group scope). Wrong command for the wrong scope is an extremely common Azure Lighthouse setup problem. If this succeeds, you should see a new registration definition appear under Microsoft.ManagedServices in the customer subscription within a few minutes.

Validate the Delegation Exists on the Customer Side

After deployment, you need to verify the delegation registered correctly in the customer tenant, not just in your own portal view. This is where a lot of confusion happens. The managing tenant sees nothing until the customer's subscription has the assignment registered.

Ask the customer to open the Azure portal, go to All Services → General → Service Providers (or search "Service Providers" in the portal search bar). They should see your offer listed under Service provider offers with a status of "Delegated."

If you have access to the customer tenant yourself (via a guest account or during the initial setup phase), run this Azure CLI command from within the customer's tenant context to check for registered definitions:

az managedservices definition list --output table

And this to check actual assignment status:

az managedservices assignment list --output table

If the definition list shows your registration but the assignment list is empty, the delegation scope didn't apply correctly. This often means you deployed the template with subscription scope but targeted only a resource group, or vice versa. Delete the orphaned definition and redeploy with the correct scope template.

To delete a stray registration definition via PowerShell:

Get-AzManagedServicesDefinition | Where-Object {$_.Name -like "*LighthouseOnboarding*"} | `
  Remove-AzManagedServicesDefinition

If both lists show the correct entries, the delegation is valid. Move on to checking role propagation in Step 3.

Fix Azure Lighthouse Permission Denied Errors After Delegation

Your delegation registered correctly, great. Now you switch to the customer subscription context in the managing tenant portal and get hit with "Authorization failed" or "You do not have access to this resource." I know how frustrating this is, especially after spending an hour getting the delegation right.

Here's what's happening: Azure delegated resource management assigns roles to specific users or groups in the managing tenant. If the user trying to access the delegated resource isn't in the group or isn't the specific user listed in the authorizations block of the ARM template, they'll get denied, even though the delegation exists.

Open your original parameter file and look at the authorizations array. Each entry should have:

{
  "principalId": "the-object-id-of-user-or-group-in-managing-tenant",
  "roleDefinitionId": "the-role-guid",
  "principalIdDisplayName": "Your Team Name"
}

The principalId must be the object ID of the user, service principal, or security group, not the UPN or display name. Get the correct object ID from the managing tenant:

# For a user
az ad user show --id user@yourcompany.com --query id --output tsv

# For a group
az ad group show --group "Lighthouse-Admins" --query id --output tsv

If the object ID in the template doesn't match the actual user's object ID in your tenant, update the parameter file and redeploy. Also confirm the user is logging into the Azure portal from the correct managing tenant, not a guest session in the customer tenant, which won't get the delegated permissions.

Troubleshoot Azure Lighthouse "My Customers" Page Showing Nothing

The My Customers page (found in Azure portal under All Services → General → My Customers) is where you manage all your delegated customer subscriptions and resource groups. When it's blank despite a successful deployment, there are three likely causes.

First: wrong portal directory. Make sure you're logged into the Azure portal as your managing tenant, not the customer's tenant. Click your account name in the top right corner and check which directory is active. Switch if needed via Switch directory.

Second: portal caching. The My Customers page can cache stale data for up to 30 minutes after a delegation change. Force a refresh by appending ?feature.customPortalMenu=true to the portal URL or simply open the page in a new InPrivate/Incognito window after waiting 10–15 minutes.

Third: the deployment ran in the wrong tenant. This happens when engineers have multiple Azure subscriptions across tenants and the CLI is pointing at the wrong one. Verify which tenant your Azure CLI is authenticated against:

az account show --query "{tenant:tenantId, subscription:name}" --output table

If the tenant ID doesn't match your managing tenant, switch with:

az login --tenant your-managing-tenant-id
az account set --subscription your-subscription-id

Then redeploy. Once you confirm the template deployed from the managing tenant against the customer's subscription, the My Customers page should populate within 10–30 minutes. If it still doesn't show, proceed to the Advanced Troubleshooting section below.

Fix Azure Lighthouse Marketplace Offer Onboarding Failures

If you're onboarding customers through a managed services offer published to Microsoft Marketplace rather than direct ARM template deployment, the failure mode is different. The most common error is a parameter mismatch between what your Marketplace offer advertises and what the onboarding template expects.

When you publish a managed services offer through Partner Center, the system generates specific values for the offer, plan IDs, publisher IDs, and authorization configurations. These must match exactly in the marketplace-delegated-resource-management.json template you use for onboarding. Even a single field difference causes silent onboarding failures.

Check the Marketplace offer onboarding template's parameter file and verify these fields match your Partner Center offer exactly:

{
  "mspOfferName": { "value": "Exactly as published in Partner Center" },
  "mspOfferDescription": { "value": "Exactly as published" },
  "managedByTenantId": { "value": "your-managing-tenant-id" },
  "authorizations": { "value": [ ... ] }
}

After a customer accepts your Marketplace offer, they don't automatically get fully delegated, they need to complete the onboarding step. Direct them to Service Providers → Service provider offers → [Your Offer] → Delegate in their Azure portal. They'll choose which subscriptions or resource groups to delegate and confirm permissions. Without this step, the offer acceptance alone doesn't create the delegation.

You can also optionally deploy the marketplace onboarding template yourself using the ARM template approach described in Step 1, which automates the delegation without requiring manual customer action in the portal. This is especially useful for large-scale, automated MSP onboarding workflows. If this succeeds, you should see the customer appear in My Customers within 15 minutes.

Advanced Troubleshooting for Azure Lighthouse

Diagnosing Cross-Tenant Management Failures via Activity Log

One of Azure Lighthouse's genuinely useful features is that actions taken by the managing tenant appear in the customer's Activity Log, you can see exactly what was done and by whom. When cross-tenant management stops working, the Activity Log is your first stop for diagnosis. In the customer's subscription, go to Monitor → Activity Log and filter by Resource Provider: Microsoft.ManagedServices. Look for any failed operations in the last 24 hours.

Failed registration assignment operations typically show one of these status codes:

AuthorizationFailed, The user attempting the action doesn't have the role assigned in the delegation.
BadRequest, Usually a malformed ARM template or parameter mismatch.
Conflict, A registration definition with the same name already exists. You need to update the existing definition rather than create a new one.

Deploying Azure Policy Across Azure Lighthouse Delegated Subscriptions

Using Azure Policy with subscriptions onboarded to Azure Lighthouse is a common enterprise scenario, and it requires the managing tenant to have appropriate permissions at the subscription scope, not just resource group scope. If you're seeing policy assignments fail across delegated subscriptions, check that the authorization block in your delegation template includes at least the Resource Policy Contributor role (36243c78-bf99-498c-9df9-86d9f8d28608) for the service principal or group running policy operations.

For automated policy remediation across delegated subscriptions, you also need a managed identity in the customer's subscription. Deploy this via an ARM template extension or use the policy-add-or-replace-tag sample from the Azure Lighthouse samples repo as a reference pattern.

Just-in-Time Role Activation Not Working

Azure Lighthouse supports just-in-time (JIT) eligible authorizations, where users must explicitly activate a role assignment before accessing customer resources, rather than having standing access. If JIT activation is failing, check whether your ARM template is using the eligible-authorizations block correctly and whether Azure AD Privileged Identity Management (PIM) is enabled in the managing tenant. JIT roles in Lighthouse require PIM. Also confirm that the user is activating the role from My Customers → [Customer] → Eligible Authorizations → Activate, not trying to directly access the resource, direct access before activation will always fail.

Cannot Delegate Across National Clouds

Azure Lighthouse is a nonregional service and works across Azure regions. However, you cannot create a delegation that spans a national cloud (Azure Government, Azure China 21Vianet) and the Azure public cloud, or between two different national clouds. If your organization spans both Azure public and Azure Government, you need separate Azure Lighthouse onboarding configurations for each cloud environment. There is no workaround for this, it's a hard architectural boundary in the platform.

When to Call Microsoft Support

If you've validated your ARM template, confirmed tenant IDs, checked role definition IDs, waited 30+ minutes for propagation, and the delegation still isn't showing in My Customers or Service Providers, it's time to escalate. Open a support request at Microsoft Support and select Lighthouse under the Monitoring & Management service category. Include your deployment name, the subscription ID you targeted, and the timestamp of your last deployment attempt. Microsoft's backend teams can inspect delegation state that isn't visible in the portal.

Prevention & Best Practices for Azure Lighthouse

Most Azure Lighthouse delegation errors are entirely preventable. Once you've fixed the immediate issue, here's how to set things up so you're not back here in two weeks.

Always validate before deploying. Make it a habit to run az deployment sub validate or Test-AzDeployment before any live deployment. This catches malformed parameters, invalid GUIDs, and missing role definitions without touching any real resources. Build this into your onboarding scripts as a mandatory pre-flight check.

Store your templates in source control with customer-specific parameter files. Each customer should have their own parameter file in a git repository. Inline customer IDs, tenant IDs, and authorization blocks should never be hand-edited on the fly. Template drift is responsible for a huge percentage of Azure Lighthouse configuration errors in MSP environments.

Use security groups instead of individual user principal IDs in authorizations. If you assign delegation permissions to individual user object IDs and that employee leaves the company, you need to redeploy the ARM template to add the new person. Using a security group means you manage membership in Azure AD and the Lighthouse delegation stays stable. This is the official recommended security practice from Microsoft's Azure Lighthouse documentation.

Apply the principle of least privilege to every delegation. Don't give Contributor access when Reader is enough for the task. Don't give Owner access when Contributor does the job. The Azure Lighthouse model gives customers visibility into exactly what permissions they've granted, and customers who see overly broad permissions will revoke access. Scoped permissions protect your business relationship.

Monitor managing tenant activity from the customer side. Customers can review all actions taken on their resources via Activity Log and the Service Providers page. As a service provider, you should periodically audit what's appearing in those logs to make sure it matches your expected activity, it builds trust and catches accidental privilege misuse early.

Quick Wins

Pin the My Customers page to your Azure portal dashboard for instant visibility into delegation health.
Tag every Lighthouse registration definition with a customer identifier and onboarding date, makes bulk management and cleanup much easier later.
Use the cross-subscription-deployment sample template when onboarding multiple subscriptions for the same customer to avoid doing it one by one.
Document each customer's delegated scope, authorized groups, and role assignments in a shared runbook, when something breaks at 2am, you'll thank yourself for having it.

Frequently Asked Questions

What is Azure Lighthouse and who actually needs it?

Azure Lighthouse is Microsoft's multitenant management platform, it lets a managing tenant (your company) access and manage resources inside a customer's Azure tenant without needing guest accounts or switching directories. It's designed for managed service providers, enterprise IT organizations managing multiple business unit tenants, and ISVs who need to operate customer environments at scale. If you're managing more than two Azure tenants and doing it by logging in with guest accounts, Azure Lighthouse will make your life significantly easier. There's no extra cost, any Azure customer or partner can use it.

How long does it take for Azure Lighthouse delegation to show up after deployment?

After a successful ARM template deployment, expect cross-tenant role assignments to propagate within 5 to 30 minutes. The deployment itself completes in seconds, but the delegation becoming visible in the managing tenant's My Customers page and the customer's Service Providers page takes longer because Azure has to replicate the assignment across tenant boundaries. Don't assume the deployment failed just because nothing appears immediately. Wait at least 15–20 minutes before troubleshooting a "missing delegation" issue.

Can a customer revoke Azure Lighthouse access at any time?

Yes, and this is by design. Customers retain full control over the delegations they've granted. They can go to Service Providers → Service provider offers → [Offer Name] → Delete in the Azure portal to remove access at any time. They can also remove individual resource group delegations without removing the full subscription delegation. As a service provider, you should never rely on continuous access being guaranteed, if your customer removes access unexpectedly, check with them directly before attempting to re-onboard.

Can I use Azure Lighthouse with Azure Government or national clouds?

Azure Lighthouse works within the Azure public cloud and within national clouds separately, but you cannot create a delegation that crosses from Azure public cloud into Azure Government (or any other national cloud), or between two different national clouds. This is a hard platform boundary with no workaround. If your organization has resources in both Azure public and Azure Government, you'll need to set up completely separate Azure Lighthouse configurations for each environment, with separate managing tenant identities for each cloud.

Why is my Azure Lighthouse ARM template deployment showing "Succeeded" but no delegation appears?

This is the most common Azure Lighthouse setup problem I see. A "Succeeded" deployment status means the ARM template processed without syntax errors, it doesn't mean the delegation was actually created correctly. The most frequent culprit is deploying a subscription-scope template (subscription.json) using a resource group deployment command, or vice versa. The second most common cause is that the managedByTenantId in the parameter file doesn't match the tenant where you ran the deployment. Check both of these first before anything else. Use az managedservices assignment list run from within the customer's subscription to verify whether an actual assignment was created.

How do I manage multiple customer subscriptions in Azure Lighthouse without doing them one at a time?

The Azure Lighthouse samples repository on GitHub includes a cross-subscription-deployment template specifically for this scenario, it lets you deploy ARM templates across multiple subscriptions in a single operation. For onboarding all subscriptions within a management group, the recommended approach is to deploy an Azure Policy that automatically onboards each subscription as it appears in the group. This avoids running individual deployments per subscription and is especially useful for large MSP environments where customers regularly add new subscriptions. Note that you can't onboard an entire management group in one direct deployment, the policy approach is the workaround Microsoft officially documents for this.

Related Microsoft Fix Guides

Sai Kiran Pandrala

Our team includes certified Microsoft engineers, Azure architects, and system administrators with 10+ years of enterprise IT experience. Every guide is written from hands-on troubleshooting, not guesswork. We test every fix before publishing.