Domainless SAML external IDP does not work with personal or business MS domains

Peter Clijsters 0 Reputation points
2026-09-18T15:26:15.9966667+00:00

The whole idea behind domainless SAML IDP federation is that inviting an IDP user with whatever email domain is OK. However, if the federated user has a personal or business MS email address this does not seem to work correctly.

Setup:

  • I run an open source SAML IDP. Users create an account and can use any email address to do so.
  • Some of these users need access to some apps in a workforce tenant.
  • The IDP is configured as a SAML/WS-Fed identity providers in the workforce tenant with the domainless option
  • The SAML/WS-Fed Identity Providers is the first in the redemption order
  • Inviting, redeeming and collaborating with a federated user that has a non-MS email domain works fine

Problem:

  • When a user in the SAML IDP uses an email address with a personal MS domain (like live.com, hotmail.com, outlook.com) and is invited for the workforce tenant, the redemption flow goes like this:
        1. login with the personal MS account
        2. login with my SAML IDP
        3. error: "AADSTS50020: User account from identity provider does not exist in tenant"
        4. despite this error, the user is created successfully
        5. subsequent logins also do the double logins
  • When a user in the SAML IDP uses an email address that is managed by another Entra ID tenant (like contoso.com) and is invited for the workforce tenant, the redemption flow goes like this
      1. login with his corporate MS account
      2. login with my SAML IDP
      3. error: "AADSTS50020: User account from identity provider does not exist in tenant"
      4. despite this error, the user is created successfully
      5. subsequent logins also do the double logins

The expected behaviour is that the user would only login with the SAML IDP, not with the personal or corporate managed MS accounts. This seems to be an issue with the new domainless SAML IDP federation feature.

Any insights or help is greatly appreciated!

Microsoft Security | Microsoft Entra | Microsoft Entra External ID
0 comments

1 answer

Sort by: Oldest
Most helpful Newest Oldest
  1. Levi Cornwell 255 Reputation points
    2026-09-18T15:58:52.1033333+00:00

    The domainless configuration itself is supposed to allow the SAML IdP to authenticate users regardless of their email domain. Microsoft’s documentation says the email domain is not used for routing when domainless federation is enabled, and the IdP is selected based on the Issuer URI instead.

    What stands out here is that the flow is still trying the Microsoft personal/Entra account first and then returning AADSTS50020. Since the same SAML IdP works with non-Microsoft email domains, I’d check whether the invitation redemption URL is using the required domain_hint for the domainless IdP. Microsoft specifically documents using domain_hint to ensure the invitation is routed to the correct federated IdP.

    I’d also test a completely new guest invitation using the documented domainless redemption flow, rather than testing an account that has already gone through a failed redemption. If it still produces AADSTS50020 for both @outlook.com and another Entra-managed domain, that sounds worth reporting to Microsoft as a possible issue with the new domainless federation flow, especially since the guest object is ultimately created despite the error.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.