问题
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."
回答1:
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.
来源：https://stackoverflow.com/questions/64919171/chrome-87-is-failing-windows-authentication-in-cors-against-windows-iis-10