a blog by Sander Berkouwer

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.

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.

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 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.

Archives

Categories

The information on this website is provided for informational purposes only and the authors make no warranties, either express or implied. Information in these documents, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user.Active Directory, Microsoft, MS-DOS, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. All other trademarks are property of their respective owners.