In our organization we recently faced some issues with some of our
On our ADFS configuration we enabled WIA (Windows Integrated Authentication). As it turns out older Chromebooks worked fine with this type of configuration. But the more recent SameSite cookie changes in Chrome 80 seem to have broken this functionality.
Microsoft hotfixes
Microsoft has provided some hotfixes to make ADFS compatible with the SameSite cookie change Google has announced. Microsoft provides the following hotfixes (depending on your WIndows version):
Though these hotfixes are required to make Chrome 80 work with ADFS, they do not seem to fix the problem we are facing with our Chromebooks. All our systems were up-to-date at the time of testing.
Fixing ADFS authentication on Chromebooks with Chrome 80
After a lot of digging and troubleshooting, we decided to disable WIA authentication for ChromeOS devices. This will force the user to login to a form based authentication. In order to disable WIA for ChromeOS devices only, and not for WIndows Chrome logins we issued the following command (using an elevated WIndows PowerShell console):
Set-AdfsProperties -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain", "MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "MS_WorkFoldersClient", "=~Windows\sNT.Edge", "Edge/12", "=~Windows\sNT.Chrome")
This command disables WIA authentication for Chromebooks, but keeps it alive for Windows machines.
Thanks for sharing Maarten; have been chasing this one for a while now; glad to see I wasn’t going crazy.
Do you maybe know what exactly changed (in ChromeOS) that is causing it to default to WIA? Did they introduce a new UserAgent or something? Thanks!
Yes I think they introduced a different user agent string. But I couldn’t verify this in detail, because I didn’t have an old version Chromebook at hand at the time. Glad this article was helpful!
BTW, in your command I noticed you didn’t include “Mozilla/5.0“; is this because that one is causing the problematic behavior? Or is it because your environment doesn’t make use of FireFox?
In our environment, “Mozilla/5.0” is currently included in the Agents lists so running your command would remove it.
Hi – just to clarify & feedback on my earlier comments:
– In the “before” situation, we included the “Mozilla/5.0” UserAgent; this would capture ALL browsers (IE, Chrome, Firefox) but also the ChromeOS Login Experience.
– By removing “Mozilla/5.0”, and adding the new regular expressions, ADFS would only offer WIA to the Windows versions of those browsers; exactly what we wanted (Windows Chrome uses WIA, ChromeOS using Forms Based Auth)
WARNING: I had to add asterisk symbols in front of both the regular expressions in order to make your command work!! Otherwise it would also use Forms Based Authentication om the Windows Chrome browser! This is the command I ended up using (notice the wildcard symbols!):
Set-AdfsProperties -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain", "MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "MS_WorkFoldersClient", "=~Windowss*NT.*Edge", "Edge/12", "=~Windowss*NT.*Chrome")If you also wish to have Firefox use WIA, then run this version:
Set-AdfsProperties -WIASupportedUserAgents @("MSAuthHost/1.0/In-Domain", "MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "MS_WorkFoldersClient", "=~Windowss*NT.*Edge", "Edge/12", "=~Windowss*NT.*Chrome", "=~Windowss*NT.*Firefox")