AADSTS 50107 Realm Object does not exist

Hello,

I recently came across an issue with an ADFS farm when adding a new federated domain. I’ve added the domain with the MSOnline PowerShell module to perform that modification, from the ADFS primary server:

Convert-MsolDomainToFederated -DomainName itfordummies.com -SupportMultipleDomain 

I’m not sure really why for now (maybe my old version of MSOnline PowerShell module), but, this added the domain, but failed to update the ADFS farm to take that new federated domain into its configuration. The domain was listed as federated in Azure AD, but not present in the ADFS claim rule “Computer not domain joined”. The regular expression was not updated and still reference only the old federated domains.

That resulted with an error at login in Azure AD while using the new domain :

AADSTS 50107 Realm Object does not exist

I could not use my newly federated domain to access my Office 365 applications, but the old ones still work. I can also authenticate to my ADFS farm with the tests pages.

There is a few different ways to fix this issue.

Federate an Azure AD domain

You can use the AADConnect wizard to add the federated domain again, it will refresh the relying party trust for Office 365 and include the domain into the claims rule.

Reset Azure AD and AD FS trust

You can also use the AADConnect wizard to completely reset the relying party trust for Office 365. This will result of a quick unavailability of the ADFS farm, a few seconds. The claims rules will be completely rebuilt with the most up to date settings from your AADConnect version.

Note: when you perform an AADConnect update/upgrade, AADConnect with reset the ADFS relying party trust for OFfice 365, and will repair the issue.

Delete Office 365 RPT and Update-MsolFederatedDomain

You can also delete the Office 365 relying party trust in the ADFS farm, and then use PowerShell to rebuild it:

Update-MsolFederatedDomain -DomainName itfordummies.com

Note: Anyone of the federated domain will make it work.

Note: This is kind of the same operation as the reset from AADConnect and may imply a few seconds of unavailability.

Conclusion

Once you’re done, you can verify with AADConnect and “Verify federated login”. The key point here, is to use AADConnect to pilot AD FS when possible, it does a great job without impacting the AdditionalAuthenticationRules or other application federation trusts.