From the field: Colleagues in specific group encounter error “AADSTS50107 Requested federation realm object does not exist.”

Sometimes, you hit error messages that are just too vague to troubleshoot. I like these kinds of situations. This particular one is especially fun, because it requires some intermediate knowledge of Active Directory Federation Services in Hybrid Identity environments.

My favorite subject. Emoticon met brede lach

 

The situation

Single Sign-On (SSO) for organizations comes in many shapes and sizes.
One of the more popular setups is Hybrid Identity where Active Directory and Azure Active Directory work together. For authentication, in the majority of these implementations, Active Directory Federation Services (AD FS) is used.

One of the more advanced scenarios is the scenario where domain-joined devices automatically join Azure Active Directory based on a Group Policy setting, a Service Connection Point (SCP) and Active Directory Federation Services (AD FS) Claims Issuance Rules. The detailed information for this scenario is provided by Microsoft on GitHub for Connecting domain-joined devices to Azure AD for Windows 10 experiences.

 

The problem

In an implementation, following the scenario described above, some colleagues encounter an error message when logging into Office 365. This Azure Active Directory-integrated application is used in an environment where Hybrid Identity is configured with federation towards Active Directory Federation Services (AD FS) on Windows Server 2012 R2.

They receive an error message when logging on, stating:

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

All other colleagues have no problem using any of the applications that are integrated with Azure Active Directory or Active Directory Federation Services (AD FS).

 

Our investigation

We began our troubleshooting roughly a month ago.

The Active Directory Domain Services environment consists of one Active Directory domain in one Active Directory forest. Further investigation reveals that while colleagues are part of hundreds of groups, the colleagues that are affected by the issue are all part of a specific group in Active Directory.

The Relying Party Trust (RPT) between Azure Active Directory and Active Directory Federation Services (AD FS) for the Office 365 Identity Platform was created using the Convert-MSOLDomainToFederated Windows PowerShell Cmdlet from the Azure Active Directory PowerShell Module. Its purpose is to change a verified DNS domain name to a federated domain.

 

The cause

The Issuance Transform Rules you created at the time to Connect domain-joined devices to Azure AD for Windows 10 experiences for the Office 365 Identity Platform, named

  • Issue object GUID
  • Issue account type for domain joined computers
  • Pass through primary SID

read:

Issue object GUID

c1:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]

c2:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”] => issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/identity/claims/onpremobjectguid”), query = “;objectguid;{0}”, param = c2.Value);


Issue account type for domain joined computers

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”);


Pass through primary SID

c1:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]

c2:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”] => issue(claim = c2);

 

The second of these rules is the one wreaking havoc on the users in the specific group.
This specific rule checks for membership of the Domain Computers group, by looking at the Well-known Group sID for it: 515.

The colleagues, that were experiencing problems with signing in to Office 365, happened to be members of a group, whose sID ended in 7515…

Note:
Azure AD Connect can also create the above rules when you configure it for AD FS through Custom Settings. Even if an organization hasn’t created the Claims Issuance Rules manually, they might still trip over them.

 

The solution

We changed the Issuance Transform Rules.

Everywhere we encountered

Value =~ “515$

We replaced it to read

Value =~ “-515$”.

This fixed the problem, because it actually looks for the sID to end with -515, eliminating all other groups ending with 515, like 1515, 2515, etc.

 

Escalating

After the fourth customer experiencing the issue, I reached out to Microsoft. They had changed the documentation already to include the same fix we had, but of course, when an organization has things working, they rarely go back to the documentation to see if it has changed.

Note:
The documentation being hosted on GitHub is a pretty big clue Microsoft expects their documentation to change, possibly based on feedback by people like you and me.

Note:
Microsoft has been consistent in its endeavours to erradicate the above situation, so when you use an updated version of Azure AD Connect and/or the Azure Active Directory PowerShell Module 2.0, you’ll see four Active Directory Federation Services (AD FS) claims issuance rules being created, of which the ones targetting the Domain Computers group have the minus added.

 

Call to Action

As I’ve previously laid out, Lifecycle Management can’t be a mere afterthought anymore. Please:

  • Check to see if your Claims Issuance Rules are impacted by this issue.
  • Monitor for servicedesk calls from colleagues not being able to log into Office 365.
  • Upgrade to the latest version of Azure AD Connect.
    Note that Azure AD Connect installations with Express Settings are auto-upgraded to the latest stable release, although they haven’t since version 1.1.343.0.
  • Regularly check for updates to Azure AD Connect and the documentation.

Further reading

Connect domain-joined devices to Azure AD for Windows 10 experiences
How to configure automatic registration of domain-joined devices with Azure AD
Why Lifecycle Management can’t be a mere afterthought anymore
Well-known security identifiers in Windows operating systems
Version 1.1.380.0 of Azure AD Connect fixes a bug in multi-domain scenarios
Claim Rules

Hat tip

Thank you to my colleagues MarcZ and BasA for sharing and caring.

leave your comment