雖然 SharePoint 提供了多個身份驗證選項和身份驗證區域，但在 Intranet 方案中企業實現的兩個最常見選項還是 NTLM 和 Kerberos。這兩種協議都用于典型的質詢/響應方案中的集成 Windows 身份驗證。NTLM 依賴于 IIS 在質詢過程中生成令牌，將令牌發送到客戶端，客戶端用令牌進行響應，域控制器驗證該響應。NTLM 要求在傳輸用戶名和密碼之前必須對它們進行加密，還要求在訪問新網絡資源時重新進行身份驗證（新令牌）。相反，Kerberos 則依賴于一個票證系統，其中的客戶端和服務器訪問一個名為密鑰發行中心 (KDC) 的受信任頒發機構，KDC 將響應客戶端請求，并授予相應票證，客戶端可以使用該票證訪問網絡資源。Kerberos 不需要重新進行身份驗證來訪問多個資源。

當前的大部分文檔都提倡使用 NTLM，除非是有某種特別迫切的需求，例如具有高安全服務級別協議的網站面臨的需求。即便在這種情況下，如果您進一步深究的話，使用 NTLM 仍是您的***：它更易于實現，無需額外步驟，而且能夠減少支持問題。例如，知識庫文章 832769 寫道：“…或無法配置服務主體名稱 (SPN)，請選擇 NTLM 身份驗證。如果您選擇 Kerberos 身份驗證但無法配置 SPN，則只有服務器管理員能夠通過 SharePoint 網站的身份驗證。”這個說法在技術上是準確的，但它似乎有一層隱含意思：配置 SPN 過于復雜，除非有人要求實現 Kerberos，否則都應對 Kerberos 避而遠之。但事實是，如果您了解原理，實現 Kerberos 并不是那么困難。

我們有很多合理的理由來解釋為什么應該轉換到 Kerberos，或者在新實現的系統中自始至終使用 Kerberos，但在大多數情況下，這些理由都可以歸結為性能或安全性。隨著用戶負載或拓撲復雜性的增加，NTLM 可能會引發性能問題，因為在很多 SharePoint 使用方案中（例如訪問 SharePoint Web 部件或自定義 Web 服務的 Web 應用程序），基于 NTLM 的身份驗證必定需要在 IIS 和域控制器之間多次往返。如果通過低速或高延遲鏈路來訪問域控制器，則很有可能出現性能問題。就安全性而言，采用網絡資源顯式委派的基于票證的系統 (Kerberos) 在設計上比只加密用戶憑據的方法更為安全。而且它速度更快，因為它僅使用單個票證即可訪問多個網絡資源。

很多安裝最初都采用 NTLM 而不是 Kerberos，因為規劃拓撲、服務器規模調整、安全支持提供程序 (SSP) 以及其他復雜細節已經令人望而生畏了，如果進一步提高復雜性，會讓用戶感到力不從心。這種看法有其合理之處。不管怎么說，啟用了 Kerberos 的實現難免會出現問題。只要閱讀知識庫文章 871179、962943 和 832769，便可了解到可能出現的一些問題，這些問題可能同藍屏 STOP 錯誤一樣嚴重。即便是現有文檔，例如 Microsoft 的 Kerberos 詳細實現指南，也沒有包括有關 IIS 版本 7 或更高版本的詳細信息，這些版本實現了內核模式身份驗證功能，并改變了處理 SPN 的方式。但不要擔心，如果您了解 SharePoint 如何使用 Kerberos 的基本概念，則實現和配置 Kerberos 會變得相對簡單一些。本文介紹了基本的體系結構組件，還包括一些配置詳細信息，可以幫助您入門。Microsoft 已經發布了帶有分步詳細信息的文檔，以及知識庫文章 832769 和 953130，可為您提供更多參考。

身份驗證組件和依賴關系

