Episode 5 — External Collaboration — Microsoft Entra B2B

Episode 4 closed out the internal side of identity: Entra ID editions, which admin features need P1 or P2, and how group-based licensing distributes those licenses. But not everyone who needs your apps is on your payroll — this episode opens the tenant door to partners, safely.

Learning objectives

Explain how B2B collaboration lets partners use their own credentials, and how a guest is represented in your directory.
Invite an external user from the Microsoft Entra admin center and track the invitation state.
Distinguish cross-tenant access settings from external collaboration settings, and predict the outcome when the two disagree.
Configure who may send invitations and which partner domains are allowed or blocked.
State how SSPR applies (and doesn't apply) to B2B users.

Why it matters

Almost every organization collaborates with vendors, consultants, and partner companies. Creating full internal accounts for them means managing external passwords, credentials, and account lifecycles you don't control — a security and audit liability. Microsoft Entra B2B collaboration solves this: guests authenticate with their home identity while you keep control over what they can reach in your tenant. On the AZ-104 exam, the classic traps are the guest object anatomy (#EXT#, user type), the least-privilege role for inviting, and above all the difference between the two control planes — cross-tenant access settings and external collaboration settings — including which one wins.

What B2B collaboration is

B2B collaboration is part of Microsoft Entra External ID and applies to workforce tenants. It lets you share your company's applications and services with guests while maintaining control over your own corporate data — the partner doesn't even need Microsoft Entra ID or an IT department.

The core principle: the partner uses their own identity management solution, so there is no external administrative overhead for you:

Guests sign in with their own work, school, or social identities — whether or not they have a Microsoft Entra account.
You don't manage external accounts or passwords.
You don't sync accounts or manage account lifecycles.

Once a guest redeems an invitation (or completes self-service sign-up), they are represented in your directory as a user object — typically with user type "guest" and a user principal name containing the #EXT# identifier. Recall the Episode 2 matrix: this is the external guest quadrant — authenticates externally, holds guest-level privileges. (A user object with a domain account can also be created as a guest by setting User type = Guest in the regular create-user flow.)

One default worth memorizing: the email one-time passcode feature is turned on by default for all new tenants and for existing tenants that haven't explicitly turned it off. Guests without any federated or social identity simply receive a code by email. If the feature is turned off, the fallback is to prompt invitees to create a Microsoft account.

Invitation and redemption

The whole exchange is a simple invitation and redemption process:

Since a 2025 rollout, guests are redirected to their own organization's sign-in page (their home tenant's branding and URL) to provide credentials, then returned to your organization to complete sign-in — a useful cue when users report an "unexpected" sign-in page.

Inviting in the portal

The least-privilege role to invite a guest is Guest Inviter (creating regular users takes User Administrator; assigning Microsoft Entra roles takes Privileged Role Administrator). Steps:

Sign in to the Microsoft Entra admin center.
Browse to Entra ID > Users.
Select New user > Invite external user.
On the Basics tab, enter the guest's email address and display name, and optionally check Send invite message to add a brief custom message (with a Cc recipient if needed).
Review + create — the invitation email containing a redemption link goes out. You can alternatively send a direct link to an app you want to share.

Two restrictions to remember: external users can't be assigned to administrative units, and after creation you assign the guest to apps or groups just like any other user.

Tracking the invitation

To check on an invitation: Entra ID > Users > select the invited guest > in the My Feed section, locate the B2B collaboration tile. If the invitation state is PendingAcceptance, use the Resend invitation link. The state is also visible under the user's Properties as Invitation state.

The two control planes

B2B collaboration is enabled by default, and two separate groups of settings govern it. Confusing them is the number-one B2B mistake.

	Cross-tenant access settings	External collaboration settings
Governs	Whether users can authenticate across tenants	Who in your org can send invitations
Direction	Inbound and outbound B2B collaboration	Outgoing invitations only
Granularity	Default configuration for all external orgs + per-organization settings; scope to specific users, groups, applications	Invitations on/off for everyone, or limited to certain roles; domain allow/blocklist; guest access restrictions on your directory
Extras	Trust MFA and device claims (compliant, Microsoft Entra hybrid joined) from other Entra organizations	By default all users, including B2B guests, can invite
Applies to	Other Microsoft Entra organizations	Any invited domain

