Error: requested federation realm object does not exist

Arjan Cornelissen
active-directory, adfs, office-365
Page content

A few weeks ago we got a few users telling us that they were not able to sign in to Office 365 with an error message “AADSTS50107: Requested federation realm object does not exist”. After searching the internet I only found errors with a whole domain not able to sign in because it was a subdomain and that was not recognized by Office 365. The affected users where able to sign in to other applications on ADFS and other users where able to sign in to Office 365 with that same domain name. This was a strange issue because the error would suggest that everybody should have an issue and not a few users on the domain.

After trying to update the domain settings in Office 365 with PowerShell “Update-MsolFederatedDomain” and check for any other issue or configuration we could not find a thing.

This now was something we need Microsoft for and so we created a case with Microsoft.

The case

The case we created by Microsoft was that a few users were not able to login to Office 365 with the error “AADSTS50107: Requested federation realm object does not exist”. Microsoft then started investigating all parts in the login chain

  • Azure AD configuration
  • Office 365 Settings
  • Domain settings
  • AD configuration
  • ADFS configuration
  • The specific AD user in our on premises AD
  • Fiddler Traces

We also had to run several diagnostic tools and commands to check what happened during the login of the specific users.

After a lot of trying to find out where the issue was and one solution we rejected from Microsoft they found the real problem.

Rejected solution

The first solution they gave us was to update the relying party trust of Office 365 In ADFS. This update would change the domain part that is responsible for the issuerid. This update is suggested for this issue multiple times on the internet if the problem is there for everybody on that domain and mainly when you have subdomains.

When I saw this proposed solution I knew that this could also mess up a lot of other domains that we have and are subdomains. We asked for the impact of this solution and Microsoft said that this could have some side effects which we did not want to have. Microsoft then searched future during a remote session on our ADFS and AD users and found the real issue.

The real solution

After digging future Microsoft found the solution in the way ADFS is identifying members of the “Domain Computers” security group. This group ends in every AD with 515.

To get this fixed we needed to update the regex to search for a more specific string than 515. We changed it in -515 witch solved our issue.

Rule name: “Issue account type for domain joined computers” Rule value: c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ “-515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”] => issue(Type = “http://schemas.microsoft.com/ws/2012/01/accounttype", Value = “DJ”);

I hope that Microsoft will update this within the new update for AAD Connect sync client, for now we know that when we update the sync client we need to update this claim rule until Microsoft updates this in the AAD Connect sync client