Entra Guest Admin Role Cross Tenant B2B Trust: How External Users Reach Global Administrator

Entra Guest Admin Role Cross Tenant B2B Trust: What These Settings Actually Control

Entra guest admin role cross tenant b2b trust settings are two of the least-reviewed layers of Microsoft Entra ID external identity governance, and they combine into one of the quietest privilege-escalation paths in the platform: an external guest account holding a directory role directly, sitting behind Cross-Tenant Access Settings that let other Microsoft Entra organizations reach your tenant by default. Neither half is exotic on its own — B2B collaboration and directory role assignment are both core, documented Entra features — but the combination is rarely audited as one control.

This is a different angle from two related gaps worth knowing first. If your concern is who can invite guests, whether they need MFA, or whether stale accounts pile up, see Azure Guest Accounts: The Forgotten Attack Surface. If your concern is a guest inheriting privilege by landing in a security group that nests into a role-assignable group, see Entra ID Nested Privileged Groups, Role-Assignable Groups, and Guests in Security Groups. This article covers something upstream of both: a guest holding a Microsoft Entra role directly — no group, no nesting — and the tenant-level B2B trust configuration that decides which external organizations can reach that guest's home identity in the first place.

Five checks make up this governance layer:

How a Guest Ends Up With a Directory Role, and How Trust Settings Widen the Door

Assigning a role to a guest is not a special case in Entra RBAC

Microsoft Entra's role-assignment model does not treat a guest principal differently from a member principal when it comes to holding a directory role. The same role-assignment workflow — New-MgRoleManagementDirectoryRoleAssignment in PowerShell, or POST /roleManagement/directory/roleAssignments in Microsoft Graph — that assigns Helpdesk Administrator to an internal employee assigns Global Administrator to an external guest object just as readily. Microsoft's own API documentation for listing role assignments shows this explicitly: its worked example of expanding the principal on a role assignment response includes guest users ("userType": "Guest") holding a directory role right alongside member users, with no special handling.

That matters because a guest's baseline directory permissions are intentionally narrow. Microsoft Entra's guest permission level (the authorizationPolicy.guestUserRoleId setting) defaults to Limited access (GUID 10dae51f-b6af-4016-8d66-8c2a99b929b3), and can be tightened to Restricted access (2af84b1e-32c8-42b7-82bc-daa82404023b), which stops a guest from even enumerating group membership beyond their own. But that setting governs default directory-object visibility for every guest — it is not a ceiling on what an explicit role assignment can grant to one guest. A guest assigned Global Administrator has full tenant administrative permissions regardless of how restrictive the baseline guest permission level is. Microsoft's own Zero Trust security guidance lists Guests are not assigned high privileged directory roles as a named recommendation, warning that a compromised guest account holding an elevated role gives attackers a path to escalate privilege, create backdoor accounts, and persist in the tenant — and third-party posture tools track it as its own standalone finding: Tenable's exposure catalogue lists "Guest Account With a Privileged Role" explicitly, citing reduced auditability and a weaker home-tenant security posture as the core risk.

Cross-Tenant Access Settings decide which external identities can even reach that assignment

A directory role assignment to a guest is only as contained as the external identity behind it. Microsoft Entra's Cross-Tenant Access Settings control that from the other direction — they are default, tenant-wide rules that apply to every other Microsoft Entra organization unless you configure organization-specific overrides. Per Microsoft's documented initial defaults:

• B2B collaboration (b2bCollaborationInbound / b2bCollaborationOutbound): all of your internal users are enabled for B2B collaboration by default — they can invite external guests, and be invited elsewhere as guests, with no per-organization allowlist required.
• Inbound trust (inboundTrust): MFA and device claims (compliant device, Microsoft Entra hybrid join) from external organizations are not trusted by default. If an admin later enables "Trust multifactor authentication from Microsoft Entra tenants" at the default scope rather than per-partner, every external Microsoft Entra organization's MFA claim is accepted — Conditional Access stops re-checking MFA for any guest, from any tenant, including ones you've never heard of. That's B2B_INBOUND_TRUST_ALL.
• B2B direct connect (b2bDirectConnectInbound / b2bDirectConnectOutbound): blocked in both directions, tenant-wide, by default — Microsoft documents this as the one setting in this family shipped closed: "outbound B2B direct connect is blocked for your entire tenant, and inbound B2B direct connect is blocked for all external Microsoft Entra organizations." B2B_DIRECT_CONNECT_ENABLED fires when a default-scope change — not an intentional per-partner one — opens it.
• Outbound access: also open by default — your users can be invited into any external Microsoft Entra organization's resources unless outbound access is scoped down. B2B_OUTBOUND_UNRESTRICTED flags exactly that unscoped outbound default.

Both allow/block lists and cross-tenant access settings are checked at invitation time, but if an external domain is on neither list, Microsoft Entra falls back to whatever the cross-tenant access default is set to — which, out of the box, is open to collaboration.

The Escalation Chain

