Just recently I happened to face a pretty annoying issue, that took me a couple of hours to solve. And by the end it was quite simple and obvious actually.
Long story short – newly implemented AD FS 4.0 farm, properly configured and already working. No funny claims rules, no additional authentication factors enforced, still login was working only for a couple of accounts with no obvious similarities or discrepancies. All users were created equal.
Testing was done by navigating to https://sts.domain.com/adfs/ls/idpinitiatedSignon.aspx and logging in with valid user credentials. For some users it worked and for others… well it did not. They were just thrown back to the login mask, no error message or anything.
Please note that the aforementioned endpoint is by default disabled in Windows Server 2016 ADFS 4.0. You have to enable it first by running:
Set-AdfsProperties -EnableIdPInitiatedSignonPage $true
Troubleshooting was quite a chore as no events were triggered and or logged in any of the available Event Logs or log/tracing files. When using bogus login credentials on purpose, e.g. wrong username or password, I received corresponding error messages of invalid username or password.
I use a managed service account (gMSA) for the ADFS service, as this is best practice and recommend by Microsoft.
As stated by Vasil Michev in his blog post (and answer to my problem):
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.
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”.
Furthermore as stated by Aaron.H in the corresponding Microsoft Forums thread:
I discovered that the Pre-Windows 2000 Compatible Access group in my production domain did not have Authenticated Users as a member like the new lab domain did. Once I added Authenticated Users to the Pre-Windows 2000 group, I was able to authenticate using regular domain accounts to ADFS.
Another reply states:
I just added the service account (which was created manually rather than a managed service account) for adfs to the Pre-Windows 2000 group and that resolved my issue, so you don’t have to add the Authenticated Users group if you don’t want to.
And a final statement on this issue:
Don’t know if you guys solved it by now but i wanted to let you know the Pre-windows 2000 Group membership didn’t work for me. However when i added the ADFS group managed service account to the ‘ Windows Authorization Access Group’ it worked instantly. According to the description of this group (‘Members of this group have access to the computed tokenGroupsGlobalAndUniversal attribute on User objects’) this is expected behaviour.
There are a lot of reasons why correct permissions are not being assigned throughout the domain. The adminCount attribute, disabling inheritance, et al. So thanks to all guys involved in this issue and for clarifying things!
- AD FS Single Sign On – only working for 1 user
- AD FS login fails for non-admin users
- Single Sign-On – Troubleshooting login problems with ADFS
- Microsoft – AD FS Troubleshooting – Events and Logging
- Possible causes of Authentications failures for federated users in Office 365
- GitHub – Set up the lab environment for AD FS in Windows Server 2012 R2