首先，我們將了解處理集成 Windows 身份驗證的 SharePoint 體系結構中的依賴關系。從最基本的層面上來講，無論是使用 NTLM 還是 Kerberos，都會有一個客戶端向啟用 SharePoint 的 .aspx 網頁發出請求，該網頁在后臺使用 .NET 和 IIS。與此同時，該網頁還依賴于 SQL Server 配置和內容數據庫中的數據。圖 1 顯示了 IIS 如何在 SharePoint 2007 上下文中處理與身份驗證相關的請求。當客戶端瀏覽器發出 Web 請求時，將在 IIS 中啟動一個線程，且與該請求相關的對象（例如，包含在 IPrincipal 對象中的 IIdentity 對象所含的令牌）將被附加到線程。從編程角度而言，IIdentity 和 IPrincipal 對象均通過 HttpContext.User 屬性訪問，而這兩個對象和該屬性均由 .NET 管道中包含的身份驗證模塊設置，如圖 1 所示。

圖 1 SharePoint 中的通用身份驗證組件和數據流

以下流程詳細說明了數據流：

1. 客戶端瀏覽器通過匿名 HTTP GET 請求初始化與 SharePoint 前端服務器的連接（由帶有 .NET 的 IIS 處理）。
2. 如果該區域配置了匿名訪問（例如在 Internet 方案中），則 IIS 將繼續處理該請求。否則，IIS 將返回錯誤 401.2 并請求從客戶端瀏覽器中進行身份驗證。
3. 客戶端瀏覽器接收請求，并根據區域和關聯的選項對客戶端進行身份驗證。常用方法是調用 AcquireCredentialsHandle 并提示輸入用戶名/密碼，然后通過 IIS 將身份驗證令牌返回 SharePoint。
4. IIS 正在 HTTP 會話中等待響應并接受身份驗證令牌，然后授權或拒絕訪問。此時，IIS 通過 .NET 將請求傳遞給 SharePoint。
5. 如果請求的頁面包含需要訪問后端 SQL 數據庫的 Web 部件，則 SharePoint 將進行 SQL Server 身份驗證并訪問數據庫。SQL 身份驗證的特性因配置選項而異。例如，您可以配置使用 NTLM 或 Kerberos 的 SQL Server 身份驗證或集成 Windows 身份驗證。下文將介紹 Kerberos 和 NTLM 的具體內容。

SharePoint 中身份驗證機制的關鍵所在是以下三個層分別行使各自的功能：客戶端瀏覽器、帶有 .NET 的 IIS 以及 SQL Server。為了返回已編譯的 .aspx 頁，身份驗證和授權都在客戶端、IIS 和 SQL Server 之間進行。有時候這***程也會簡化，例如在 SQL Server 與 IIS 位于同一物理服務器中的情況下使用 NTLM 進行身份驗證時。在這種情況下，從客戶端到 IIS 只有一個躍點。有關 .NET 中的身份驗證的詳細信息，請參閱解釋：ASP.NET 2.0 中的 Windows 身份驗證。

NTLM 和 Kerberos

現在您已經了解了 Windows Server、IIS 和 .NET 用于對用戶進行身份驗證和授權的基礎機制，下面我們將說明如何通過這種機制使用 NTLM 和 Kerberos 進行集成 Windows 身份驗證。正如上文所述，NTLM 和 Kerberos 之間的關鍵差異在于：NTLM 使用質詢/響應機制，在訪問每個網絡資源時都需要進行身份驗證和授權；而 Kerberos 則使用票證系統，只需進行一次身份驗證，然后通過委派進行授權。如果您不太明白這一差異，也不要擔心，下面我將進行詳細說明。圖 2 說明了 SharePoint 在使用 NTLM 時如何處理請求。

圖 2 SharePoint 中的 NTLM 身份驗證