Step 1 — An external org invites, or is invited, with no organization-specific restriction

Because default B2B collaboration settings allow inbound and outbound access to every external Microsoft Entra organization, a guest account from effectively any tenant can be invited into yours — or a compromised employee account can invite one — without hitting an allowlist check.

Step 2 — Inbound trust settings suppress a fresh MFA challenge

If inbound trust is configured to accept MFA claims from external organizations at the default scope, Microsoft Entra checks the guest's token for an MFA claim already satisfied in their home tenant — a tenant you don't control and can't audit. No fresh challenge is issued in your tenant if that claim is present, regardless of how weak or strong the home tenant's own MFA enforcement actually is.

Step 3 — The guest object is directly assigned a directory role

Somewhere in the tenant's history — a one-off vendor engagement, a break-glass workaround, an admin using "assign the guest Global Admin temporarily" as a shortcut that was never reverted — the guest's object ID was passed to a role assignment call. Nothing in Entra ID's RBAC blocks this at the API level, and unless someone is specifically querying role membership for guest principals, it doesn't surface in a routine "who are our admins" review that lists names by eye.

Step 4 — The privileged session persists across the guest's home tenant

Because authentication for that guest still happens in their home tenant, your Conditional Access policies, sign-in risk detections, and password/MFA enforcement in your tenant only see what the trust settings let through. A compromise of the guest's home-tenant credentials becomes, transitively, a compromise of a privileged identity in yours.

Detection

# Microsoft Graph — current default cross-tenant access posture
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default

# Microsoft Graph — every partner-specific override
GET https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/partners

# Microsoft Graph — all directory role assignments with principal expanded;
# filter the response client-side for principal.userType eq 'Guest'
GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignments?$expand=principal

// Microsoft Entra audit logs — role assignments landing on a guest UPN
AuditLogs
| where OperationName in ("Add member to role", "Add eligible member to role")
| where TargetResources[0].userPrincipalName contains "#EXT#"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName), Target = tostring(TargetResources[0].userPrincipalName)

// Microsoft Entra audit logs — default cross-tenant access setting changes
AuditLogs
| where Category == "CrossTenantAccessSettings"
| where OperationName has "default"
| project TimeGenerated, OperationName, InitiatedBy = tostring(InitiatedBy.user.userPrincipalName)

Remediation

1. Inventory every directory role assignment held by a guest, then decide for each one: does this need standing access, does it need a role at all, or was it never reverted after a short-term engagement. Treat "we don't know why this guest has this role" as an incident, not a config note.
2. Move any legitimate guest privileged access into PIM as an eligible, time-bound assignment with approval required, rather than a permanent direct assignment. See Azure Privileged Access: Too Many Global Admins for why standing privileged access is already a common finding even for member accounts, and Azure AD Premium P2 Features for what PIM requires to enable.
3. Set default inbound and outbound B2B collaboration access to Block, then add organization-specific settings only for the external tenants you actually collaborate with. Microsoft's own guidance is to identify inbound/outbound sign-ins first, so a default-to-block change doesn't sever active business access.
4. Move inbound MFA and device trust off the default scope. If you need to trust MFA from a specific partner, configure it as an organization-specific override for that partner only — not as a blanket default applied to every Microsoft Entra tenant that ever gets invited.
5. Leave B2B direct connect blocked by default — Microsoft's own initial posture — and only enable it, per organization, for partners you've validated through mutual configuration.
6. Scope outbound access down to the users and groups that actually need to collaborate externally, instead of leaving all internal users eligible for outbound B2B by default.
7. Run access reviews scoped specifically to privileged role membership, not just group membership — a review that only checks "who's in the Global Admins group" misses a guest with a direct role assignment sitting outside any group. Harden default tenant settings more broadly using Azure Tenant Hardening: Fix Insecure Default Settings as a companion checklist.

How EtcSec Detects This

EtcSec's Entra ID audit checks this governance layer directly. Guest User with Administrative Role (GUEST_ADMIN_ROLE) flags any guest principal holding a directory role assignment. Cross-Tenant Access Open (B2B_CROSS_TENANT_OPEN) and Outbound B2B Access Unrestricted (B2B_OUTBOUND_UNRESTRICTED) check the default inbound/outbound B2B collaboration posture against organization-specific overrides. Inbound Trust for All Organizations (B2B_INBOUND_TRUST_ALL) flags MFA/device trust configured at the default scope rather than per-partner. B2B Direct Connect Enabled (B2B_DIRECT_CONNECT_ENABLED) confirms direct connect hasn't been opened beyond Microsoft's blocked-by-default posture.

For the adjacent guest-governance angles this article doesn't cover, see Azure Guest Accounts: The Forgotten Attack Surface for invitation policy, MFA requirements, and stale-account cleanup, and Entra ID Nested Privileged Groups, Role-Assignable Groups, and Guests in Security Groups for guests reaching privilege through group nesting instead of a direct assignment. For the broader review these checks sit inside, see How to Audit Microsoft Entra ID Security.