🧠 Mnemonic: Cross-tenant access = "can they get in?" — external collaboration settings = "can we invite them?"

When the two planes disagree about invitations, the most restrictive setting applies. Two worked examples straight from the documentation:

Example 1 — You block adatum.com in external collaboration settings, but cross-tenant access settings enable B2B collaboration for all Microsoft Entra organizations. Result: most restrictive wins — your users can't send invitations to adatum.com.
Example 2 — You allow Fabrikam in cross-tenant access settings, then add fabrikam.com to the blocked domains list in external collaboration settings. Result: users can't invite new Fabrikam guests, but existing Fabrikam guests continue to have access — blocking a domain stops new invitations, it doesn't cut off guests who already redeemed.

Across Microsoft clouds

By default, cross-tenant collaboration stays within the same Microsoft cloud. With Microsoft cloud settings you can establish mutual B2B collaboration between the Microsoft Azure global cloud and Azure Government, or between the global cloud and Microsoft Azure operated by 21Vianet. Both tenants must enable the setting for the other cloud, then configure inbound and outbound cross-tenant access as usual.

Beyond one-by-one invitations

Manual invitations don't scale to every scenario, so B2B offers several complementary mechanisms:

Self-service sign-up user flows — build a sign-up experience for guests who want access to your apps, offering different social or enterprise identity providers (Facebook, Microsoft accounts, Google, or federated enterprise IdPs) and collecting user information. API connectors integrate the flow with external systems for custom approval workflows, identity verification, and validation.
Delegated guest management — administrators set up self-service app and group management, and application or group owners then add guest users themselves through the Access Panel (myapps.microsoft.com) — no admin ticket needed.
Entitlement management — policy-driven onboarding that manages access packages for external users; the B2B invitation APIs allow fully customized onboarding experiences.
Conditional Access for guests — policies such as multifactor authentication can be enforced at the tenant level, the application level, or for specific guest users. Guests are not exempt from your guardrails.
SharePoint and OneDrive integration — share files, folders, list items, document libraries, and sites externally using B2B for authentication; enabling it also turns on the email one-time passcode fallback.

Password reset for B2B users

What happens when a guest forgets their password? Password reset and change are fully supported on all B2B configurations — but where the reset happens depends on the identity:

Guest identity	Who handles the reset
Partner org with its own Microsoft Entra tenant	Their home tenant's password reset policies apply (SSPR must be enabled there)
Self-service sign-up user	Resets with the email they registered at sign-up
Invited B2B user	Resets with the email registered during the invite process
Personal Microsoft account (Hotmail.com, Outlook.com…)	Cannot use Microsoft Entra SSPR — Microsoft's own account recovery applies

This is consistent with the B2B philosophy: you don't manage partner credentials, so partner-tenant guests reset at home, and only identities that exist because of your processes (self-service sign-up, invite-time email) reset through your side.

Practice

Exercise 5.1 — Invite a guest and track the invitation

In a trial tenant, invite an external collaborator (use a personal test mailbox you own) and verify the invitation state before and after redemption. Which role would you grant a helpdesk operator whose only job is sending such invitations?

Solution

