Sometimes, you hit error messages that are just too vague to troubleshoot. I like these kinds of situations. I’ve hit this particular error before, but Microsoft fixed the issue with the 515 rID a long time ago…
Let’s see what’s happening today causing the same error. 
The situation
An organization has recently restructured. Today, all employees work together as one organization using one company name and one DNS domain name.
This organization uses AD FS, Azure AD Connect, Azure AD and Microsoft 365. The organization uses the latest version of Azure AD Connect. The Azure AD Connect installation is used to manage AD FS.
The issue
One employee has reset the password to his user account. From that moment on, the person was unable to sign in to Microsoft 365 services. At sign-in, the person would get an error from AD FS stating:
AADSTS50107 Requested federation realm object does not exist
Our troubleshooting
I was asked to troubleshoot this scenario, together with my colleague Bas. We utilized the default approach:
- Update the Azure AD trust from within Azure AD Connect
- Verify federated login in Azure AD Connect for the user
- Configure Claims X-Ray and perform a sign-in for the user
- Compare attributes for the on-premises user object in Active Directory and the object in Azure AD
It became clear really fast, that there was only one person in the organization experiencing this issue. Interestingly, Claims X-Ray didn’t display any error and displayed claims information for the object without issues.
When looking at the attributes for the on-premises user object in Active Directory, I noticed there was a space at the end of the email address specified in the mail attribute, so I removed it.
When looking at the RAW token from Claims X-Ray, my colleague then found the cause of the issue.
The cause
The userPrincipalName attribute for the object in Active Directory also had a trailing space.
It was clearly visible in the RAW token just before the </saml:AttributeValue> tag. We didn’t notice it in our PowerShell outputs and couldn’t see it in the graphical management tools, obviously.
During the restructuring of the organization, the mail attribute was used to fill the userPrincipalName attribute. As the mail attribute doesn’t have input validation, you can pretty much fill in anything in this attribute. As the script did not (sufficiently) check the value before overwriting the userPrincipalName attribute, the space was migrated over.
The password reset must have triggered the revocation of certain refresh tokens, triggering the issue.
The solution
On the Attribute Editor tab of the Active Directory user object’s Properties, I deleted the trailing space in the userPrincipalName attribute.
excellent detail in this solution.