Microsoft Entra External ID Security

Microsoft Entra External ID (formerly known as Azure AD External Identities) is a set of capabilities that allow organizations to securely interact with users outside their tenant. It encompasses two primary scenarios: Business-to-Business (B2B) collaboration and Business-to-Customer (B2C) identity management. For AZ-500, the focus is heavily on B2B collaboration security, but B2C concepts also appear.

B2B Collaboration enables you to invite external users (partners, vendors, contractors) to access your organization's applications as 'guest' users. These guests authenticate using their own identity provider (e.g., Microsoft, Google, or any SAML/WS-Fed IdP) and are represented in your directory as user objects with UserType = 'Guest'. B2B collaboration is the primary mechanism for sharing applications and resources with external partners without managing their credentials.

B2C Identity Management is a separate Azure service (Azure AD B2C) for customer-facing applications. It allows customers to sign up and sign in using social identities (Google, Facebook) or enterprise identities, with customizable user journeys. While B2C is a distinct product, AZ-500 may test its security configuration, such as token settings and identity providers.

When an external user is invited via B2B collaboration, the following occurs:

To configure External ID settings via PowerShell or Azure CLI:

Azure AD PowerShell (AzureAD module)

# Get current external collaboration settings
Get-AzureADDirectorySetting | Where-Object {$_.DisplayName -eq "Group.Unified"}

# Update settings to restrict guest invitations to admins
$setting = Get-AzureADDirectorySetting | Where-Object {$_.DisplayName -eq "Group.Unified"}
$setting.Values["AllowToAddGuests"] = $false
Set-AzureADDirectorySetting -Id $setting.Id -Values $setting.Values

Microsoft Graph PowerShell SDK

# Get cross-tenant access policy
Get-MgPolicyCrossTenantAccessPolicyDefault

# Update default inbound trust settings
$params = @{
    inboundTrust = @{
        IsMfaAccepted = $true
        IsCompliantDeviceAccepted = $false
        IsHybridAzureADJoinedDeviceAccepted = $false
    }
}
Update-MgPolicyCrossTenantAccessPolicyDefault -BodyParameter $params

Azure CLI

# Get Azure AD directory settings
az rest --method GET --uri "https://graph.microsoft.com/v1.0/policies/crossTenantAccessPolicy/default"

AZ-500 expects you to know the differences between B2B and B2C, how to configure cross-tenant access settings, and how to secure guest access with Conditional Access. Be familiar with the default settings and common misconfigurations. The exam often tests scenarios where an admin needs to allow external users to authenticate with their own credentials while maintaining security policies.

A large manufacturing company, Fabrikam, collaborates with dozens of suppliers. Each supplier uses their own Azure AD tenant. Fabrikam wants to allow supplier employees to access a shared procurement application. Previously, Fabrikam created local user accounts for each supplier employee, leading to password fatigue and security risks. They migrated to Entra External ID B2B collaboration. They configured cross-tenant access settings to trust MFA from the supplier tenants, so supplier employees use their own MFA. They also created a Conditional Access policy that requires device compliance for the procurement app. However, they discovered that not all suppliers enforce device compliance. To handle this, they set the policy to require MFA as a fallback. Performance is seamless — users authenticate via their home tenant and are redirected back. Common misconfiguration: forgetting to update cross-tenant access settings when a new supplier is onboarded, causing access failures. Solution: Use automated scripts via Microsoft Graph to add new partner tenants to the allowed list.

A retail company, Contoso, built a customer loyalty app using Azure AD B2C. They configured sign-up with email, Google, and Facebook. They needed to collect customer consent for marketing emails. They used custom policies to add a consent screen during sign-up. Security requirements included blocking sign-ins from anonymous IP addresses and requiring email verification. They used Identity Protection for B2C to detect risky sign-ins. However, they faced a challenge: customers frequently forgot their passwords. They implemented self-service password reset (SSPR) using email verification. Scale: They handle 100,000 active users with no performance issues. Common issue: Misconfigured token lifetimes caused users to be logged out too frequently. They set session token lifetime to 24 hours and refresh token lifetime to 14 days. Exam note: B2C token settings are configured in the 'Token, session, and SSO configuration' blade.

A consulting firm, ProConsult, frequently brings in external consultants for projects. Each consultant needs access to specific project sites and applications. Previously, admins manually created guest accounts and added them to groups. This led to orphaned accounts. They implemented Entitlement Management with access packages. Each project has an access package containing the relevant SharePoint site and a Teams group. Consultants request access via the My Access portal, which triggers approval from the project manager. Access is time-limited to the project duration (e.g., 6 months). After the project ends, access automatically expires. They also set up quarterly access reviews to catch any oversight. This reduced administrative overhead by 80%. Common pitfall: Not configuring auto-expiration, leading to indefinite access. Solution: Always set an expiration date in the access package policy.