Sign in to the Microsoft Entra admin center and browse to Entra ID > Users.
Select New user > Invite external user.
On Basics: enter the test email address, a display name, check Send invite message, and add a short message. Select Review + create.
Open the new guest user: in My Feed, find the B2B collaboration tile — the invitation state shows PendingAcceptance (also visible under Properties > Invitation state). The Resend invitation link is available in this state.
Open the invitation email in the test mailbox and follow the redemption link, signing in with the mailbox identity (email one-time passcode if there's no Entra/social account). Back in the portal, the state is no longer PendingAcceptance; the user object shows user type Guest and a UPN containing #EXT#.

Role: Guest Inviter — the least-privilege role for inviting external guests. User Administrator also works but grants far more than needed.

Exercise 5.2 — Blocked domain vs cross-tenant access

Your external collaboration settings block adatum.com, but your cross-tenant access settings allow B2B collaboration with all Microsoft Entra organizations, and three Adatum guests already redeemed invitations last year. A project manager tries to invite a fourth Adatum engineer today. What happens to (a) the new invitation and (b) the three existing guests?

Solution

(a) The invitation fails: when the two control planes disagree, the most restrictive setting applies, and the domain blocklist in external collaboration settings stops new invitations to adatum.com — regardless of the permissive cross-tenant access configuration.

(b) The three existing guests continue to have access: blocking a domain prevents new invitations only; it doesn't revoke already-redeemed guests, and cross-tenant access settings still allow them to authenticate. To actually cut them off you'd have to act on the guest accounts or the cross-tenant access side.

Exercise 5.3 — Only Sales may invite, only one partner

Management wants exactly this: only members of the Sales team can invite guests, and only from fabrikam.com. Which settings do you change, and where?

Solution

Both requirements live in external collaboration settings (this is about sending invitations, not authentication):

Who can invite: by default everyone, including guests, can invite. Restrict invitations so they're limited to certain roles, and grant the Sales team members the Guest Inviter role (a group containing the Sales users keeps this manageable). Everyone without such a role can no longer invite.
Which domains: configure the domain allow/blocklist to allow only fabrikam.com — invitations to any other domain are then rejected.

Cross-tenant access settings don't need to change for this requirement: they control whether authentication is possible, and the default configuration already permits B2B collaboration. If you also wanted to tighten authentication to Fabrikam only, that would be a cross-tenant access change — a different control plane.

Key takeaways

B2B collaboration lets guests use their own work, school, or social credentials — you don't manage their passwords or account lifecycles.
A redeemed guest is a user object in your directory with user type "guest" and #EXT# in the UPN.
Email one-time passcode is on by default; turned off, the fallback is creating a Microsoft account.
Least privilege: Guest Inviter invites guests; invitations are tracked via the B2B collaboration tile and resent while PendingAcceptance; guests can't join administrative units.
Cross-tenant access settings control whether users can authenticate across tenants (inbound/outbound, per-org, MFA/device trust); external collaboration settings control who can send invitations and the domain allow/blocklist.
When the planes conflict, the most restrictive setting wins for invitations; blocking a domain stops new invites but existing guests continue.
Conditional Access applies to guests — at tenant, application, or per-guest level.
SSPR for B2B users is supported per configuration, but personal Microsoft accounts can't use Entra SSPR.

Quick recall

Q: How do you recognize a B2B guest account in your directory? A: A user object with user type "guest" and the #EXT# identifier in its user principal name.

Q: Which least-privilege role lets someone invite external guests? A: Guest Inviter.

Q: A guest's invitation state shows PendingAcceptance — what can you do from the portal? A: Use the Resend invitation link on the B2B collaboration tile in the user's My Feed (state is also under Properties > Invitation state).

Q: Scenario — cross-tenant access settings allow Contoso, but contoso.com was just added to your blocked domains. A Contoso guest invited last month tries to sign in; a colleague tries to invite a new Contoso guest. Outcomes? A: The existing guest still signs in (blocklist affects only new invitations, and cross-tenant access allows authentication); the new invitation is blocked — most restrictive setting wins.

Q: What is the default behavior when an invited guest has no Entra, social, or federated identity? A: They authenticate with an email one-time passcode (on by default); if that feature is off, they're prompted to create a Microsoft account.

Q: Can a guest with a Hotmail.com account use your tenant's SSPR? A: No — personal Microsoft accounts can't use Microsoft Entra SSPR; they use Microsoft's own account recovery.

Coming up

Guests reset passwords at home — but what about your own users? Episode 6 dissects Self-Service Password Reset: how the reset flow decides whether a user may proceed, authentication methods and one-vs-two-gate policies, registration and reconfirmation, notifications, on-premises writeback, and why administrators follow a stricter policy of their own.