Domainless SAML federation: let partners sign in with their own IdP, whatever their email domain

SAML/WS-Fed IdP federation lets your tenant trust a partner's own identity provider. Their users redeem your B2B invitations and sign in with the accounts they already have, so you don't create new credentials or a Microsoft account for them. Microsoft redirects them to their IdP, then brings them back to your tenant once they've signed in.

It has always had one awkward rule: the domain in the guest's email address had to match a domain configured on the IdP. That's fine when everyone at the partner is @fabrikam.com. It breaks for contractors, freelancers and partners whose users have addresses on another domain, or even on gmail.com. Domainless SAML IdP federation, now generally available for workforce tenants, removes that check.

What goes wrong without it

With domain-based federation, Entra compares the email claim in the SAML assertion with the domains on the IdP configuration. If they don't match, sign-in fails with:

AADSTS5000819: SAML Assertion is invalid. Email address claim is missing or does not match domain from an external realm.

You can look that up in the AADSTS error lookup, and paste the failing response into the SAML decoder to see exactly which email address the partner's IdP sent.

How domainless federation works

With the Domainless option ticked, Entra no longer looks at the user's email domain. It routes the authentication request to the IdP by its Issuer URI. When you invite a guest, you add a domain_hint parameter to the invitation's redirect URL, set to that Issuer URI. When they redeem, Entra uses it to send them to the right IdP.

After redemption, Entra updates the guest's user object with the external IdP association. From then on they can sign in to your apps directly, without the hint.

What the partner's IdP needs to send

The SAML requirements are the same as for domain-based federation. For a workforce tenant:

Microsoft recommends the tenant-specific audience for new federations. Existing federations that use the global urn:federation:MicrosoftOnline value keep working, but a new federation stops working if the IdP expects the global issuer URL. If the partner uses WS-Fed, Microsoft has only tested AD FS and Shibboleth.

Set it up

You'll need the External Identity Provider Administrator role or higher.

1. In the Microsoft Entra admin center, go to Entra ID > External Identities > All identity providers.
2. On the Custom tab, select Add new > SAML/WS-Fed.
3. Enter a display name, choose SAML, and tick Domainless.
4. Either parse the partner's metadata file, or enter the Issuer URI, passive authentication endpoint (HTTPS only) and signing certificate by hand. Add the Metadata URL too: with it, Entra can renew the signing certificate automatically. Without it, you'll have to update the certificate yourself whenever it changes.
5. Save, then wait 5 to 10 minutes before anyone tries to redeem an invitation.
6. Under Cross-tenant access settings, open the redemption order and move SAML/WS-Fed identity providers to the top of the primary identity providers list, so the federated IdP is tried first.

To switch an existing domain-based IdP over, open its domains pane, tick Domainless and select Done.

Invite the guest

Invite them as normal (Users > All users > New user > Invite external user). Their email doesn't need to match any domain. The important part is the redirect URL: add a domain_hint whose value matches the Issuer URI on your IdP configuration exactly. Copy it straight from the configuration in the admin center rather than typing it.

Limits to know about

• One domainless IdP per tenant. Microsoft's documentation says only one wildcard IdP can be configured per tenant, so choose the partner that needs it most. Others stay on domain-based federation.
• Known issue: if you type an invalid domain name into an IdP configuration, the configuration can be deleted, even if you hadn't saved it. Double-check before you add domains.
• Removing federation locks guests out. Guests who already redeemed can't sign in once the configuration is deleted. You'll need to reset their redemption status to give them access again.

Checklist

• Partner IdP sends a persistent NameID and the emailaddress claim
• Audience set to your tenant-specific endpoint
• Domainless ticked, and the metadata URL added so certificates renew
• SAML/WS-Fed moved to the top of the redemption order
• Invitations sent with domain_hint set to the exact Issuer URI
• Test with one guest before inviting the rest