在企業內部寫ASP.NET的人都用過整合式Windows驗證吧？來個小測驗：
- 沒加入網域的PC可以用AD帳號登入隸屬該網域的IIS嗎？
- 在測試環境建立一測試網域，與公司正式AD網域間無信任關係。正式網域PC是否可以用測試網域帳號登入測試網域的IIS？
- 承上，正式網域PC需將DNS指向測試網域DC才能用測試網域帳號登入嗎？
依據實際使用經驗，我知道的答案是：Yes、Yes、No，但不知所以然。最近因工作需要做了粗淺研究，整理筆記備忘兼分享。（如有謬誤，有請各方高人指正）
IIS實現Windows驗證的方式有兩種，NTLM與Kerberos。NTLM如其名，是NT時代就有的Challenge/Response驗證方式（不透過網路傳輸密碼本身）；Windows 2000起改用Kerberos作為預設認證協定，主要有以下優點：
驗證速度快
使用NTLM時，若資源伺服器本身不是DC（Domain Controller，網域控制器），則轉向DC求證身分真偽（稱之Pass-Through Authentication）；而資源伺服器取得Kerberros Tickets（或稱Authenticator）時就已取得足以驗證客戶端的資訊，較有效率。交互驗證
Kerberos驗證時，不只客戶端向伺服器證明自己身分，伺服器也可要求伺服器驗明正身，社絕NTLM可能被冒牌伺服器騙取身分的風險。Kerberos為開放標準
由於Kerberos為開放標準，故有機會整合Windows與其他作業系統達成單一登入（Single Sign On）。支援驗證委派
資源伺服器取得代表使用者身分的Kerberos Ticket後，可直接代表該使用者存取其他資源伺服器。例如：使用者登入Web後，Web以該使用者身分登入SQL。支援Smart Card登入
可整合Smart Card做到雙因子登入，登入時需擁有實體卡片並知道密碼，降低身分盜用風險。
當我們設定IIS使用Windows驗證時，預設的提供者為Negotiate，包含Kerberos及NTLM兩種驗證方式，而其選用規則為「與瀏覽器協商，先嘗試使用Kerberos，若條件不符則改用NTLM」。
IIS採用NTLM或Kerberos則有以下區別：
NTLM
- 客戶端不管有沒有加入網域都適用
- 可使用網域帳號或本機帳號
- 使用網域帳號時，只有IIS主機需要連線DC
註：忙碌的NTLM Server (IIS, Exchange, TMG/ISA)可能產生大量NTLM請求，對DC形成負擔 - 客戶端只需連上IIS，不用連到DC
- 可以穿透支援HTTP Keep-Alives的Proxy
- 認證過程需多次往返（HTTP 401 –> HTTP 401 –> HTTP 200）
- 不支援Double-Hop Authenticataion（即驗證委派，將使用者認證用於另一台電腦執行的服務）
- 支援Windows 2000以下的舊版系統（註：此點已可忽略）
- 易受LM Auth Level不一致影響(lmcompatibilitylevel不吻合)
- 為Negotiate提供者的備援方案，若 Kerberos不成功就轉用NTLM
Kerberos
- 只適用已加入網域的客戶端
- 客戶端必須自己連上AD DC（TCP/UDP 88 Port）
- 不易穿透Proxy
- 憑證效期長（10小時），DC負荷較輕
- 認證過程為HTTP 401 –> 傳送Token（6-16KB） –> HTTP 200
- 認證身分可以轉用。例如：使用者登入IIS後，Web使用同一AD帳號登入SQL
- Negotiate提供者的優先選項
- 必須搞定SPN註冊（手續挺複雜）
- 非常容易失敗，如果你…
- 在URL使用IP而不是機器名稱
- 沒註冊SPN
- 重複註冊SPN
- SPN註冊錯帳號 (KRB_ERR_AP_MODIFIED)
- 客戶端無法連線DNS/DC
- Proxy/Local Intranet Zone沒設好
理解以上知識，一開始的三個問題就有了答案，而我才這發現平日使用的Windows驗證，幾乎都是走NTLM，理由包含：使用測試AD帳號、使用IP URL、未特別為網站註冊SPN、啟用Web Farm或負載平衡設備無法用機器名稱… 換言之，Kerberos雖然更安全，但成立條件嚴苛，稍有不慎就會掉回NTLM。
活到老學到老，今天又上了一課。
參考資料：
- Comparing Windows Kerberos and NTLM Authentication Protocols
- Why use Kerberos instead of NTLM in IIS?