Azure Lighthouse is a service that enables cross-tenant management in Azure, allowing one Azure AD tenant to manage resources in other Azure AD tenants in a secure, controlled manner. It’s especially designed for scenarios like service providers managing multiple customer environments, or large enterprises that have multiple Azure tenants and want a centralized operations team. Using Lighthouse, you can see and manage subscriptions from different tenants in one place – essentially achieving a “single pane of glass” for multi-tenant Azure management.
Let’s break down the mechanisms and how they work:
- Delegated Resource Management: Azure Lighthouse works by establishing a trust where the owner (customer) tenant delegates access to specific resources (subscriptions or resource groups) to a managing tenant. Practically, the customer creates a delegation (via Azure Portal, PowerShell, or ARM template) specifying the Azure AD tenant ID of the service provider (or central IT) and which roles to grant. For example, customer X can delegate subscription “Prod” to the service provider’s tenant with the role “Contributor”. Under the hood, this creates an assignment of a Guest principal from provider tenant into customer tenant roles. Now, in the provider’s tenant, their users can access customer resources without switching accounts.
- Unified Portal and Tools: After delegation, the service provider (or central IT admin) can go to Azure Portal and under their context see a section “My customers”. They can list delegated subscriptions from various customers and manage them as if they were their own – but with the exact permissions granted. So, an MSP support engineer could see CustomerA-Prod, CustomerB-Test, etc., in their subscription filter. They don’t have to log in separately to each customer’s Azure – this is a huge efficiency gain. Scripting and automation also benefit: Azure CLI/PowerShell/ARM APIs from the provider tenant can target customer subscriptions by specifying the subscription ID as normal (the cross-tenant link is handled behind the scenes by Lighthouse). Essentially, Lighthouse extends Azure RBAC across tenants. Each action by the provider is still logged in the customer’s activity logs (with information that it was performed via delegated access), ensuring transparency.
- Secure by Design: One might wonder: giving one tenant access to another’s resources – is that safe? Azure Lighthouse is built with strict consent and least-privilege principles. The customer explicitly controls what scope and roles are delegated, and can revoke at any time. The service provider users do not exist in the customer’s Azure AD (no need to invite them as guest users individually anymore), which is beneficial because it reduces identity management overhead and the risk of leftover accounts. Instead, the provider uses their own Azure AD credentials, which Azure Resource Manager recognizes (via Lighthouse’s assignments) as having rights on the customer’s resources. Also, the provider can’t see anything not delegated – for instance, if only Resource Group A is delegated, they won’t even know Resource Group B exists.
- Scope and Granularity: Delegation can be at subscription level or resource group level. Many MSPs prefer resource group level to isolate things like only certain workloads (maybe only networking resources, or only a specific app) to their view. This flexible mechanism allows tailoring access. For central IT controlling multiple subsidiaries (each maybe in their own tenant), they might just delegate whole subscriptions because it’s all within one company. Azure Lighthouse essentially uses Azure AD’s B2B federation under the hood combined with ARM RBAC.
- Integration with Other Services: Azure Lighthouse’s cross-tenant mechanism lights up capabilities in Azure services. For example, Azure Sentinel (a cloud SIEM) supports Lighthouse so an MSSP (Managed Security Service Provider) can view and manage incidents from many customer Sentinel workspaces in their single Sentinel instance. Or Azure Arc – a service provider could manage on-prem servers across customers through one portal, combined with Lighthouse and Azure Arc. Azure Policy can be executed at scale across customer environments – e.g., a provider can create a policy assignment in their tenant that applies to multiple customer subscriptions (with appropriate permissions). Similarly, updates or deployments via ARM templates can be multi-tenant. Essentially, anything you can do in a subscription via ARM/RBAC can, with Lighthouse, be done across tenants that have given you access.
- Managed Service Offers: Azure Lighthouse can be onboarded manually via scripts or portal, but there’s also a marketplace integration: A service provider can publish a “Managed Service offer”. When a customer accepts that offer (private or public), Azure automatically sets up the delegations (it’s basically an ARM template under the hood). This automates onboarding potentially dozens of customers consistently. The MSP can even include automation in the offer that deploys monitoring or security solutions into the customer environment upon onboarding (with customer consent, of course). This is powerful for scaling an MSP business.
- Enterprise Multi-Tenant use-case: As noted, some large enterprises have multiple tenants – maybe due to mergers, or to separate IT environments for compliance, or separate Azure environments for different business units. Azure Lighthouse can let a central team operate across those as if it’s one. For example, Contoso Corp. has a global IT tenant and regional affiliates each with their own Azure AD – the global team can manage them all via Lighthouse, rather than maintaining separate admin accounts in each. Similarly, if corporate security wants read-only access to all subscriptions in a subsidiary tenant for auditing, the subsidiary can delegate Reader access to them instead of adding external accounts.
- Transparency and Control: On the customer side, there’s a “Service providers” blade where they see which delegations exist and can remove or add as needed. They also can see the actions that the provider performed in their logs, as mentioned. This fosters trust. It’s more transparent and secure than giving an MSP co-admin credentials or inviting them as guest and forgetting to remove – with Lighthouse, everything is explicit and scoped. Also, if the MSP relationship ends, it’s one step to remove all their access (just remove delegation assignments), rather than hunting down accounts and RBAC roles one by one.
- Multi-tenant Azure Resource Graph & Monitoring: A concrete scenario: imagine a provider wants to ensure all their customers have backups enabled on VMs. With Lighthouse, they can run a single Resource Graph query across all delegated subscriptions to find VMs without backups. Without Lighthouse, they’d have to iterate per tenant with separate contexts/auth, which is far more complex. Or they might want to apply a log analytics query across all customer logs – with Lighthouse and something like Azure Monitor Workbooks supporting cross-tenant queries, it’s possible to consolidate that data. Azure Defender (security center) also uses Lighthouse so an MSSP can see all security recommendations across customers in one unified dashboard (with each customer’s consent via delegation). These are advanced management scenarios enabled by this cross-tenant mechanism.
In summary, Azure Lighthouse provides enterprise-grade cross-tenant management by allowing delegated access at scale with full fidelity of Azure’s management capabilities. The key mechanisms are: – Delegating access using Azure AD B2B behind the scenes. – Centralizing view in portal and APIs (the managing tenant can treat customer resources almost like their own). – Maintaining isolation and security (no mingling of data, strict role enforcement). – Ease of onboarding (via ARM templates or Marketplace offers). It fundamentally makes managing many Azure directories feasible and efficient.
For a visual mental model: think of Azure Lighthouse as creating a “bridge” between tenants’ Azure Resource Manager instances. This bridge is built only where invited, and carries the specific role permissions across. The result – as a service provider admin, you log into your Azure and see multiple tenants’ stuff, but you’re actually only carrying your single identity and switching context within that login session logically. This cross-tenant management model is unique to Azure; AWS and GCP don’t natively have an equivalent that spans distinct organizations to this extent. It’s a big selling point for Azure in the MSP space and any multi-tenant scenario.
By adopting Azure Lighthouse, organizations can vastly simplify multi-tenant operations, reduce time spent switching accounts, and manage large-scale environments more uniformly. It supports the mechanisms needed (like least privilege cross-tenant access, aggregated governance) for enterprise and service provider scenarios that previously required clunky solutions. Essentially, Lighthouse is Azure’s built-in solution for multi-tenant management and fits nicely into the narrative of cloud center of excellence managing multiple subdivisions or an MSP managing multiple customer clouds.