Skip to content

Azure Lighthouse vs. B2B Guest Access Packages

How Azure Lighthouse simplifies multi-tenant access management across a Home Tenant (Tenant A) and a Resource Tenant (Tenant B)—and the hard Microsoft limits where you still need B2B Guest Access Packages.

1. What Azure Lighthouse Changes

Without Azure Lighthouse, managing a secondary tenant (Tenant B) requires creating B2B Guest accounts in Tenant B, running a second set of Access Packages and PIM policies in Tenant B, and having engineers switch directories in both myaccess.microsoft.com and the Azure Portal.

With Azure Lighthouse, Tenant B delegates its Azure Subscriptions (or Resource Groups) directly to a security group (pag-*) that lives in Tenant A (the engineer's home tenant):

flowchart LR
    subgraph TenantA["Tenant A (Home / Managing Tenant)"]
        USER["Synced Engineer<br/>alice@tenanta.com"]
        MYACCESS["MyAccess (Tenant A)<br/>myaccess.microsoft.com"]
        PKG["Tenant A Access Package"]
        PAG["Tenant A Persona Group<br/>(pag-tenantb-sub-contributor)"]
        PIM["Tenant A PIM for Groups<br/>(4h JIT Activation)"]

        USER --> MYACCESS --> PKG -->|"Eligible Member"| PAG
        PIM -->|"Activates"| PAG
    end

    subgraph TenantB["Tenant B (Delegated Resource Tenant)"]
        LH["Azure Lighthouse Registration<br/>(Microsoft.ManagedServices)"]
        SUB1["Subscription 1<br/>(Contributor / Reader)"]
        SUB2["Subscription 2<br/>(Contributor / Reader)"]

        LH --> SUB1
        LH --> SUB2
    end

    PAG ==>|"Cross-Tenant Projection<br/>(No Guest Account Needed)"| LH

What Azure Lighthouse Makes Easier

  1. One MyAccess & One PIM (in Tenant A): Engineers never have to visit myaccess.microsoft.com/@tenantb or switch directories to activate PIM for subscription work. They request the Access Package in Tenant A's MyAccess and activate the group in Tenant A's PIM (or use Lighthouse's built-in eligible authorization rules).
  2. No B2B Guest Accounts for Subscription Work: Engineers act as their native alice@tenanta.com identity. You don't need #EXT# guest accounts, guest lifecycle reviews, or Cross-Tenant MFA trust rules just to manage Azure resources inside Tenant B's subscriptions.
  3. No Directory Switching in the Azure Portal: In portal.azure.com, engineers stay signed into Tenant A and use the Directory + Subscription filter to view and manage Tenant B's subscriptions side-by-side with Tenant A's subscriptions in a single view.

2. The Catch: What Azure Lighthouse Cannot Do

Azure Lighthouse operates only on the Azure Resource Manager (ARM) plane at the Subscription or Resource Group scope. It has four hard architectural limits enforced by Microsoft:

Limitation What Microsoft Blocks Impact on Platform Personas
1. No Entra ID Directory Roles Lighthouse has zero integration with Entra ID directory roles or Microsoft Graph permissions. Cannot grant Global Administrator, Privileged Role Administrator, Security Administrator, Application Administrator, or manage Conditional Access in Tenant B.
2. No Management Group Scope Microsoft.ManagedServices/registrationAssignments can only be deployed at a Subscription or Resource Group—never at a Management Group (mg-tenant-root, mg-intermediate-root, mg-platform, mg-landingzones). You cannot delegate a Management Group tree once. Instead, your subscription-vending pipeline in Tenant B must attach the Lighthouse registration to every new subscription as it is vended.
3. No Full Owner Role Microsoft explicitly blocks delegating the Owner role (or unconstrained Role Based Access Control Administrator / User Access Administrator) over Lighthouse. At most, a Lighthouse-delegated identity can hold Contributor plus a conditioned User Access Administrator that is only allowed to assign a pre-approved list of built-in roles to delegated identities (never Owner).
4. Tenant-Bound Data Plane Limits Certain operations (creating Entra App Registrations/Service Principals, managing Key Vault access policies vs. RBAC, or certain Entra-bound data-plane APIs) require a principal object inside Tenant B's directory. Workloads or pipelines that vend identities in Tenant B must still run inside Tenant B.

3. Side-by-Side Comparison

Capability Azure Lighthouse (Tenant A → Tenant B) B2B Guest + Tenant B Access Packages
Where the pag-* group lives Tenant A (Home Tenant) Tenant B (Resource Tenant)
Where the engineer requests & activates Tenant A MyAccess & Tenant A PIM Tenant B MyAccess (/@tenantb) & Tenant B PIM
Requires B2B Guest account in Tenant B? No Yes
Requires switching directory in Azure Portal? No (cross-tenant view) Yes
Can grant Reader / Contributor on Subscriptions? Yes Yes
Can grant Owner at Management Groups (mg-*)? No (Subscription/RG scope only, no Owner) Yes
Can grant Entra ID Directory Roles in Tenant B? No Yes
Can manage Conditional Access / App Registrations in Tenant B? No Yes

Because Azure Lighthouse is much simpler for subscription-level work but cannot reach Tenant B's Entra ID or Management Groups, the cleanest multi-tenant design combines both:

flowchart TB
    ENG["Engineer in Tenant A<br/>(alice@tenanta.com)"]

    subgraph Tier12["90% of Day-to-Day Work: Tier 1 & Tier 2 (Azure Subscriptions)"]
        LH_FLOW["Tenant A Access Package + Tenant A PIM<br/>→ Azure Lighthouse Delegation"]
        LH_ROLES["• Contributor / Reader on Subscriptions<br/>• Network / Monitoring / Log Analytics Contributor<br/>• Security Reader on Subscriptions"]
        LH_FLOW --> LH_ROLES
    end

    subgraph Tier0["10% Control Plane Work: Tier 0 & Management Groups"]
        B2B_FLOW["B2B Guest in Tenant B<br/>→ Tenant B Access Package + Tenant B PIM"]
        B2B_ROLES["• Entra Directory Roles (Global Admin, PRA, Security Admin)<br/>• Conditional Access & Service Principal Vending<br/>• Owner at Tenant Root / mg-intermediate-root / mg-platform"]
        B2B_FLOW --> B2B_ROLES
    end

    ENG ==>|"No directory switch"| Tier12
    ENG ==>|"Switch to Tenant B"| Tier0
  1. Use Azure Lighthouse (from Tenant A) for Subscription-Level Access (Tier 1 / Tier 2):
  2. Create the pag-* groups, Access Packages, and PIM policies in Tenant A.
  3. Have Tenant B's subscription-vending module automatically deploy an azurerm_lighthouse_definition and azurerm_lighthouse_assignment to every subscription in Tenant B, mapping Reader, Contributor, Monitoring Contributor, and Log Analytics Contributor to Tenant A's pag-* groups.
  4. Engineers stay in Tenant A for all routine Azure engineering, monitoring, and troubleshooting.
  5. Use B2B Guests + Tenant B Access Packages Only for the Control Plane (Tier 0):
  6. Keep a small, tightly controlled set of B2B Guest accounts in Tenant B for senior platform engineers.
  7. Use Tenant B's own azure-privileged-access-grants and azure-privileged-access-packages strictly for roles Lighthouse cannot delegate: Entra ID directory roles (Global Administrator, Privileged Role Administrator, Security Administrator), Service Principal vending, Conditional Access, and Management Group Owner grants.