昨天談到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,收工。

參考資料:


Comments

Be the first to post a comment

Post a comment