External Identities and B2B Collaboration

Azure AD External Identities is a set of capabilities that allow people outside your organization to access your apps and resources using their own identity. It comes in two flavors: B2B (business-to-business) collaboration and B2C (business-to-consumer) customer access. The AZ-104 exam focuses almost exclusively on B2B collaboration, where you invite external users from partner organizations into your Azure AD tenant as guests.

B2B collaboration is not federation in the traditional sense—there is no trust relationship established between two Azure AD tenants. Instead, each guest user is represented as a user object in your tenant with UserType set to "Guest." The guest authenticates against their home identity provider (IdP), and Azure AD issues a token for your tenant based on that authentication. This is sometimes called "bring your own identity" (BYOI).

The process involves two phases: invitation and redemption.

Invitation: An administrator or user with the Guest Inviter role sends an invitation email or direct link to the external user. The invitation contains a link pointing to https://login.microsoftonline.com/redeem?tenantID=...&invitationToken=... The invitation token is valid for 30 days by default (configurable via the InvitationRedeemTimeout property, range 1–30 days). The invited user does not need to have an existing Azure AD account; they can use any email address.

Redemption: When the user clicks the link, Azure AD checks the invitation token. If valid, the user is redirected to their home IdP for authentication. The user authenticates using credentials managed by their home organization (e.g., Microsoft account, Google, or corporate SAML/WS-Fed IdP). After successful authentication, Azure AD creates a guest user object in your tenant (if one doesn't already exist) and issues a token scoped to your tenant. The guest user object includes:

Once redeemed, the guest can access resources directly without clicking the invitation again, as long as the guest user object exists in your tenant.

Guest users have a restricted set of directory permissions by default. They can read own profile but cannot browse the tenant directory (unless you enable "Guest users have limited access" or assign the Directory Readers role). Key properties:

You can manage guest users via:

Guests can be assigned to: - Azure AD applications (SaaS apps, custom apps integrated with Azure AD) - Azure AD security groups (including dynamic groups—but dynamic groups for guests require special rules) - Azure RBAC roles (e.g., Contributor on a subscription)

Important: By default, guests can be added to Azure AD roles only if they have an Azure AD P1 or P2 license assigned to them in your tenant. This is a common exam trap—guests need a license for privileged roles.

B2B is for external partners who authenticate using their own organization's identity system. B2C is a separate service (Azure AD B2C) for customers who authenticate using social identities (Google, Facebook) or local accounts (email/password). B2C is a completely different Azure resource (Azure AD B2C tenant) and is not covered in the AZ-104 exam except to contrast it with B2B.

As of 2023, Azure AD supports cross-tenant access settings that replace the old B2B direct connect. You can configure: - Inbound access: Allow specific external tenants to access your apps via B2B collaboration or B2B direct connect. - Outbound access: Allow your users to access apps in external tenants. - Trust settings: Trust MFA, trusted devices, or compliant devices from the external tenant.

These settings are found under Azure AD > External Identities > Cross-tenant access settings. The exam may ask about the difference between B2B collaboration (invitation-based) and B2B direct connect (used for Teams shared channels).

Conditional Access policies can be applied to guest users by targeting the "External users" exclusion or by including "Guest or external users" in the policy scope. However, to enforce MFA for guests, you must either:

If you trust MFA from the home tenant, the guest's home tenant must have MFA enabled and the user must have completed MFA there. This is a common exam scenario: you can avoid assigning licenses to guests by trusting their home tenant's MFA.

To maintain security and compliance, Azure AD Entitlement Management and Access Reviews can be used to periodically review guest access. Access reviews can be configured to expire guest accounts after a set number of days (e.g., 30, 60, 90). This is a key exam point—guests are often overprovisioned and access reviews help automate cleanup.

Invite a guest using Azure CLI:

az ad user create --display-name "Jane Doe" --user-principal-name janedoe#EXT#@contoso.onmicrosoft.com --user-type Guest --mail-nickname janedoe

Invite a guest using Microsoft Graph (PowerShell):

New-MgInvitation -InvitedUserEmailAddress "jane@partner.com" -InviteRedirectUrl "https://myapps.microsoft.com" -SendInvitationMessage:$true

List guest users:

az ad user list --query "[?userType=='Guest']"

Convert guest to member:

Set-AzureADUser -ObjectId <objectid> -UserType Member

(This changes the user type but does not change authentication method.)

A mid-size company, Contoso, uses Salesforce and Dynamics 365 integrated with Azure AD. They need to give their external accounting firm access to specific Salesforce records. The accounting firm uses Office 365. Contoso's admin invites the accounting firm's users as guests via Azure AD B2B. They assign the guests to an Azure AD security group that is synchronized to Salesforce. The accounting firm's users authenticate with their own Office 365 credentials. Contoso does not need to manage passwords or create local accounts. A common mistake: the admin forgets to assign the guests to the group, so they can authenticate but see no data. Another pitfall: the admin enables Conditional Access requiring MFA but does not trust the home tenant's MFA, forcing guests to register for MFA in Contoso's tenant (which requires a license). The correct approach is to configure cross-tenant access settings to trust MFA from the partner tenant, avoiding license costs. Performance is not an issue; B2B authentication adds minimal latency (a few hundred milliseconds). The main concern is guest account sprawl—without access reviews, guest accounts accumulate. Contoso sets up quarterly access reviews to remove inactive guests.

A large enterprise, Fabrikam, uses Azure DevOps and an internal web app hosted on Azure App Service. External contractors need Contributor access to a specific resource group for deployment. Fabrikam invites the contractors as guests and assigns them the Contributor RBAC role on the resource group. The contractors authenticate using their personal Microsoft accounts. The challenge: Fabrikam wants to enforce MFA for all external access. They configure a Conditional Access policy targeting "Guest or external users" that requires MFA. Since the contractors use Microsoft accounts (which support MFA), and Fabrikam trusts MFA from Microsoft accounts, no extra license is needed. However, if the contractors used a corporate SAML IdP that does not support MFA, Fabrikam would need to assign Azure AD P1 licenses to the guests to enforce MFA with their own tenant. This scenario highlights the importance of understanding MFA trust and licensing. A common error: the admin assigns the Contributor role at the subscription level instead of the resource group, giving the contractors broader access than intended.

An organization uses Teams with external partners via shared channels. This feature uses B2B direct connect, not B2B collaboration. The admin must configure cross-tenant access settings to allow B2B direct connect with the partner's tenant. The partner also needs to configure outbound settings. Unlike B2B collaboration, B2B direct connect does not create guest user objects in the tenant—the external user remains external and is not visible in Azure AD Users. This is a common exam trap: the exam may ask which method to use for Teams shared channels. The answer is B2B direct connect, not B2B collaboration. If misconfigured, users may see a "no access" error. The admin must ensure both tenants have the correct inbound and outbound settings.