Multi-Tenant Access Packages (Home & Guest Tenants)¶

How Entra ID Entitlement Management (Access Packages) and PIM for Groups work when your workforce identities sync from on-premises Active Directory into a Home Tenant (Tenant A) and manage a Resource Tenant (Tenant B) as B2B Guests.

1. The Multi-Tenant Scenario¶

A common enterprise architecture separates the corporate workforce directory from secondary or dedicated cloud resource tenants:

Tenant A (Home / Workforce Tenant): Syncs human user accounts from on-premises Active Directory (AD DS) via Entra Connect or Cloud Sync. Every engineer's primary identity (alice@tenanta.com) lives and authenticates here.
Tenant B (Resource / Secondary Tenant): Does not sync directly from on-prem AD DS. Instead, users from Tenant A are provisioned into Tenant B as B2B Guest (or Cross-Tenant Synced) users (alice_tenanta.com#EXT#@tenantb.onmicrosoft.com), and those guest identities are used for access management in Tenant B.

2. Does `myaccess.microsoft.com` Show Packages From All Tenants at Once?¶

No. Both the MyAccess portal (myaccess.microsoft.com) and Entra PIM are strictly scoped to one tenant at a time:

When a user opens https://myaccess.microsoft.com, Entra signs them into their home tenant (Tenant A) by default. They will only see Access Packages hosted inside Tenant A.
Access Packages from Tenant B will never appear mixed into Tenant A's MyAccess list.

How a User Accesses Packages and PIM in Tenant B¶

To request an Access Package or activate a group in Tenant B, the engineer must explicitly target Tenant B at both stages of the JIT flow:

Stage	In Tenant A (Home Tenant)	In Tenant B (Resource Tenant)
Stage 1: Request Access Package (MyAccess)	Open `https://myaccess.microsoft.com`	Either: 1. Open the tenant-scoped URL: `https://myaccess.microsoft.com/@<tenant-b-domain-or-tenant-id>` (e.g. `https://myaccess.microsoft.com/@tenantb.onmicrosoft.com`), or 2. Click the Organization Switcher (top-right profile menu in MyAccess) and switch from Tenant A to Tenant B.
Stage 2: Activate Group (PIM for Groups)	Open Entra / Azure Portal → PIM → My roles → Groups	First use the portal Directory + Subscription Switcher (top-right) to switch into Tenant B, then open PIM → My roles → Groups and activate the Tenant B PAG.
Using Azure CLI (`az login`)	`az login`	`az login --tenant <tenant-b-id-or-domain>` (after activating the PAG in Tenant B's PIM)

3. Architecture Across Tenant A and Tenant B¶

An Access Package in Tenant A can only grant membership to groups and roles inside Tenant A, and an Access Package in Tenant B can only grant membership to groups and roles inside Tenant B. Therefore, each tenant deploys its own independent instance of the Access Management stack (azure-privileged-access-grants + azure-privileged-access-packages):

flowchart TB
    subgraph OnPrem["On-Premises"]
        AD["Active Directory (AD DS)"]
    end

    subgraph TenantA["Tenant A (Home Tenant)"]
        USER_A["Synced User<br/>alice@tenanta.com"]
        MYACCESS_A["MyAccess (Tenant A)<br/>myaccess.microsoft.com"]
        PKG_A["Tenant A Access Packages<br/>→ Tenant A PAGs & Roles"]
        PIM_A["Tenant A PIM for Groups"]
        USER_A --> MYACCESS_A --> PKG_A --> PIM_A
    end

    subgraph TenantB["Tenant B (Resource Tenant)"]
        GUEST_B["B2B Guest User<br/>alice_tenanta.com#EXT#@tenantb..."]
        REQ_B["Requestor / Approver Groups<br/>(sg-priv-tier-0-requestors)"]
        MYACCESS_B["MyAccess (Tenant B)<br/>myaccess.microsoft.com/@tenantb"]
        PKG_B["Tenant B Access Packages<br/>→ Tenant B PAGs & Roles"]
        PIM_B["Tenant B PIM for Groups<br/>(Switch directory to Tenant B)"]

        GUEST_B --> REQ_B
        GUEST_B --> MYACCESS_B --> PKG_B --> PIM_B
    end

    AD ==>|"Entra Connect"| USER_A
    USER_A ==>|"B2B Invite or<br/>Cross-Tenant Sync"| GUEST_B

4. Two Patterns for Onboarding Tenant A Users into Tenant B Packages¶

In Tenant B, how you configure the Catalog and Access Package depends on whether the Tenant A users already exist as Guest objects in Tenant B before they request a package:

Pattern 1: Pre-Provisioned B2B Guests (Recommended for Platform Teams)¶

Users from Tenant A are already created as B2B Guest accounts in Tenant B (either via Cross-Tenant Synchronization or controlled guest invitation).

How it works: Because a Guest user object already exists inside Tenant B's Entra directory, Tenant B treats them like any other directory user for group membership.
Configuration in Tenant B:
Add the Tenant B Guest user objects (alice_tenanta.com#EXT#@...) to Tenant B's sg-priv-tier-0-requestors and sg-priv-tier-0-approvers groups.
Keep externally_visible = false on the catalog (or true if desired).
Target the Access Package assignment policy at the local group sg-priv-tier-0-requestors—the exact same Terraform module call used in a single-tenant setup.
Why this fits Tier 0 / Tier 1: You explicitly control which external identities exist in Tenant B and belong to sg-priv-tier-0-requestors (in Lane A) before they can ever see or request a privileged package.

Pattern 2: On-Demand Guest Onboarding via Connected Organizations¶

Users exist in Tenant A, and they have not been invited to Tenant B yet. You want the Access Package in Tenant B to automatically invite them as a B2B Guest the first time they request access.

How it works: Tenant B trusts Tenant A as a Connected Organization in Entitlement Management.
Configuration in Tenant B:
Set externally_visible = true on the azuread_access_package_catalog.
Register Tenant A as a Connected Organization (azuread_access_package_catalog_role_assignment / Graph connectedOrganizations).
Configure the Access Package's assignment policy for Users not in your directory → Specific connected organizations (Tenant A), specifying an internal or external sponsor/approver.
User flow: A user in Tenant A opens https://myaccess.microsoft.com/@<tenant-b-domain>, sees the package made available to their home organization, and submits a request. Once approved, Entra Entitlement Management automatically creates their B2B Guest account in Tenant B and binds their eligibility.

Comparison	Pattern 1: Pre-Provisioned Guests	Pattern 2: Connected Organization (On-Demand)
Guest account exists before request?	Yes (via Cross-Tenant Sync or invite)	No (created automatically upon approval)
Catalog `externally_visible`	`false` (or `true`)	Must be `true`
Assignment policy scope	Specific group (`sg-priv-tier-0-requestors` in Tenant B)	Connected organization (`Tenant A`)
Best suited for	Privileged platform personas (Tier 0 / Tier 1) with a known roster of engineers	Broad workforce / partner onboarding where you don't want to pre-create guests

Syncing Profile Attributes (jobTitle, department) from Tenant A to Tenant B

If you use attribute-based auto-assignment or dynamic requestor groups (for example, user.jobTitle -eq "Platform Engineer"), Entra Cross-Tenant Synchronization automatically maps profile attributes (jobTitle, department, companyName, or custom extension attributes) from the user's home account in Tenant A onto their B2B Guest object in Tenant B.

That means when on-prem AD DS updates a user's title to Platform Engineer in Tenant A, Cross-Tenant Sync updates their Guest profile in Tenant B, which can automatically place them into Tenant B's requestor group or auto-assign baseline Tenant B packages without manual group edits in either tenant.

5. Essential Multi-Tenant Settings in Tenant B¶

When operating Access Packages and PIM for B2B Guests in Tenant B, three tenant-level details matter:

1. Cross-Tenant MFA Trust (Prevents Double MFA Registration)¶

Every PIM activation in Tenant B requires MFA. Without cross-tenant trust, when alice@tenanta.com tries to activate a PAG in Tenant B, Tenant B ignores the MFA she already completed in Tenant A and forces her to register a second Microsoft Authenticator profile specifically inside Tenant B.

Fix: In Tenant B's External Identities → Cross-tenant access settings, add an inbound trust rule for Tenant A and enable Trust multifactor authentication from Microsoft Entra tenants (and optionally compliant/hybrid-joined device claims).
Result: When Alice activates a group in Tenant B's PIM, Tenant B accepts the MFA claim from her home tenant (Tenant A) seamlessly.

2. Can B2B Guests Hold Role-Assignable Groups and Directory Roles in Tenant B?¶

Yes. In Microsoft Entra ID, a B2B Guest user object in Tenant B can: - Be a member of sg-priv-tier-0-requestors and sg-priv-tier-0-approvers. - Be bound as an Eligible Member of a role-assignable PAG (pag-*) in Tenant B. - Activate that PAG in Tenant B's PIM to receive both Entra ID directory roles and Azure RBAC roles in Tenant B for the duration of the activation window.

(Note: verify your organization's policy on whether external guests vs. cross-tenant internal workforce members are permitted to hold Tier 0/1 roles; see Guest Access for partner/external guest restrictions vs. internal multi-tenant workforce setups).

3. Licensing in Both Tenants¶

Both Stage 1 (Entitlement Management Access Packages) and Stage 2 (PIM for Groups) require Microsoft Entra ID P2 (or Entra ID Governance) licensing in the tenant where the access package and PIM policy are enforced. Ensure Tenant B has sufficient P2 / Governance licenses (or Microsoft External ID MAU governance billing linked) to cover the guest engineers activating roles in Tenant B.