This chapter covers Microsoft Entra External Identities for B2B collaboration, a critical component of identity and access management in Microsoft 365. On the MS-900 exam, this topic falls under Domain 3: Security, Compliance, Privacy, and Trust, specifically Objective 3.3: Describe the identity and access management capabilities of Microsoft 365. Expect 2-3 questions on B2B collaboration, focusing on how it differs from B2C, guest user access, and integration with Conditional Access. Understanding the mechanics of B2B collaboration is essential for configuring secure external sharing in a hybrid or cloud-only environment.
Jump to a section
Think of Microsoft Entra External Identities (B2B) as a visitor badge system for a corporate headquarters. In this analogy, your company's building is your Microsoft 365 tenant, and employees have permanent badges (internal accounts). When a partner from another company needs to access a specific meeting room or shared workspace, they don't get a full employee badge—they get a temporary visitor badge that grants limited access. The visitor badge is issued by the front desk (Entra ID) after verifying the visitor's identity from their own company's ID (their home tenant). The badge is linked to their existing identity; they don't need a new one. The badge can be set to expire after a certain time, and access can be revoked at any moment. Crucially, the visitor can use their own company's badge reader (their existing credentials) to enter—they don't need to memorize a new PIN. This is exactly how B2B collaboration works: external users authenticate using their home tenant credentials, and Entra ID issues a token that grants access to resources in your tenant, without creating a separate account for them. The system also supports advanced policies like multifactor authentication (MFA) enforced by your tenant, even if the visitor's home tenant doesn't require it. Just as a visitor badge can be customized to allow access only to certain floors, B2B collaboration allows granular control over which apps and data the external user can see.
What is Microsoft Entra External Identities (B2B)?
Microsoft Entra External Identities (formerly Azure AD B2B) is a feature of Microsoft Entra ID (Azure AD) that enables organizations to securely share applications and resources with external users (guests) while letting them authenticate using their own identity provider. The key principle is that external users are represented as guest users in your tenant, but their credentials are managed by their home organization or personal identity provider (e.g., Microsoft account, Google, Facebook, or any SAML/WS-Fed IdP). This eliminates the need to manage external user passwords or create duplicate accounts.
B2B collaboration is distinct from B2C (business-to-consumer), which is designed for customer-facing applications with self-service sign-up. B2B is intended for partner, vendor, or contractor access where the external user already has an identity that can be trusted.
How B2B Collaboration Works Internally
The process begins when an internal user (inviter) invites an external user via email, Azure portal, or PowerShell. The invitation is sent to the external user's email address. The external user clicks the link in the invitation, which redirects them to Entra ID's redemption endpoint. At this point, Entra ID determines the external user's identity provider based on the email domain. - If the domain is a Microsoft Entra ID tenant (e.g., partner.com), the user is redirected to their home tenant to authenticate. After successful authentication, the home tenant issues a token that includes claims about the user's identity. Entra ID then creates a guest user object in the resource tenant with a UserType of "Guest" and a unique object ID. - If the domain is a consumer identity (e.g., gmail.com, outlook.com), the user can authenticate using a Microsoft account (MSA) or a one-time passcode (OTP) if the email domain is not associated with an Entra ID tenant. The OTP option is enabled by default for domains that cannot be verified. - If the external user's home tenant has Conditional Access policies, those policies are evaluated during authentication. However, the resource tenant can also enforce its own Conditional Access policies on guest users, such as requiring MFA or compliant devices.
Once the guest user object is created, the guest user can access shared resources (e.g., SharePoint sites, Teams, apps) using their own credentials. The resource tenant trusts the authentication performed by the home tenant, but the resource tenant's policies (like MFA) can be applied at the time of resource access.
Key Components, Values, Defaults, and Timers
Guest User Object: Created in the resource tenant with UserType = "Guest". It has a separate UPN (usually email) and object ID. The guest user is not a member of any security groups by default.
Invitation Expiration: If the guest user does not redeem the invitation within 30 days (default), the invitation expires. This can be configured via PowerShell.
One-Time Passcode (OTP): For email domains that are not associated with a Microsoft Entra ID or MSA, Entra ID can send a one-time passcode to the email address for authentication. This is enabled by default in the External Identities settings.
External Identities Settings: In the Entra admin center, under "External Identities" -> "External collaboration settings", you can configure:
Guest user access level: Can be limited to properties and memberships of their own guest user object, or allowed to have same access as members (not recommended).
Guest invite settings: Who can invite guests (admins, members, or all users).
Enable or disable the ability to invite guests.
Cross-tenant Access Settings: You can configure inbound and outbound trust settings for specific tenants. This includes allowing or blocking B2B collaboration from specific domains, and applying MFA or device compliance trust from the home tenant.
Configuration and Verification Commands
To invite a guest user via PowerShell:
New-MgInvitation -InvitedUserEmailAddress "user@partner.com" -InviteRedirectUrl "https://myapps.microsoft.com" -SendInvitationMessage:$trueTo list guest users:
Get-MgUser -Filter "UserType eq 'Guest'"To configure external collaboration settings:
Update-MgPolicyCrossTenantAccessPolicyDefault -B2BCollaborationInbound @{AllowedIdentities=@(@{Type='ExternalUsersAndGroups';Values=@('All')})}Interaction with Related Technologies
Microsoft Teams: Guest users can be added to Teams as guests. They have limited capabilities (cannot create channels, cannot view org chart). They authenticate using their home credentials.
SharePoint Online: External sharing can be configured at the tenant, site, or file level. B2B collaboration integrates with SharePoint's external sharing by using guest user objects.
Conditional Access: Policies can target guest users specifically. For example, require MFA for all guest users accessing sensitive apps. The resource tenant can enforce MFA even if the guest's home tenant does not require it.
Identity Protection: Guest users are not covered by Identity Protection risk detections in the resource tenant; risk is evaluated by the home tenant.
Azure AD B2C: For customer-facing apps, use B2C; for partner access, use B2B. They are separate products but can coexist.
Initiate Invitation
An internal user (with appropriate permissions) initiates an invitation via Azure portal, Teams, SharePoint, or PowerShell. The invitation includes the guest's email address and a redirect URL that the guest will see after redemption. The invitation is recorded in the resource tenant's invitation log. The system generates a unique redemption URL and sends an email to the guest with a link to accept the invitation. The email includes the tenant name and a personalized message if provided.
Guest Clicks Invitation Link
The guest receives the email and clicks the link. The link points to the Entra ID redemption endpoint (https://login.microsoftonline.com/...). The browser is redirected to the Microsoft identity platform. Entra ID inspects the email domain of the guest to determine the identity provider. If the domain is associated with a Microsoft Entra tenant, the guest is redirected to that tenant's login page. If it's a consumer domain (Gmail, Yahoo, etc.), the guest is prompted to choose between Microsoft Account or one-time passcode.
Authentication at Home Tenant
If the guest's domain is managed by another Entra ID tenant, the guest authenticates using their home tenant's credentials (username/password, MFA, etc.). The home tenant issues a security token that includes the user's immutable ID, tenant ID, and claims. This token is sent to the resource tenant's Entra ID. The resource tenant validates the token and creates a guest user object if one does not already exist. The guest user object is assigned a new UPN (usually the email) and a unique object ID in the resource tenant.
Consent and Redemption
After successful authentication, the guest is presented with a consent screen (if required) that lists the permissions the resource tenant is requesting (e.g., access to apps, profile information). The guest must accept to complete redemption. Once accepted, the guest is redirected to the originally specified redirect URL (e.g., My Apps portal). The guest user object is now active and can be assigned to apps, groups, or SharePoint sites. The guest's access can be immediately revoked by deleting the guest user object or removing assignments.
Resource Access
When the guest accesses a resource (e.g., a SharePoint site), the resource tenant's Entra ID issues an access token for the guest. The guest's authentication is not re-evaluated unless the token expires (default 1 hour). The resource tenant applies any Conditional Access policies targeting guest users. For example, if MFA is required for guests, the guest will be prompted for MFA even if they already authenticated at their home tenant. The guest's session is maintained until the token expires or the user signs out.
Enterprise Scenario 1: Partner Access to SharePoint Extranet
A large manufacturing company needs to share engineering documents with a dozen external partner firms. They create a SharePoint site for each partner and invite guest users from those firms using B2B collaboration. The guest users authenticate using their own corporate credentials (Entra ID). The manufacturing company configures Conditional Access to require MFA for all guest users accessing the SharePoint site. They also set a 90-day expiration policy for guest accounts using Azure AD Entitlement Management. Performance is excellent because authentication is federated; no additional infrastructure is needed. Common misconfiguration: forgetting to restrict guest access to only the specific SharePoint site, leading to guests being able to see other resources if not properly scoped.
Scenario 2: Vendor Access to Azure DevOps
A software company uses Azure DevOps and needs to grant temporary access to external contractors. They use B2B collaboration to invite contractors as guest users. The contractors authenticate using their personal Microsoft accounts. The software company uses Azure AD access reviews to automatically remove guest access after 30 days. They also use cross-tenant access settings to block B2B collaboration from certain high-risk domains. One issue that arises: if the contractor's email domain later becomes managed by an Entra ID tenant, the guest user must re-authenticate using that tenant, which can cause confusion if the guest was previously using OTP.
Scenario 3: M&A Integration with Temporary Access
During a merger, Company A needs to provide email and Teams access to employees of Company B before the identity systems are fully integrated. Company A invites Company B users as guests. They use cross-tenant access settings to trust Company B's MFA and device compliance, so Company B users don't need to re-enroll. After the merger is complete, the guest users are converted to internal users using a migration tool. The challenge: managing the lifecycle of thousands of guest accounts and ensuring access is revoked promptly when the migration is complete.
MS-900 Exam Focus on B2B Collaboration
The MS-900 exam tests your understanding of the difference between B2B and B2C, the guest user model, and the key capabilities of Entra External Identities. Objective 3.3 specifically asks you to "describe identity and access management capabilities," which includes external identities.
Common Wrong Answers: 1. "B2B collaboration requires external users to have a Microsoft Entra ID account in their own organization." This is false; external users can authenticate using any email address, including consumer identities like Gmail or Yahoo, using one-time passcodes. 2. "Guest users are created as members in the resource tenant." False; guest users have UserType of "Guest" and have limited directory permissions by default. They cannot enumerate users or groups unless explicitly granted. 3. "B2B collaboration is the same as B2C." False; B2C is for customer-facing apps with self-service sign-up, while B2B is for partner access with admin-initiated invitations. 4. "MFA for guest users must be handled by their home tenant." False; the resource tenant can enforce its own MFA policies on guest users, even if the home tenant does not require MFA.
Specific Numbers and Terms: - Default invitation expiration: 30 days. - Guest user type: "Guest" (not "Member"). - One-time passcode is enabled by default for unverified domains. - Cross-tenant access settings allow trust of MFA and device compliance from home tenants. - Entra ID Governance features like access reviews and entitlement management can be used to manage guest lifecycle.
Edge Cases: - If a guest user's email domain later becomes managed by Entra ID, the guest may need to re-authenticate. The OTP option is no longer available because the domain is now verified. - Guest users can be invited to access only specific applications without being added to the directory (limited preview feature called "direct federation" or SAML/WS-Fed IdP). - B2B collaboration supports Google federation (for Gmail addresses) but requires additional configuration.
How to Eliminate Wrong Answers: If a question mentions "self-service sign-up" or "customer identity," it's B2C, not B2B. If it mentions "invitation" or "partner access," it's B2B. Remember that guest users are not automatically members; they have limited permissions. Also, the resource tenant can always enforce its own Conditional Access policies, regardless of the home tenant's settings.
B2B collaboration allows external users to access resources in your tenant using their own identities; no separate credentials are needed.
Guest users have UserType 'Guest' and limited directory permissions by default.
One-time passcode authentication is enabled by default for email domains not associated with Azure AD or Microsoft accounts.
Invitations expire after 30 days if not redeemed (configurable via PowerShell).
Conditional Access policies can be applied to guest users, including requiring MFA from the resource tenant.
Cross-tenant access settings allow you to trust MFA and device compliance from specific partner tenants.
B2B is for partner access; B2C is for customer identity and access management.
These come up on the exam all the time. Here's how to tell them apart.
B2B Collaboration
Designed for partner and vendor access.
Invitations are admin-initiated or user-initiated (via self-service).
Guest users authenticate using their existing work, school, or personal accounts.
Guest users are represented as guest objects in the resource tenant.
No self-service sign-up; users are invited.
B2C (Azure AD B2C)
Designed for customer-facing applications.
Users sign up themselves via customizable policies.
Users can authenticate using social identities (Google, Facebook, etc.) or local accounts.
Users are stored in a separate directory (B2C tenant), not the resource tenant.
Self-service sign-up is the primary method.
Mistake
B2B collaboration requires the external user to have an Azure AD account.
Correct
External users can authenticate using any email address. If the domain is not managed by Azure AD, they can use a Microsoft account or a one-time passcode sent to their email.
Mistake
Guest users become members of the resource tenant.
Correct
Guest users have UserType 'Guest' and have restricted directory permissions. They cannot browse the tenant directory or see other users unless explicitly granted.
Mistake
MFA for guest users must be enforced by their home tenant.
Correct
The resource tenant can enforce its own MFA policies on guest users via Conditional Access, independent of the home tenant's MFA settings.
Mistake
B2B collaboration and B2C are interchangeable.
Correct
B2B is for partner/employee-like access with admin-controlled invitations. B2C is for customer-facing apps with self-service sign-up and social identity providers. They are separate services.
Mistake
Guest user accounts never expire.
Correct
Guest accounts do not expire automatically, but administrators can set expiration policies using Azure AD Entitlement Management or access reviews to automatically remove guests after a period.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
B2B (business-to-business) is for sharing resources with external partners, vendors, or contractors. Users are invited and authenticate using their existing work, school, or personal accounts. B2C (business-to-consumer) is for customer-facing applications where users sign up themselves using social or local accounts. B2C stores user profiles in a separate Azure AD B2C tenant, while B2B guest users are stored in your existing tenant.
Yes, the resource tenant can enforce MFA on guest users using Conditional Access policies. When a guest tries to access a resource, the resource tenant can require MFA regardless of the home tenant's policies. This is a common exam scenario: the resource tenant controls access.
If the domain is not managed by Azure AD and not a Microsoft account (like Gmail, Yahoo), Entra ID can send a one-time passcode (OTP) to the email address. The user enters the OTP to authenticate. This is enabled by default in External Identities settings.
The default expiration for a B2B invitation is 30 days. If the guest does not redeem the invitation within 30 days, the invitation link expires. This can be changed using PowerShell by setting the 'InvitedUserExpiration' property.
No, guest users only have access to resources they are explicitly granted access to (e.g., SharePoint sites, Teams, apps). By default, they cannot browse the directory or see other users. Access is controlled by assigning them to groups, apps, or SharePoint permissions.
Cross-tenant access settings allow you to configure inbound and outbound trust with specific external tenants. You can block or allow B2B collaboration from certain domains, and you can trust MFA and device compliance claims from the home tenant. This helps streamline access for trusted partners.
You can delete the guest user object from Entra ID, remove them from groups, or revoke their access to specific apps. You can also use Azure AD access reviews to automatically remove guests after a period. Revoking access is immediate.
You've just covered Microsoft Entra External Identities (B2B) — now see how well it sticks with free MS-900 practice questions. Full explanations included, no account needed.
Done with this chapter?