Chrome 87 在针对 Windows IIS 10 的 CORS 中的 Windows 身份验证失败

Chrome 86（及更早版本）、Edge、Curl 和 IE 都能够对 Windows 2019 计算机上的 IIS 10 ASP.NET 服务进行跨域 Windows 身份验证，没有任何问题。

但 Chrome 87 失败，并显示“从源 'http://[DIFFERENT]' 访问 'https://[REDACTED]' 处的 XMLHttpRequest 已被 CORS 策略阻止：不存在 'Access-Control-Allow-Origin' 标头根据要求”

奇怪的是，Chrome 87 可以与在配置相同的 Windows 2008 计算机（不要问）上的 IIS 7.5 中运行的相同 ASP.NET 服务配合使用。

更新：注意 - 我意识到 [2020-12-04]“工作”系统恰好位于不同的域上，该域已添加到我的“始终可以使用 cookie 的站点”列表中。所以“修复”从一开始就在我面前......；）

使用curl - 我看不出Windows 身份验证的IIS 响应之间有任何区别。

如果我破解我的 ASP.NET 并让它在所有请求而不是主要请求中包含回显的 Access-Control-Allow-Origin 'http://[DIFFERENT]' - 那么 Chrome 87 会发出 401 - 未授权 - 而不是继续来回进行 Windows 身份验证。 Curl 和其他浏览器都可以使用附加标头。

直接调用网站（无需跨源）就可以了。

有人知道 Chrome 87 做了什么不同吗？开发工具仅显示链中的“最后一个”请求 - 所以我不知道失败之前发生了什么。

更新：[2020-12-02] 显然，Chromium 团队声称它正在按照需要的方式工作......但对我来说，这似乎很奇怪。

https://bugs.chromium.org/p/chromium/issues/detail?id=1154281 https://bugs.chromium.org/p/chromium/issues/detail?id=1154281

“这是现在的预期行为 - 阻止第三方 cookie 现在的行为就像设置凭据：忽略第三方请求。我们将看看我们收到了多少关于此问题的报告，但之前的行为是有问题的，因为真正未经授权的请求以及那些提供 HTTP 身份验证凭据，但没有 cookie，将共享套接字。”

我们在我们的环境中看到了同样的情况，Chrome 87 现在将 cookie 规则应用于 Kerberos 和 NTLM 身份验证（显然是一个错误）。这不仅影响 XHR，还影响从其他站点加载的任何资源（图像、iframe 等）。

我们设置了“阻止第三方 cookie”，并发现将受影响的网站和域添加到 Chrome 中的“始终可以使用 cookie 的网站”列表中已恢复身份验证；这对我们来说是一个可以接受的解决方法，因为我们通过组策略管理 Chrome，并且可以轻松推出更新的网站列表。

2020年12月2日： 截至今天，MS Edge 87 也表现出相同的行为。