如圖 2 所示，使用 NTLM 需要一個能夠對用戶進行身份驗證的域控制器。如果域在本機模式下運行，則默認情況下必須在域控制器或另一個服務器上有一個全局編錄。除了雙躍點問題之外，這也是一個潛在的性能問題，因為在與域控制器取得聯系之后，如果本地沒有全局編錄可用，則會通過代理將身份驗證請求發送到全局編錄服務器。在鏈路速度緩慢的情況下，這可能會消耗大量的資源和帶寬。您可以想法設法提高 NTLM 身份驗證的性能，例如通過更改 MaxConcurrentApi 注冊表項的值，但這無法解決 NTLM 需要依賴質詢/響應方案的根本需求，也無法解決高負載下的相關性能問題。

同一域中的帳戶的 NTLM 身份驗證的詳細信息如下所示：

1. 流程按上文所述的方式開始，客戶端瀏覽器利用 HTTP GET 請求來初始化與運行帶有 .NET 的 IIS 的 SharePoint 前端服務器的連接，并嘗試以匿名方式進行身份驗證。
2. IIS 拒絕匿名請求，返回 401.2 錯誤，并發回使用 NTLM (WWW-Authenticate: NTLM) 進行身份驗證的請求。
3. 客戶端瀏覽器接收該請求，并調用 InitializeSecurityContext 以創建包含域和計算機名稱的身份驗證令牌，然后將該身份驗證令牌發送到 IIS。
4. IIS 接受詳細信息，并向客戶端發送 NTLM 質詢。
5. 客戶端利用已用用戶密碼進行了加密的質詢響應（即身份驗證令牌）進行響應。
6. 此時，IIS 需要與域控制器會話。它發送客戶端的用戶名、質詢和質詢響應。
7. 域控制器檢索用戶的密碼哈希，并將其與使用用戶憑據加密的質詢響應進行比較。如果兩者匹配，域控制器將向 IIS 返回身份驗證成功消息，IIS 可與客戶端瀏覽器會話。
8. 此時，Web 應用程序將向 SQL Server 進行身份驗證，可以訪問包含 .aspx 頁數據的內容數據庫。

如果您曾經嘗試在“管理中心”網頁上為基本安裝配置 Kerberos，那么您便知道，如果選擇 Kerberos 而不是 NTLM，生成的消息將提示您配置應用程序池帳戶以明確允許使用 Kerberos，除非應用程序池正在網絡服務上下文中運行。這是因為基于 Kerberos 的身份驗證的工作方式需要 SPN。在 WSS 和 MOSS 中，Web 應用程序實際上是分配給應用程序池的 IIS 網站，在內置或用戶帳戶上下文中運行。可以為同一應用程序池分配多個網站，但這并不是***做法。除非您進行更改，否則 IIS 會將網絡服務帳戶用于應用程序池，而不使用唯一域帳戶。但是，若要在 SharePoint 中使用 Kerberos，必須針對應用程序池帳戶設置唯一 SPN。

在實踐中，基于 Kerberos 的通信必須具有一個客戶端、一個能夠支持 Kerberos 的服務器以及充當中間授權方的 KDC，此外還需要 SPN。技術細節稍微有些復雜。例如，Kerberos 還要求 DNS 與 Active Directory 或帶有 SRV 記錄、TCP/IP 和時間服務的 BIND 集成。如果您使用的是集成了 DNS 的 Windows Server 2003 或 2008，則您已經擁有了必需組件，只需配置這些組件即可。圖 3 顯示了 SharePoint 中基于 Kerberos 的身份驗證所涉及的各個組件以及數據流。

圖 3 Kerberos 身份驗證

1. 與 NTLM 相同，客戶端瀏覽器使用主機名（FQDN 或別名）以匿名方式發出 HTTP GET 請求。
2. 前端服務器響應，返回 401.2 錯誤以及 WWW-Authenticate: Negotiate 頭和/或 WWW-Authenticate: Kerberos 頭（表明它支持 Kerberos 身份驗證）。您必須在管理中心中顯式配置前端服務器上的此設置，相關內容將在下文討論。
3. 客戶端與域控制器上的 KDC 聯系，并基于瀏覽器客戶端以主機名的形式發送的信息為 SPN 請求票證。
4. 如果 KDC 找到匹配的 SPN，它將對票證進行加密并將其返回。
5. 瀏覽器客戶端創建身份驗證器，并將其與服務票證一同發送到 IIS 服務器。隨后，IIS 服務器對票證進行解密，確定身份，并檢查其對所請求資源的權限（訪問控制列表），確定是否允許訪問。
6. 如果允許訪問，IIS 將通過 Web 應用程序服務聯系 SQL Server，該服務將從 KDC 請求 SQL Server 票證。
7. 如果找到 SPN，KDC 將返回票證，Web 應用程序使用該票證來查詢內容數據庫，并通過委派模擬用戶。
8. SQL Server 檢查來自 Web 應用程序的票證，并驗證該票證。驗證成功后，SQL Server 將數據發送回服務器，.NET 將能夠編譯 aspx 頁，并將其發送到瀏覽器。

了解 SPN

SPN 是 Kerberos 配置中難度較大的環節之一，因為它們要作為被授權訪問特定服務器資源的客戶端資源的唯一標識符注冊到 KDC。在集成 Windows 身份驗證中，客戶端和服務器必定信任 KDC，因為在幾乎所有情況下，KDC 還是域控制器，它需要一種方法來確定是否為請求授予票證，這種方法就是 SPN。正如上文所述，當您為應用程序池設置域用戶帳戶時，還必須針對帳戶設置 SPN，以便讓所有人都能訪問與應用程序池關聯的 Web 應用程序。

SPN 是在服務器上運行的服務的唯一標識符字符串。它存儲在 Active Directory 中用戶帳戶的名為 Service-Principal-Name 的多值屬性中。一臺主機或多臺主機上的多項服務可以根據它們的唯一 SPN 進行區分。也許我過分強調了 SPN 的重要性，但這樣做是有充分理由的。配置不當的 SPN 會破壞 Kerberos 身份驗證。如果您設置了兩個相同的 SPN，或者忘記設置 SPN，或者錯誤配置了 SPN 的某一部分，則身份驗證將無法正常進行。

讓我們來看一個 SPN 示例，以了解 Kerberos 如何使用 SPN。SPN 包括三個部分：標識服務類型的服務類、運行服務的主機的計算機名稱、端口。這幾個部分組合在一起，語法為：服務類/主機:端口。對于 SharePoint，有兩個相關名稱是 HTTP 和 MSSqlSvc。這兩個服務名稱不是任意的，而是定義為服務的特定別名。主機名部分是 FQDN 或 NetBIOS 名稱，可以選擇是否包括端口。注冊 SPN 時，***做法是同時為 NetBIOS 和 FQDN 主機名注冊 SPN，以便無論客戶端使用什么方法，它們都可以訪問目標主機上的資源。

在上文中，我曾提到除非在網絡服務帳戶下運行應用程序池，否則就需要顯式注冊 SPN。這是因為當計算機加入到 Active Directory 域時，將自動為計算機帳戶創建 SPN，其格式為 HOST/<NetBIOSname> 和 HOST/<FQDN>。由于網絡服務帳戶作為網絡上的一臺計算機，因此 SPN 對它有效。但是，出于安全考慮，再加上本地帳戶可能會破壞某些方案，因此使用本地網絡服務帳戶并不是***做法。例如，如果您要還原或附加使用網絡服務帳戶配置的內容數據庫，則必須將該帳戶添加到 SQL Server 上的本地管理員組，在附加數據庫之后再將其刪除。大多數現有文檔推薦使用域帳戶。

后端配置

無論您是從現有場遷移，還是安裝新場，您都必須首先在 SQL Server 上配置 Kerberos 身份驗證。SQL Server 必須滿足上文所述的要求，例如加入到域、可以訪問充當 KDC 的域控制器等。對于大多數環境而言，當使用集成了 DNS 的 Active Directory 時，在默認情況下可以滿足這些要求。如果您的環境僅使用前端 SharePoint 服務器，而沒有使用應用程序服務器（例如運行 Excel Services 或 SQL Reporting Services 的服務器），則不需要顯式配置 Kerberos。對于基本的前端/后端連接，在 SQL Server 加入到域時創建的默認 SPN 足以滿足要求。

在 SQL Server 上，配置 Kerberos 相對比較簡單。首先，您要設置相關 SPN，然后驗證使用的是否是 Kerberos 而不是默認的 NTLM。您應該設置 NetBIOS 名稱和 FQDN，格式為 MSSQLSvc/<NetBIOS_Name>:1433 和 MSSQLSvc//<FQDN-hostname.domain.local>:1433，此處假定您的實例使用默認的 1433 端口。雖然您可以使用 setspn 工具或 ADSIEdit 來設置 SPN，但 setspn 通常是更好的選擇，因為它可以驗證輸入的語法，以確保輸入正確。相反，使用 ADSIEdit 時，您要直接將 SPN 寫入 servicePrincipalName 屬性。若要創建兩個 SPN，請運行setspn-A MSSQLSvc/<NetBIOS_Name>:1433 <domain>\<username> 和 setspn-A MSSQLSvc/<FQDNe>:1433 <domain>\<username>，其中用戶名為 SQL Server 服務帳戶。

若要確認 SQL Server 流量使用的是 Kerberos，您可以使用 Wireshark 等數據包分析器跟蹤流量，也可以使用 Kerbtray.exe 等工具，或者檢查事件日志。如果您使用 SQL Server Management Studio 連接到 SQL 實例，則安全事件日志將顯示事件 ID 540，其中的登錄進程和身份驗證數據包使用 Kerberos。有關詳細信息，請參閱為 SQL 通信配置 Kerberos 身份驗證。

前端和應用程序服務器配置

確保 Kerberos 在 SQL Server 中正常工作后，接下來您可以配置 SharePoint，包括為應用程序池設置 SPN，為 SSP 和 Web 應用程序啟用 Kerberos，并完成一些最終配置步驟。SPN 配置類似于 SQL Server 服務帳戶的配置，但需要配置更多的 SPN。回顧一下，SPN 是基于用戶在客戶端瀏覽器地址欄中輸入的地址構造的，因此您必須為用戶可能在地址欄中輸入以訪問網站的每個條目設置 SPN。這包括采用主機頭格式的 FQDN、NetBIOS 名稱和別名。圖 4 列出了資源類型示例以及需要為每個資源類型注冊的 SPN。

圖 4 基本 MOSS 場的 SPN

在設置 SPN 時，應該記住一些注意事項。首先，SPN 要注冊到啟用 SharePoint 的網站，正如要注冊到任何 IIS 網站那樣。重要的是指定正確的主機名和帳戶，每個網站的應用程序池在該帳戶下運行。如果使用多個主機頭，請確保為所有主機頭設置 SPN。第二，不需要指定 HTTP 和 HTTPS 端口，但應該指定任何自定義端口。第三，您可能還需要配置其他一些依賴關系，例如配置針對 IIS 的注冊表更改以支持帶有自定義端口的 SPN 格式，以及配置更新以支持 SSP。您可以在配置 Kerberos 身份驗證 (Office SharePoint Server) 中找到更多詳細信息。

若想讓 Kerberos 在環境中正常工作，您還應該完成另外兩個重要步驟。您必須配置用于委派的計算機帳戶和一些服務帳戶，還必須在管理中心為 Kerberos 配置場。Kerberos 中的委派的原理是：如果用戶向最終資源發出請求，則一些中介帳戶必須處理該請求，這些中介帳戶是可信任的，能夠代表用戶進行委派。可以將 Active Directory 用戶和計算機作為域管理員，從而來配置用于委派的帳戶。在用戶或計算機帳戶的“委派”選項卡下，選擇“信任此用戶/計算機來委派任何服務(Kerberos)”。您應該為前端、應用程序和 SQL Server 計算機帳戶啟用委派，還應為應用程序池（SSPAdmin、MySite、各種 Web 應用程序）和場服務帳戶啟用委派。

此外，您還需要在“組件服務”中設置權限。在默認屬性下，將“模擬級別”設置為“委派”。在“IIS WAMREG Admin Service”下，定位到“安全”選項卡，為應用程序池帳戶授予“本地激活”權限。有關詳細信息，請參閱知識庫文章 917409 和 920783。

啟用委派后，即可通過啟用 Kerberos 作為 SSP 和 Web 應用程序的***協議來完成具體的配置工作。對于新安裝，可以在 SharePoint 產品和技術配置向導中為管理中心網站進行此操作。否則，請在管理中心的“應用程序管理”下定位到“驗證提供程序”，單擊“默認值”并將方法設置為“協商(Kerberos)”。不要忘記運行 iisreset /noforce，將更改應用于應用程序池，并為 SSP 啟用 Kerberos。

IIS 7 和 Windows Server 2008 中的變化

截止目前，我們討論的內容主要限于 Windows Server 2003 和 IIS 6 上的 SharePoint 2007。如果您遷移到 Windows Server 2008 和 IIS 7，則在體系結構上有一些變化，可能需要其他一些配置步驟。IIS 7 中的最顯著變化也許是它支持內核模式 Kerberos 身份驗證。在內核模式身份驗證中，網絡服務帳戶（實際上就是上文所述的計算機帳戶）將對票證進行解密，除非您指定了其他設置。當您遷移到 IIS 7 或安裝一個新場時，默認情況下將啟用內核模式身份驗證。正如上文所述，網絡服務帳戶是本地帳戶。如果運行的是單個服務器，則解密可以正常進行。但在場中，解密會失敗，因為您需要使用可以通過 KDC 驗證的域帳戶。這一變化還意味著您可以使用網絡服務帳戶進行協議轉換（允許客戶端向 IIS 進行非 Kerberos 身份驗證，允許 IIS 將 Kerberos 用于后端通信），因為該帳戶已經具有 LocalSystem 權限。

若要在運行 IIS 7 的 SharePoint 場中配置 Kerberos，需要手動更改 %WinDir%\System32\inetsrv\config\ApplicationHost.config 文件 — 當前沒有 GUI 選項。相關條目如下所示。

<system.webServer>
   <security>
      <authentication>
         <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
     </authentication>
   </security>
</system.webServer>

不要忘記運行 iisreset /noforce 以應用更改，并檢查***更新以發現問題，例如在知識庫文章 962943 中詳細說明的藍屏更新。

如果您的配置使用了身份模擬（web.config 中的 <identity impersonate="true" />）和集成模式管道，則還應注意另外一個配置細節。在此情況下，需要將 validateIntegratedModeConfiguration 設置為 false，或在經典模式管道中運行 .aspx 頁。

結論

雖然 Kerberos 身份驗證需要一些額外配置步驟，還需要 NTLM 之外的更多知識，但目前的趨勢是向 Kerberos 遷移。Microsoft 在 II7 中將 Kerberos 作為默認選中選項，并且為 Kerberos 提供了良好的支持，因為它是一個開放的標準。使用 Kerberos 物有所值。現在有大量文檔介紹 Kerberos 的部署、驗證和故障排除，這也為我們實際使用 Kerberos 提供了支持。您無需進行很多更改即可避免由于過多身份驗證躍點而導致的性能下降問題，享受 Kerberos 的良好安全性。

原文：http://technet.microsoft.com/zh-cn/magazine/ee914605.aspx

來源：微軟TechNet中文站