Chrome 87 在 CORS 中針對 Windows IIS 10 的 Windows 身份驗證失敗
Chrome 86（及更早版本）、Edge、Curl 和 IE 都能夠在 Windows 2019 機器上針對我的 IIS 10 ASP.NET 服務進行跨域 Windows 身份驗證，而不會出現任何問題。
但 Chrome 87 失敗並顯示“在 ‘https:// 訪問 XMLHttpRequest
$$ REDACTED $$‘來自原點’http://$$ DIFFERENT $$’ 已被 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
“這是現在的預期行為 - 阻止第三方 cookie 現在的行為就像在第三方請求上設置 crendials:omit提供 HTTP 身份驗證憑據，但沒有 cookie，將共享套接字。”
我們在我們的環境中看到了同樣的情況，Chrome 87 現在將 cookie 規則應用於 Kerberos 和 NTLM 身份驗證（顯然是一個錯誤）。這不僅會影響 XHR，還會影響從其他站點載入的任何資源（圖像、iframe 等）。
我們設置了“阻止第三方 cookie”，並發現將受影響的站點和域添加到 Chrome 中的“始終可以使用 cookie 的站點”列表已恢復身份驗證；並且對我們來說是一種可接受的解決方法，因為我們通過組策略管理 Chrome，並且可以輕鬆推出更新的站點列表。
2020-12-02：截至今天，MS Edge 87 表現出相同的行為。