Can’t login to Office365 using Single Sign-On if UPN uses sub-domain

Scenario:

You have federated your domain with Office 365 to provide Single Sign-On for your users

Problem

Some or all of your users cannot sign into Office 365.  Users are presented with the following error:

SSO1

Looking closer at the description you see the following:

AADSTS50107: Requested federation realm object ‘http://subdomain.domain.com/adfs/services/trust/’ does not exist.

Cause:

  • The domain names used for UPN suffices include the top level domain (e.g. contoso.com) and sub-domains (sales.contoso.com)
  • You have used the –SupportMultipleDomain switch to federate the top level domain (e.g. contoso.com) and subdomain (sales.contoso.com)
    1. Convert-MsolDomainToFederated -DomainName <domain_fqdn> -SupportMultipleDomain

Reason

The SupportMultipleDomainswitch is not required when you have a single top level domain and one or more sub domains.  For example if the domains used for upn suffixes are @sales.contoso.com and @contoso.com and the top level domain (contoso.com in this case) was added first and federated then you don’t need to use the “SupportMultipleDomain” switch.  This is because these sub domains are effectively managed within the scope of the parent

Solution

Modify the third claim rule on ADFS as follows:

Open ADFS Management

SSO2

Expand Trust Relationships > Relaying Party Trusts

Right click “Microsoft Office 365 Identity Platform” and choose “Edit Claims Rules”

SSO3

Highlight the 3rd Claim rule and choose “Edit Rule”

SSO4

Modify the claim rule with the following

c:[Type
== “http://schemas.xmlsoap.org/claims/UPN“]=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid“, Value = regexreplace(c.Value, “^((.*)([.|@]))?(?<domain>[^.]*.(com|net|co|org)(.\w\w)?)$”, “http://${domain}/adfs/services/trust/“));

SSO5

Ref:  SupportMultipleDomain switch, when managing SSO to Office 365

13 thoughts on “Can’t login to Office365 using Single Sign-On if UPN uses sub-domain

  1. Hi Shane, great help here. We just implemented ADFS for Office 365 yesterday and because I chose mult-domain support during setup I hit this same issue. We do have a subdomain (as well as split DNS) tenant in Office 365. We handle it in AD with a UPN suffix.

    Using your steps I was able to get past the realm object does not exist for the subdomain, but now I get the same error/page stating that the account realm object itself doesn’t exist. Office 365 reports that the mailbox is Synced with Active Directory. Any ideas?

  2. Another instance where I’ve seen that this will occur is when you DO have multiple federated domains, however the claims rule did not help (and with the latest Office 365 metadata when you federate a domain is unnecessary). Simply connect to Azure AD Powershell, and run Update-MSOLFederatedDomain -DomainName . It was as simple as this and a refresh of the page to get logged into O365.

  3. Pingback: AADSTS50107: Requested realm object ‘username@domain.com’ does not exist. – Scriptovic

  4. “Highlight the 3rd Claim rule”? That seems so vague seeing as none of the three in your screenshot have names, while we have 15 rules all of which have names! 🙂

    Gold old Microsoft…

  5. Thank you Shane! Finally a post about this issue that was correct and solved my problem! Interesting that the Issuer ID Claim Rule automatically added by Microsoft doesn’t take sub-domains into account.

Leave a Reply

Your email address will not be published. Required fields are marked *