為什麼在 IIS 中使用 Kerberos 而不是 NTLM？
這是我從未真正能夠像我喜歡的那樣回答的問題： 在 IIS 中使用 Kerberos 身份驗證而不是 NTLM 的真正優勢是什麼？
我已經看到很多人真的很難設置它（包括我自己），我一直無法找到使用它的充分理由。不過肯定有一些非常顯著的優勢，否則設置它不值得所有的麻煩，對吧？
僅從 Windows 的角度來看：
NTLM
- 適用於外部 （非域）和內部客戶端
- 在 IIS 框中 同時使用域帳戶和本地使用者帳戶
- 使用域帳戶，只有伺服器需要直接連接到域控制器 (DC)
- 使用本地帳戶，您在任何地方都不需要連接:)
- 您無需以相關使用者身份登錄即可使用憑據
- 另外：DC 被繁忙的 NTLM 伺服器（IIS、Exchange、TMG/ISA 等）和大量 NTLM 請求（以減輕：
MaxConcurrentAPI、AuthPersistSingleRequest（錯誤）、更快的 DC。）壓倒並不少見。參考獎金。）- 只需要客戶端連接到 IIS 伺服器（在站點埠上，沒有別的。即一切都通過 HTTP（或 HTTPS）發生。）
- 可以遍歷任何支持HTTP Keep-Alive的 代理
- 您也許可以使用 TLS/SSL 來解決其他問題
- 需要多次往返進行身份驗證，使用小數據包
- （日誌模式是 401.2、401.1、200和使用者名）
- 不能用於需要雙跳認證的場景
- 即使用者的憑據將被轉發到另一台電腦上的服務
- 支持舊客戶端 (< Win2000)
- 容易受到 LM Auth Level 差異的影響（不匹配
lmcompatibilitylevel）- 如果 Curb 失敗，則由 Negotiate 包用作備份。
- （不是“如果使用Kerb拒絕訪問”，Curb 必須中斷才能使用 NTLM - 通常這看起來像沒有得到票證。如果客戶端得到票證並且它不完美，這不會導致回退。）
Kerberos
僅適用於目前加入域的客戶端
- 需要客戶端連接到AD DC (tcp/udp 88)和伺服器（票證由客戶端通過 Curb 埠從 DC 檢索，然後使用 HTTP 提供給伺服器）
可能能夠遍歷代理，但請參閱上面的 DC 點：您仍然需要與活動 DC 位於同一網路上，伺服器也是如此。
- 所以理論上，如果你有一個域，其中連接網際網路的客戶端直接與連接網際網路的 DC 聊天，它是可行的。但除非你已經知道，否則不要這樣做。
- 在反向代理場景 (ISA/TMG) 中，協議轉換伺服器需要在該網路上，即不是客戶端……但是客戶端並不是真正執行 Kerberos 位的人（必然 - 認為 Forms auth to Curb過渡）。
票證是長期存在的（10 小時），這意味著在票證生命週期內DC 通信較少- 並且要強調：這可以在該生命週期內為每個客戶端**節省數千到數百萬個請求 - （仍然是一件事；Kerberos PAC 驗證曾經是一件事）
AuthPersistNonNTLM需要單次往返進行身份驗證，但身份驗證負載大小相對較大（通常為 6-16K）（401 , {(encoded) token size} 200）
可以與（“請始終使用約束”） 委託一起使用以啟用雙跳方案**，即連接使用者到下一個服務的 Windows 身份驗證
- 實際上，N-hop - 它像樂高積木一樣堆疊！根據需要添加盡可能多的啤酒花…
- 例如，允許
UserA訪問 IIS，並讓 IIS 在訪問不同的 SQL Server 電腦時模擬同一個 Windows 使用者帳戶。這就是“授權授權”。- （在此上下文中的約束意味著“但不是其他任何東西”，例如 Exchange 或其他 SQL 框）
目前是協商身份驗證的主要安全包
- 意味著 Windows 域成員在可以獲得它時更喜歡它
需要註冊 SPN，這可能很棘手。有幫助的規則。
需要使用名稱作為目標，而不是 IP 地址
遏制可能失敗的原因：
- 使用 IP 地址而不是名稱
- 沒有註冊 SPN
- 註冊的重複 SPN
- SPN 註冊了錯誤的帳戶 (
KRB_ERR_AP_MODIFIED)- 沒有客戶端 DNS / DC 連接
- 客戶端代理設置/本地 Intranet 區域未用於目標站點
當我們這樣做時：
基本的
可以多跳。但是通過將您的使用者名和密碼直接暴露給目標 Web 應用程序來實現
- 然後它可以對他們做任何它想做的事情。任何東西。
- “哦，域管理員剛剛使用了我的應用程序嗎？我剛剛閱讀了他們的電子郵件嗎？然後重置了他們的密碼？唉。可惜”
任何形式的安全都需要傳輸層安全性（即 TLS/SSL）。
- 然後，看上一期
適用於任何瀏覽器
- （但見第一期）
需要單次往返進行身份驗證（401、200）
可用於多跳場景，因為 Windows 可以使用基本憑據執行互動式登錄
- 可能需要
LogonType配置來完成此操作（認為預設值在 2000 年到 2003 年之間更改為網路明文，但可能記錯了）- 但同樣，請參閱第一期。
- 得到第一個問題真的非常重要的印象？這是。
總結一下：
設置遏制可能很棘手，但是那裡有大量指南（我的指南）試圖簡化流程，並且從 2003 年到 2008 年，這些工具有了很大
SetSPN的改進（可以搜尋重複項，這是最常見的破壞問題;在看到使用SETSPN -S-A 的指導時使用，生活會更快樂）。受限制的代表團值得入場。