JUMP TO SECTIONChoose a lesson section
Trust, identity provisioning and sign-in are separate systems.
An external employee can pass MFA at their home tenant yet still be blocked by outbound policy. A cross-tenant synchronization job can create a B2B account even when the target app isn't authorized. And a federated Microsoft 365 domain can have perfectly healthy sign-ins while other AD FS-dependent applications still require federation. Learn to identify the responsible tenant and resource at every boundary.
Same identity. Different control planes.
Cross-tenant access settings
Which tenant allows access in each direction?The user's home tenant controls outbound access to another organization's apps. The resource tenant controls inbound access to its apps, and separately decides whether to trust partner MFA/device claims. Partner-specific settings override tenant defaults.
VALIDATE: Check both directions, the target app and user scope, partner organization overrides and Conditional Access results.Cross-tenant synchronization
Where does the B2B identity come from?Cross-tenant sync pushes eligible internal members from the source tenant to a target as B2B accounts. The target permits inbound sync, the source owns provisioning assignments/mappings, and automatic redemption needs matching settings in both tenants.
VALIDATE: Validate source provisioning scope, target inbound permission, auto-redemption, provisioning logs and deprovisioning behavior.SAML / WS-Fed federation
Who authenticates users without Entra home accounts?External identity provider federation lets eligible partners using third-party SAML/WS-Fed providers sign in with those credentials. It differs from native Entra-to-Entra B2B collaboration; the latter doesn't call for direct SAML federation between Microsoft tenants.
VALIDATE: Review issuer, tenant-specific audience, signed claims, certificate, DNS if needed and invited user redemption behavior.AD FS migration
Can the federated domain safely become managed?Staged Rollout lets approved pilot groups try cloud authentication, typically password hash synchronization, before converting a domain away from AD FS. Existing relying party apps, claim rules, certificates and rollback must be inventoried.
VALIDATE: Test users, legacy apps, token/claims behavior, cutover state and a documented decommission plan.Entra Connect Health
What failed between AD DS and the cloud?Connect Health for Sync adds server/agent alerts, import/export latency and object-level error reporting for Microsoft Entra Connect Sync. It is distinct from the provisioning logs for a cross-tenant B2B job.
VALIDATE: Verify Sync V2, agent freshness, outbound telemetry, connector run errors, conflicting UPNs and source objects.The home tenant can say no. So can the resource tenant.
For Entra-to-Entra collaboration, the partner's outbound policy governs whether its users may access Northstar. Northstar's inbound policy governs whether those partner users may access Northstar's resources. Your app assignment, invitation status and Conditional Access evaluation add other decisions. An inbound MFA trust rule accepts a supported home-tenant claim; it doesn't substitute for app authorization.
B2B collaboration
Default: Available by default for other Entra organizations in the same cloud, subject to policies and app permissions
Check inbound and outbound scopes, invitation/redemption, resource app access and Conditional Access.B2B direct connect
Default: Blocked by default
Both organizations must configure mutually permitted settings for supported scenarios.Cross-tenant synchronization
Default: No users or groups synchronized by default
Target inbound sync permission, aligned auto-redemption, source provisioning job, scoped identities and mappings.SAML/WS-Fed external IdP
Default: Only if federation is configured and applicable
Verify partner IdP endpoints, tenanted issuer/audience, certificates, claims and existing redemption state.Start with the identity's home tenant
For an employee from a partner Entra organization, their home tenant can block outbound B2B collaboration by user, group or target application. Your resource tenant cannot override that partner block.
Inspect your resource tenant inbound policy
Determine whether the named partner, target app and the external user/group are allowed. Partner-specific settings take precedence over defaults; B2B direct connect has different default and mutual requirements.
Choose trust claims intentionally
Inbound trust can accept partner MFA, compliant device or hybrid-joined device signals where supported. Trusting MFA does not automatically trust devices or grant authorization. Evaluate your own Conditional Access and resource permissions.
Test and retain the evidence
Correlate resource sign-in and Conditional Access logs, outbound and inbound rules, tenant-specific exceptions, app assignment and actual user behavior. Avoid a broad default allow merely to repair one partner.
Inbound partner MFA trust is independent of compliant/hybrid-joined device claims and does not bypass authorization. Likewise, B2B direct connect remains blocked by default until both organizations allow a supported scenario. Verify the exact partner and resource—not only the tenant default.
Source pushes users. Target permits the relationship.
Cross-tenant sync uses Microsoft's provisioning service for eligible internal members in the source tenant. The job and scope live at the source. The target allows inbound synchronization; both sides align automatic redemption. It provisions target B2B users, not a second independent set of employee passwords, and it doesn't automatically clone every guest already in the source tenant.
Approve the trust and identity scope
Choose the approved source and target tenants, eligible internal member users and resource applications. Standard cross-tenant sync doesn't simply copy guests already invited into the source.
Target tenant: allow inbound synchronization
Configure the partner organization in cross-tenant access settings and permit inbound user synchronization (and supported groups if required). Restrict by partner rather than enabling a universal allow.
Both tenants: align automatic redemption
The source enables outbound automatic redemption and target enables inbound automatic redemption. Missing either setting can cause CrossTenantSyncPolicyCheckFailure during connection testing.
Source tenant: create the provisioning configuration
Create the cross-tenant sync job in the source; test connection, assign approved users/groups, review mapping and scoping rules, then run provision on demand for a small test group.
Monitor the complete lifecycle
Review provisioning logs and target identity/access. Remove a pilot user from scope to test configured leave/deprovision behavior before scaling up. Disable or delete outcomes depend on settings.
A provisioned target B2B object still needs app assignment and allowed sign-in policy. A successful pilot also needs a tested leave/deprovision scenario; do not assume the target user is always deleted when the source loses scope.
When the partner isn't using Microsoft Entra.
For eligible partners using a third-party SAML or WS-Fed identity provider, Microsoft Entra External ID can federate sign-in so users authenticate with their existing IdP. This is not how two Entra workforce tenants should implement ordinary B2B collaboration. Supported federation requires matching issuer, tenant-specific audience, endpoint, signing certificates and required claims.
Select the right collaboration model
Use native Microsoft Entra-to-Entra B2B for partners already using Entra. For eligible organizations with third-party SAML or WS-Fed IdPs, consider direct external IdP federation.
Verify partner metadata and protocol
The external IdP must correctly identify its issuer, sign assertions with trusted certificates and provide required claims. New trusts use tenant-specific audience/issuer expectations; check the published Microsoft tables.
Configure B2B federation and redemption
Configure the external IdP through Entra External Identities and coordinate partner domain verification or DNS as applicable. Where supported, set inbound redemption order to prefer federation.
Validate new and previously redeemed users
Test a newly invited pilot guest and an existing guest separately. Guests who already used email one-time passcode can retain that method until redemption status is intentionally reset.
Enabling a new federation configuration doesn't necessarily alter a guest who already redeemed their invitation with an email one-time passcode. Evaluate targeted redemption reset, consent and user communication if you intend to change the sign-in method.
Don't decommission the old sign-in system after one successful pilot.
AD FS can be the authentication endpoint for Microsoft 365 domains and unrelated relying-party applications. Migrating a federated workforce domain to managed cloud sign-in requires discovery of each dependency. Microsoft generally recommends password hash synchronization (PHS) for cloud authentication; temporary Staged Rollout lets approved pilot groups test the proposed experience before domain cutover.
Inventory relying parties and claims
Catalog AD FS-dependent SaaS/internal apps, customized claim rules, WS-Fed/SAML endpoints, certificates, MFA integrations and owners. Identify apps that will not move automatically when Microsoft 365 domain sign-in changes.
Prepare cloud authentication
Compare password hash synchronization (Microsoft's general recommendation) with pass-through authentication. Verify Entra Connect Sync health, UPN alignment, password synchronization and licensing/role requirements.
Pilot with Staged Rollout
Use a temporary selected group to evaluate cloud sign-in, Conditional Access and MFA while the domain remains federated. Observe extra interactive sign-ins during state transitions and test previously supported SSO flows.
Plan and execute a controlled domain cutover
After evidence and change approval, convert the eligible federated domain to managed authentication, test representative applications and users, and maintain an executable rollback for unexpected claim or sign-in issues.
Retire remaining AD FS dependencies deliberately
Only decommission AD FS and related proxy/monitoring infrastructure after all relying parties, service endpoints, token validation and break-glass workflows are validated and their owners accept the change.
Adding or removing a pilot user may require an additional interactive sign-in to switch the authentication experience. Domain federation remains in place until deliberately converted; production AD FS relying parties and claim transformations must be migrated or retired separately.
The object is missing. Which sync engine failed?
Microsoft Entra Connect Health for Sync observes supported Entra Connect Sync servers and the synchronization engine between AD DS and Microsoft Entra ID. It relies on an installed Health agent and supported Sync V2. Use alert history, telemetry freshness, Sync Insight latency, connector errors and object-level conflict reports. A cross-tenant B2B provisioning job is separate and has its own logs.
Server health and alerts
Is the Connect Health agent installed on each eligible Entra Connect Sync server, reporting fresh health data?
Agents, Sync v2, supported Windows Server, egress/connectivity and service healthSynchronization latency
Which import, sync or export step has become slow or stalled?
Sync Insight latency and object-change trends; compare connector run detailsDuplicate attribute
Are a UPN or proxyAddresses value conflicting with another directory object?
Object-level error details and source/cloud identifiers, not random object deletionData validation
Does a source attribute contain an unsupported value or length?
Review reported attribute, authoritative AD DS object and approved correctionFederated domain change
Is the object associated with a changed federation state or UPN domain?
Correlate domain cutover state and Entra Connect errorsCross-tenant provisioning
Is the failure in a separate B2B provisioning job, not the Entra Connect Sync engine?
Use cross-tenant provisioning logs and job scoping; do not expect Connect Health to diagnose itA stale agent, blocked egress or unsupported/older Sync installation can make reports look quiet. Even custom filtering can limit uploaded error events. Validate the health feed before treating an empty dashboard as proof that directory synchronization is healthy.
Which tenant has the missing switch?
Toggle the prerequisite gates for a source-to-target sync pilot. Then solve four evidence-based incidents spanning partner access, provisioning, external federation and hybrid directory health.
Will the cross-tenant sync connection pass its policy checks?
Toggle the approval gates for a fictional pilot. All three must be configured in the correct tenant before validating the provisioning job.
An expected policy check can fail until the target permits incoming sync and both organizations align automatic redemption. This simulator does not contact either tenant.
This checks prerequisite policy gates only. It doesn't simulate a working authentication protocol, directory permissions, target application authorization, or a live provisioning operation.
Four cross-boundary investigations.
Choose a ticket and identify exactly which tenant or service can make the next decision.
A partner guest can sign in, but the app still denies access.
EVIDENCE FROM THE TICKET
- Northstar's application assignment includes the invited partner user.
- The partner home tenant has an organization-specific outbound block.
- Northstar is evaluating whether to trust the partner's MFA claims.
Verify current supported behavior before changing tenant trust.
Cross-tenant sync, cloud policies, external federation and staged rollout have licensing, permission and client requirements. Confirm these against current Microsoft documentation before production deployment.
The user has access. But who created the identity?
Practice 020 adds 16 identity trust cards, 16 explained questions and two multi-step Northstar cross-tenant and hybrid incidents.