Cross-Tenant Access Settings

Cross-tenant access settings are policies in Microsoft Entra ID that govern authentication and resource access between two Azure AD tenants. They replace the older, less granular approach of allowing or blocking all B2B collaboration with a tenant. With cross-tenant access settings, you can define separate controls for inbound and outbound access, apply conditional access policies to external users, and enable B2B direct connect for Teams Connect shared channels.

These settings are part of the External Identities feature set and are configured under Azure Active Directory > External Identities > Cross-tenant access settings. The settings apply at the organizational level (whole tenant) or for specific external tenants (partner tenants).

Before cross-tenant access settings, organizations had only a binary choice: allow or block B2B collaboration invitations from all external tenants. This was coarse and insecure. For example, if you allowed all B2B invitations, users from a compromised tenant could potentially access your resources. Cross-tenant access settings provide granular control:

When a user from Tenant B tries to access a resource in Tenant A, the following flow occurs:

- Default settings: Initially, all B2B collaboration is allowed (both inbound and outbound). B2B direct connect is blocked by default. You can change the default to block all or allow specific tenants. - Inbound settings: - B2B collaboration: Allow or block invitations to users from specific tenants. - B2B direct connect: Allow or block Teams Connect shared channels with specific tenants. - Trust settings: Checkboxes to trust MFA, compliant devices, and hybrid Azure AD joined devices from the external tenant. - Outbound settings: - B2B collaboration: Allow or block your users from being invited to specific tenants. - B2B direct connect: Allow or block your users from accessing shared channels in specific tenants. - Automatic redemption: When enabled, users from the external tenant do not need to accept a consent prompt. This is useful for seamless collaboration but reduces user awareness. - Conditional Access for external users: You can target conditional access policies to external users by using the "External users" or "Guest or external users" user type in the policy assignment.

To configure cross-tenant access settings, you can use the Azure portal or Microsoft Graph API. Below is a PowerShell example using the Microsoft Graph Beta module:

Connect-MgGraph -Scopes "Policy.ReadWrite.CrossTenantAccess"

# Create a cross-tenant access policy for a specific tenant
$params = @{
    displayName = "Contoso Access Policy"
    tenantId = "contoso.com"
    inboundTrust = @{
        isMfaAccepted = $true
        isCompliantDeviceAccepted = $true
        isHybridAzureADJoinedDeviceAccepted = $false
    }
    b2bCollaborationInbound = @{
        usersAndGroups = @{
            accessType = "allowed"
            targetType = "user"
            targetId = "All"
        }
    }
}
New-MgPolicyCrossTenantAccessPolicyPartnerDefault -BodyParameter $params

To verify cross-tenant access settings, use the Azure portal: navigate to Azure AD > External Identities > Cross-tenant access settings. You can see the default settings and any organizational-level policies. For a specific tenant, view the partner configuration. You can also use Microsoft Graph to list policies:

Get-MgPolicyCrossTenantAccessPolicyPartnerDefault

Or via Graph API:

GET https://graph.microsoft.com/beta/policies/crossTenantAccessPolicy/partners

A global company with 50,000 employees acquires a smaller company with its own Azure AD tenant. The acquisition company needs to collaborate on projects while maintaining separate tenants during the integration period. The IT team configures cross-tenant access settings to allow inbound B2B collaboration from the acquired tenant, but only for specific groups. They enable trust settings for MFA and compliant devices because the acquired company uses Intune. They also enable automatic redemption to avoid consent prompts. Performance is fine for up to a few thousand guest users, but sign-in logs become voluminous. The main issue is that if the acquired company's tenant is compromised, the trust settings could allow compromised devices to access resources. To mitigate, the parent company applies conditional access policies that require additional controls for external users.

A healthcare organization uses Teams Connect shared channels to collaborate with external labs and pharmacies. They need B2B direct connect enabled. They configure cross-tenant access settings to allow B2B direct connect only with specific partner tenants. For each partner, they trust the partner's MFA but not their device compliance (because they cannot enforce the partner's device policies). They also set up conditional access policies to require MFA for all external users, but since they trust the partner's MFA, the policy is satisfied. A common mistake is forgetting to enable B2B direct connect on both sides; if only one tenant enables it, the shared channel fails. Also, if a partner changes their tenant ID (e.g., due to domain change), the policy breaks and must be updated.

A SaaS company provides a multi-tenant application that customers access via B2B collaboration. The SaaS company's tenant invites users from customer tenants. They configure cross-tenant access settings to allow inbound B2B collaboration from all tenants (default allow) but block specific tenants known for abuse. They do not enable trust settings because customers have varying security postures. Instead, they apply conditional access policies that require MFA from external users. The challenge is managing a growing list of blocked tenants. They use automation via Microsoft Graph to periodically update the block list. If the default is accidentally changed to block all, all customers lose access immediately, so they use Azure policy to audit changes to cross-tenant access settings.