Azure Lighthouse for Multi-Tenant Management

Azure Lighthouse is a service that enables cross-tenant management by allowing users in one Azure AD tenant (the 'managing tenant') to perform management operations on subscriptions or resource groups in another tenant (the 'customer tenant'), without needing a separate account in the customer tenant. It was designed primarily for managed service providers (MSPs) who manage multiple customer environments, but it is also used by enterprises with multiple Azure AD tenants (e.g., after acquisitions) to centralize management.

The core problem Azure Lighthouse solves is the inefficiency and security risk of creating and maintaining guest user accounts in every customer tenant. Before Lighthouse, an MSP had to either:

Azure Lighthouse eliminates the need for accounts in the customer tenant. Instead, it uses a delegation model where the customer tenant authorizes the managing tenant's users (via groups) to access specific subscriptions or resource groups, with specific Azure RBAC roles. The managing users authenticate in their own tenant, and Azure AD issues a token that is valid in the customer tenant based on the delegation.

The mechanism relies on Azure Resource Manager (ARM) and Azure AD authentication. Here is the step-by-step flow: 1. Customer Onboarding: The customer tenant administrator creates an Azure Lighthouse offer (using ARM templates) that defines:

- The managing tenant's tenant ID. - One or more authorizations, each specifying a principal (user, group, or service principal) from the managing tenant and an Azure RBAC role (e.g., Contributor, Reader). - The scope: one or more subscriptions or resource groups. 2. Delegation: The customer deploys the ARM template, which creates a special resource type called Microsoft.ManagedServices/registrationDefinitions in the customer tenant. This resource records the delegation. 3. Authentication: When a user from the managing tenant attempts to access the customer's resource (via Azure portal, CLI, or API), Azure AD authenticates the user in the managing tenant. The user's token includes the managing tenant ID. 4. Authorization Check: The customer's Azure Resource Manager receives the request. It checks if there is a registration definition that:

- Matches the managing tenant ID. - Includes the user's principal ID (or a group the user belongs to) in its authorizations. - Covers the target scope. 5. Token Issuance: If authorized, ARM issues a delegated token (a JWT) that allows the user to perform operations within the delegated scope, with permissions determined by the assigned RBAC role. 6. Management Operations: The user can now manage resources in the customer tenant using their own credentials, as if they were a native user with those roles. All actions are logged in the customer's Azure Activity Log.

- Managing Tenant: The Azure AD tenant that contains the users performing management. This tenant must be specified during onboarding. - Customer Tenant: The Azure AD tenant that owns the resources being managed. The customer retains control and can revoke delegation at any time. - Authorizations: Each authorization maps a principal from the managing tenant to an Azure RBAC role. You can use Azure AD groups to simplify management. Built-in roles like Contributor, Reader, and custom roles are supported. However, certain roles are not supported for delegation: Owner, User Access Administrator, and any roles with DataActions (e.g., Storage Blob Data Contributor) because Lighthouse cannot grant data plane permissions. - Registration Definition: A resource in the customer tenant (Microsoft.ManagedServices/registrationDefinitions) that stores the delegation configuration. It contains the managing tenant ID, authorizations, and scope. - Registration Assignment: A child resource (Microsoft.ManagedServices/registrationAssignments) that links the registration definition to a specific scope (subscription or resource group). - Managed by: A property on delegated resources that indicates the managing tenant. This is visible in the Azure portal under 'Managed by' for subscriptions/resource groups. - Onboarding Methods: - ARM Template (JSON): The most common method. The customer deploys a template that creates the registration definitions. - Managed Service Offer (Marketplace): For MSPs publishing offers to multiple customers. The customer accepts the offer in the Azure Marketplace. - PowerShell/CLI: Using New-AzManagedServicesDefinition and New-AzManagedServicesAssignment cmdlets. - Delegation Limits: A customer tenant can have up to 200 registration definitions per subscription. Each registration definition can have up to 400 authorizations. - Auditing: All delegated actions are logged in the customer's Activity Log under the managing user's identity (e.g., user@managingtenant.onmicrosoft.com). The customer can also view the 'Managed by' information.

Onboarding with PowerShell:

