昨天談到IIS整合式Windows驗證會優先嘗試Kerberos，不行再改用NTLM，那麼如何得知現在用的驗證方式是哪一種？
瀏覽器的F12開發工具雖然有HTTP往來記錄，但不會顯示驗證過程，因此，Fiddler才是最佳觀察工具。
為了捕捉標本，我特地用Hyper-V架了AD，還學會用「setspn -a HTTP/機器名稱 AppPool執行帳號」註冊SPN的技巧，費了好大力氣，終於做出Kerberos驗證。以下介紹如何用Fiddler觀察Windows驗證過程：
首先測試Kerberos，URL要用機器名稱，讀取一個GIF作為簡單測試。當一切符合要求（SPN、網域內、機器名稱），瀏覽器就會使用Kerberos驗證。
由Fiddler可觀察到前文提過的「兩次401＋一次200」歷程。第一次Server先回傳HTTP 401，而Response Header提示IIS支援Negotiate及NTLM兩種認證方式，此時瀏覽器會跳出帳號密碼對話框等待使用者輸入帳號密碼：
使用輸入帳號密碼後，瀏覽器發出第二個Request，包含Authorization Header，IIS再次回應HTTP 401，Response包含WWW-Authenticate Header。
切到Fiddler獨有的Auth頁籤，可以看到詳細資訊，Request Header裡包含的就是前文提過的Kerberos Ticket，而Response Header回應則是Kerberos Reply：
後續發出的Request內含Kerberos Ticket，順利取回GIF圖檔：
接著，我們把URL的機器名稱換成IP，刻意違背Kerberos要求，預期將採用NTLM。第一個HTTP 401 Response Header一樣提示IIS支援Negotiate及NTLM兩種Provider：
輸入帳號密碼後瀏覽器發出第二個Request，Header包含Authentication資訊，401 Response則有WWW-Authenticate Header：
切到Auth頁籤可看出NTLM與Kerberos的明顯差異：Kerberos在第二次Request時送出是Kerberos Ticket，意味著Client端已向DC完成身分認證，直接向Server出示身分證明；而採用NTLM驗證時，第二個401 Response回覆的是NTLM Challenge，代表此時才開始用使用者的帳號密碼對Challenge內容進行演算，隨後得到200的Request才會送出針對Challenge的Response結果。
第三個Request已正確回傳HTTP 200取得圖檔，而Request Auth頁籤裡有玄機，其中橘底文字的完整內容為：Target Information block provided for use in calculation of the NTLMv2 response. 在此可完整見證NTLM Challenge/Response的運作。
如果沒有Fiddler可用，看不到HTTP 401歷程，要怎麼區別瀏覽器是走NTLM還是Kerborse。有一密技－當你在Request Authorization Header看到「TlR」字首，就代表目前使用的是NTLM（如圖所示）：
註：此一技巧來自MSDN Blog，但該文提到Kerberos標頭固定為YII與我的觀察不同，NTLM為TlR倒是所語不假。
學會這招，用Chrome F12開發者工具也能看出NTLM囉～
NTLM/Kerberos觀察技能點數＋1，收工。
參考資料：
