AD FS login fails for non-admin users

Thanks to Jack Benson for bringing this issue to my attention, I wasn’t aware of it before. Here’s the original thread on EE:

Long story short – AD FS 3.0 farm, properly configured and the RPT with O365 established. No funny claims rules, no additional auth factors enforced (well device registration was initially, which steered us away from troubleshooting this, but that’s not relevant to the actual issue), the users were properly synced to O365. Yet login was working only for Admin accounts. Jack then stumbled upon a very similar issue reported on TechNet forums:

Turns out, the service account was missing the required permissions. Simply giving the account Read access to the user account in question resolved the issue – the user was now able to properly use AD FS. As it turns out, the root cause was that the for whatever reason, the access entry for “Authenticated Users” was removed from the “Pre-Windows 2000 Compatible Access” group in the affected environments.

Now why would this happen is another story. The “Authenticated users” group is added as a member by default in Server 2008/R2, 2012/R2, 2016, if you un-check the “Permissions compatible with pre-Windows 2000 servers” checkbox during DCPromo (or whatever other method you used to create the first domain). If you did check that option, the “Everyone” group will be added instead, and in some cases adding the “Anonymous logon” security principal was also required for applications to run properly. In this case (checkbox ticket), the “Authenticated users” group is not added. My guess is that the security guys stumbled upon some articles that explained how big of a security exploit having the everyone/anonymous access is and demanded a quick fix, which in turn resulted in clearing the membership of the “Pre-Windows 2000 Compatible Access” group. And skipping the step of adding the  “Authenticated users” group. This in turn will result in all kinds of issues with different applications – apart from the issue with AD FS, you might run into issue with accessing shares, creating VMs in VMM, changing passwords via applications such as ISA, etc. Here are some articles with more details:

In addition, a very similar issue might occur if the application in question is not able to read the tokenGroupsGlobalAndUniversal attribute. To solve this, make sure that the service account is a member of the “Windows Authorization Access Group”.

Note that the scenarios described here don’t only apply to configurations with GMSA configured!

This entry was posted in Office 365. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *