為 WSS Reporting Services 設置 Kerberos 身份驗證所涉及的風險
我們有一個基於 WSS 的已建立的 Intranet，具有兩個前端和一個數據庫。
目前所有的身份驗證都是 NTLM。
我們已經在集成模式下安裝了 Reporting Services。
只要安裝了 RS 的 Web 前端處理事務，RS 就可以工作。
如果沒有 RS 的前端處理請求，那麼我們會收到 UNAUTHORIZED 錯誤。
在嘗試解決此問題時，網路搜尋等 - 暗示該問題是由農場需要執行“雙跳”身份驗證引起的 - 這不能通過 NTLM 發生。
所以我們需要配置 Intranet 場以接受 Kerberos 身份驗證。
我找到了這個有用的指南，但它採取了我們從頭開始農場的立場。
所以我們需要知道追溯配置 Kerberos 是否存在風險？在我們執行啟用 Kerberos 的步驟期間和之後，NTLM 會像以前一樣繼續嗎？
啟用 Kerberos 委派以允許雙跳存在一些風險。基本上，您允許 IIS 模擬使用者，而無需使用者再次實際輸入任何憑據。在 Windows 2000 Active Directory 環境中，只有所謂的無約束委派。基本上，你不能限制委派的工作以及它可以很好地委派的地方（以及你想要的）。在這些情況下，Microsoft 強烈建議不要使用 Kerberos 委派。如果您使用的是 Windows 2003 或 2008 Active Directory，則可以並且應該使用約束委派。這使您可以更具體地了解委派。在這種情況下，風險會增加，但通常事實是您不這樣做
至於 NTLM 是否會繼續，這取決於。如果可以建立 Kerberos 身份驗證，則將使用它。這包括它返回錯誤的情況（您認為它不應該如此），例如 SPN 錯誤等。如果無法使用 Kerberos 身份驗證，它只會退回到 NTLM。話雖如此，Kerberos 是較新的安全協議，並且具有 NTLM 不包括的安全功能，包括時間戳（防止中繼攻擊）、客戶端驗證伺服器身份的能力（NTLM 無法做到）以及票證的使用這應該會減少對 DC 進行身份驗證的總體流量。