Azure Lighthouse for Managed Security Services

Azure Lighthouse is a Microsoft service that enables service providers (or enterprises managing multiple tenants) to manage customer environments at scale using their own Azure Active Directory (Azure AD) tenant. It eliminates the need to create individual user accounts in each customer tenant, reducing administrative overhead and security risks. Instead, Lighthouse uses a delegated resource management model where the customer grants the service provider's tenant access to specific subscriptions, resource groups, or resources via Azure RBAC role assignments. The service provider's users authenticate in their home tenant, and Azure AD issues tokens that include delegated permissions scoped to the customer's resources.

Azure Lighthouse operates on a delegation model. The customer (also called the managing tenant) must first onboard a subscription or resource group for management by the service provider. This is done by deploying an Azure Resource Manager (ARM) template in the customer's tenant that defines the delegation. The template specifies:

Once the template is deployed, Azure AD in the customer's tenant creates a service principal for the service provider's tenant. This service principal is a representation of the provider tenant within the customer tenant. The RBAC role assignments are then applied to that service principal. When a service provider user authenticates to Azure, they receive a token from their home tenant. That token includes a claim that indicates they are acting on behalf of the managing tenant. Azure Resource Manager (ARM) checks the token and then looks up the delegation in the customer tenant. If the user's home tenant ID matches the managing tenant ID in the delegation, and the user has an applicable RBAC role assignment (via group membership), access is granted.

Key technical details:

To onboard a subscription using Azure Lighthouse, the customer deploys an ARM template. Here is a simplified example:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "mspOfferName": {
      "type": "string",
      "metadata": {
        "description": "Name of the MSP offer"
      }
    },
    "mspOfferDescription": {
      "type": "string",
      "metadata": {
        "description": "Description of the MSP offer"
      }
    },
    "managedByTenantId": {
      "type": "string",
      "metadata": {
        "description": "Tenant ID of the managing tenant"
      }
    },
    "authorizations": {
      "type": "array",
      "metadata": {
        "description": "Array of authorization objects"
      }
    }
  },
  "resources": [
    {
      "type": "Microsoft.ManagedServices/registrationDefinitions",
      "apiVersion": "2020-02-01-preview",
      "name": "[guid(parameters('mspOfferName'))]",
      "properties": {
        "registrationDefinitionName": "[parameters('mspOfferName')]",
        "description": "[parameters('mspOfferDescription')]",
        "managedByTenantId": "[parameters('managedByTenantId')]",
        "authorizations": "[parameters('authorizations')]"
      }
    }
  ]
}

To verify delegations, use Azure CLI:

az managedservices definition list
az managedservices assignment list

Or in PowerShell:

Get-AzManagedServicesDefinition
Get-AzManagedServicesAssignment

A large MSSP manages security for 500+ customers, each with their own Azure subscription. Without Lighthouse, the MSSP would need to create a dedicated Azure AD user account in each customer tenant for each of its 50 security analysts—resulting in 25,000 accounts to manage. Password rotations, MFA enforcement, and offboarding become a nightmare. With Lighthouse, the MSSP onboards each customer subscription using an ARM template that grants the MSSP's 'SecurityAnalysts' group the Reader role (for monitoring) and a custom 'SecurityResponder' role (for taking actions like shutting down VMs). The analysts authenticate in the MSSP's own tenant, where MFA and PIM are enforced. The customer retains full control: they can revoke access immediately if the contract ends. The MSSP uses Azure Sentinel to aggregate security events across all customer tenants, leveraging Lighthouse to manage the Sentinel workspaces centrally. A common misconfiguration is granting Contributor instead of Reader to analysts, leading to accidental deletions. The MSSP mitigates this by using custom roles and PIM for elevated access.

A global corporation has multiple subsidiaries, each with its own Azure AD tenant (for isolation). The central IT team needs to manage compliance policies (Azure Policy) across all subsidiaries. Instead of creating guest accounts in each subsidiary, the central IT team uses Lighthouse. They deploy delegations in each subsidiary's subscription, granting the central 'PolicyAdmin' group the 'Resource Policy Contributor' role. The central team can then assign Azure Policy initiatives across all subsidiaries from their home tenant. A challenge is that each subsidiary must approve the delegation, which can be slow. To scale, the enterprise uses Azure Blueprints to automate the onboarding of new subsidiaries. They also monitor delegations using Azure Monitor to detect unauthorized changes. A common issue is that the central team accidentally assigns roles at the wrong scope (e.g., management group instead of subscription), which Lighthouse does not support (delegations must be at subscription or resource group level).

An ISV provides a SaaS solution that requires managing Azure infrastructure for each customer. They use Lighthouse to give their DevOps team Contributor access to customer resource groups containing the application. This allows them to deploy updates and fix issues without exposing the entire subscription. They implement PIM with approval workflows for any role that can modify resources. A frequent problem is that the customer's IT team inadvertently revokes the delegation while troubleshooting, causing the ISV to lose access and triggering a support call. The ISV educates customers to use the 'Service providers' blade to check delegations before making changes. They also set up Azure Alerts to notify them if a delegation is deleted.