When testing out Windows Authentication with a new ADFS deployment for Windows Server 2022, I found that users kept getting redirected to the Forms Authentication login page.
Windows Authentication was definitely enabled as a Primary Authentication method in ADFS manager for Intranet authentication. Windows Integrated Authentication is supposed to take predecence over Forms Based Authentication (FBA) when the computer is joined to the domain, and therefore able to obtain a Kerberos ticket in the background.
Going through the basic troubleshooting didn’t yeild any results – the SPN for the ADFS service account was configured properly, the channel binding token wasn’t the issue, and the client computer’s Internet Options were configured with the ADFS server in the trusted Intranet zone. https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-iwa
I tried to authenticate with Windows Authentication using both the Microsoft Edge browser, and the Chrome browser. So I didn’t think the browser would be the issue. But it turns out it was. Browsers send a user-agent string in the request, which tells a web server how to structure content for specific browsers. And ADFS has a list of specific browsers that can participate in Windows Integrated Authentication.
If you open PowerShell on the ADFS server and run the command:
(Get-AdfsProperties).WIASupportedUserAgentsADFS will return the user-agent strings that are supported for Windows Integrated Authentication. It appears that Microsoft Edge is on the list, at the bottom.
But running a trace in Fiddler shows that Edge is actually sending this user-agent string:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36 Edg/120.0.0.0
None of those user-agent strings are in the default list in ADFS!
A little research found that Mozilla/5.0 is common to most browser these days. Even PowerShell sends this in the user-agent string. Mozilla is the engine used by Firefox, but browsers often send user-agent strings representing other browsers, in order to guarantee they receive any HTML features that might be intended (i.e. coded by the webmaster) for those specific browsers. That use to be more of an issue years ago, back in the Internet Explorer days, but apparently it’s still a consideration.
The answer then is simply to add Mozilla/5.0 to the list of WIASupportedUserAgents in ADFS:
Set-AdfsProperties -WIASupportedUserAgents ((Get-AdfsProperties).WIASupportedUserAgents + "Mozilla/5.0")Run (Get-AdfsProperties).WIASupportedUserAgents again to see the updated list.
Mozilla/5.0 has been appended to the bottom of the list.
And now users can access the application using Windows Authentication, without being prompted for Forms Based Authentication.
I hope this helped. You can check out my courses on ADFS and other topics on Pluralsight. Sign up for a free trial using the link below.
