前言
最近客戶從 Windows 2003 升級到 Windows 2016，聽說使用者是透過 AD 驗證登入的。
於是在 IIS 那裡設定 Windows 整合驗證(Kerberos, NTLM)，都可以讓使用者用 AD 去登入。
但是客戶說，他們想要每次登入時，都出現 Windows 登入驗證視窗來讓使用者輸入。
預設近端網站是會直接登入的，詳細可以參考[IE]設定 Windows 驗證，Client 還是會跳出登入視窗呢?
研究
那是否請客戶將該網站加入「信任或是網際網路」應該就會跳出登入驗證視窗，但目前有些使用者卻是「近端」，不太可能請使用者自已來設定。
而客戶也說，舊的系統也沒特別設定，但卻會跳出 Windows 登入驗證視窗。
於是再回頭查看那台舊作業系統在 IIS 那是如何設定的，結果它是啟用「摘要式驗證」。
於是在 Windows 2016 中也加入「摘要式驗證」，並在應用程式那啟用 摘要式驗證。
結果，Client 不管在近端、信任及網際網路，都會出現 Windows 登入驗證視窗，讓使用者來輸入。
這樣就達到使用者的需求。
補充說明怪異的狀況
另外，原本設定 Windows 整合驗證時，在某些電腦使用停止約 3 分鐘時，透過 UpdatePanel Postback 時，會發生「Sys.WebForms.PageRequestManagerpasrserErrorException: 無法剖析從伺服器收到的訊息」的錯誤。
查看 F12 的網路後發現，正常從 UpdatePanel Postback 發出的 Body 會有內容，回傳值是 text/plain 。
而發生錯誤它的 Request Body 是空的，Content-Length 是 0 。
而且 Header 多加了 Authorization: Negotiate TlRMTVNTUAABAAAAl4II4xxxxgsssdfsadsfGAbEdAAAADw==
的值，所以發回來的內容是整個網頁，所以在 Parse 時，就會噴錯。
但是 Negotiate 是 Windows 的 Kerberos，但這個應用程式，只啟用「匿名驗證」跟本就沒有啟用「Windows 驗證」(原本 Windows 驗證是另一個應用程式)。
但好玩的事，將 Windows 驗證 中的 Providers ，將 NTLM 上調到第一位(原本 Negotiate 是第一位)。
在有問題的電腦中測試，它的 Header 也一併變成了 Authorization: NTLM 。
後來將那個 Windows 驗證，改成使用 摘要式驗證 ，就沒有再出現那個 UpdatePanel Postback 的怪問題。
有遇到問題的朋友，可以參考一下哦!