Menu
Chrome 86 (and prior), Edge, Curl, and IE all are able to do cross-origin Windows Authentication against my IIS 10 ASP.NET service on Windows 2019 machine without any problem.
But Chrome 87 fails with "Access to XMLHttpRequest at 'https://[REDACTED]' from origin 'http://[DIFFERENT]' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested"
Weirdly - Chrome 87 works with the identical ASP.NET service running in IIS 7.5 on a Windows 2008 machine (don't ask) that is configured identically.
UPDATE: Note - I realized [2020-12-04] that the "working" system happened to be on a different domain that was already added to my "Sites that can always use cookies" list. So the "fix" was staring me in the face right from the start... ;)
Using curl - I can't see any difference between the IIS responses for Windows Authentication.
If I hack my ASP.NET and have it include a echoed Access-Control-Allow-Origin 'http://[DIFFERENT]' to all requests instead of the main one - then Chrome 87 barks a 401 - not authorized - instead of continuing with the Windows Authentication back and forth. Curl and the other browsers are just fine with the additional headers.
Invoking the website directly (without cross-origin) works just fine.
Anyone have a clue what Chrome 87 is doing different? The Dev Tools only shows the "last" request in the chain - so I don't know what is happening prior to the failure.
UPDATE: [2020-12-02] Apparently the Chromium Team is claiming it is working the way it needs to... But it seems weirdly broken to me.
https://bugs.chromium.org/p/chromium/issues/detail?id=1154281
"This is now expected behavior - blocking third party cookies now acts like setting crendials:omit on third party requests. We'll see how many reports we get about this, but the previous behavior was buggy, since truly uncredentialed requests and those that had provided HTTP auth credentials, but no cookies, would share sockets."
309
Click on 'Security tab > Local intranet' then the 'Custom level...' button. Scroll to the bottom and select the 'Automatic logon with current user name and password' option. It's under the 'Authentication > Logon' section. Click OK to save the changes.
Open the Windows Control Panel and go to Network and Internet > Internet Options. On the Advanced tab, select Enable Integrated Windows Authentication.
Select the "Advanced" tab. Scroll down to the "Security" section until you see "Enable Integrated Windows Authentication". Select the box next to this field to enable. Select the "Security" tab.
We are seeing the same in our environment, Chrome 87 is now applying the cookie rules to Kerberos and NTLM authentication (clearly a bug). This is affecting not just XHR but any resource loaded from another site (images, iframes, etc).
We have "Block third-party cookies" set and have found that adding affected sites and domains to the "Sites that can always use cookies" list in Chrome has restored authentication; and is an acceptable workaround for us since we manage Chrome via Group Policy and can push out an updated list of sites easily.
2020-12-02: As of today MS Edge 87 exhibits the same behaviour.
188
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