# Create authorization object
$auth = New-AzManagedServicesAuthorizationObject `
  -PrincipalId "<object-id-of-group-or-user>" `
  -RoleDefinitionId "<role-definition-id>" `
  -PrincipalIdDisplayName "My MSP Group"

# Create registration definition
$def = New-AzManagedServicesDefinition `
  -Name "MyDelegation" `
  -DisplayName "My MSP Delegation" `
  -Description "Delegation to MSP" `
  -ManagedByTenantId "<managing-tenant-id>" `
  -Authorization $auth

# Create registration assignment
New-AzManagedServicesAssignment `
  -RegistrationDefinitionId $def.Id `
  -Scope "/subscriptions/<subscription-id>"

Verification with Azure CLI:

# List all registration definitions in a customer tenant
az managedservices definition list

# List all registration assignments
az managedservices assignment list

# Show details of a specific definition
az managedservices definition show --definition <definition-id>

Checking delegated access:

# From managing tenant, list accessible resources in customer tenant
az account list --query "[?tenantId=='<customer-tenant-id>']"

# Switch to customer tenant context (if you have access)
az account set --subscription <customer-subscription-id>

When a managing user authenticates, Azure AD issues an access token for the resource https://management.azure.com. This token contains the user's home tenant (managing tenant) and the requested audience. The customer's ARM endpoint receives the token and performs a lookup in its registration definitions. If a matching delegation exists, ARM issues a new token scoped to the delegated subscription/resource group with the appropriate RBAC claims. This token is then used for subsequent resource operations. The entire process is transparent to the user, who simply selects the customer's subscription in the Azure portal or CLI.

A managed service provider (MSP) manages cloud infrastructure for 50+ small to medium businesses, each with its own Azure AD tenant. Before Lighthouse, the MSP had to create a dedicated user account in each customer tenant for each of its 20 engineers, resulting in 1,000+ accounts to manage. Password policies, MFA, and account lifecycle were a nightmare. With Azure Lighthouse, the MSP creates a single security group in its own tenant (e.g., 'MSP-Engineers') and adds engineers to that group. Each customer deploys an ARM template that delegates their subscription to that group with Contributor role. Now, when an engineer leaves, the MSP simply removes them from the group, and access is revoked across all customers within minutes (Azure AD group membership changes propagate quickly). The MSP also uses Lighthouse's ability to view all delegated subscriptions in a single 'My customers' blade in the Azure portal, enabling centralized monitoring and management. Performance is excellent because Lighthouse adds negligible latency (the token exchange is fast). Misconfiguration risk: if the MSP accidentally assigns Owner role (which is not allowed), the deployment fails with an error. The most common mistake is forgetting to include the role definition ID (a GUID) correctly in the ARM template, leading to deployment failure.

A large enterprise acquires a company that has its own Azure AD tenant. The enterprise wants to manage the acquired company's Azure resources from its central IT team's tenant without migrating everything immediately. Using Azure Lighthouse, the central IT team (in the enterprise tenant) is delegated Contributor access to the acquired company's subscriptions. This allows them to apply Azure Policy, deploy resources, and monitor costs while the acquired company retains ownership and can revoke access if needed. The central IT team uses Azure Blueprints to deploy Lighthouse templates consistently across multiple acquired tenants. A common challenge is that the acquired company's administrators may not be familiar with Lighthouse; they need to be trained to understand that delegating does not give away ownership. If the central IT team accidentally delegates to a group that includes external contractors, that could be a security risk. The enterprise mitigates this by using Privileged Identity Management (PIM) for the managing tenant group, requiring just-in-time activation for delegated roles.

A company uses a separate 'DR tenant' for disaster recovery. They want their primary tenant's administrators to be able to manage resources in the DR tenant during a failover. Instead of creating duplicate accounts, they use Azure Lighthouse to delegate Contributor access to the DR tenant's subscriptions from the primary tenant. This allows the same users to manage both environments seamlessly. However, they must ensure that during normal operations, the primary tenant users have limited access (e.g., Reader) to prevent accidental changes. They achieve this by creating two delegations: one with Reader for normal operations and one with Contributor that is activated only during a DR event. This scenario highlights the importance of using groups and role-based access to enforce least privilege.