Microsoft SharePoint 2010 產品的 Kerberos 驗證概觀

 

適用版本: SharePoint Server 2010

上次修改主題的時間: 2016-11-30

Microsoft SharePoint 2010 產品針對如何在平台中管理身分識別引入大量增強功能。您必須了解這些變更如何影響方案設計和平台設定,才能將需要使用者身分識別的案例委派給整合系統。Kerberos 第 5 版通訊協定在啟用委派中扮演重要的角色,且這些案例有時會需要此通訊協定。

這些文章提供提供您資訊,以協助您執行下列作業:

  • 了解 SharePoint 2010 產品的身分識別概念

  • 了解 Kerberos 驗證如何在驗證和委派案例中扮演非常重要的角色

  • 識別應該利用或方案設計可能需要 Kerberos 驗證的情況

  • 在環境中設定端對端 Kerberos 驗證,包括在 SharePoint Server 中使用各種服務應用程式的案例

  • 測試及驗證 Kerberos 驗證正確設定且如預期運作

  • 尋找其他工具和資源,以協助您在環境中設定 Kerberos 驗證

這些文章分為兩大部分:

  • SharePoint 2010 產品的 Kerberos 驗證概觀

    本文包含如何在 SharePoint 2010 產品中管理身分識別、Kerberos 通訊協定,以及 Kerberos 驗證如何在 SharePoint 2010 方案中扮演重要角色的概念性資訊。

  • 逐步設定

    這組文章討論在各種 SharePoint 方案案例中設定 Kerberos 驗證和委派所需的步驟。

誰應該閱讀這些關於 Kerberos 驗證的文章?

SharePoint 2010 產品的身分識別和委派是很廣泛的主題,包含許多需要理解的面向和深度。這些文章處理的主題同時涵蓋概念性和技術性層級,並且專為因應各類讀者群的需求所撰寫:

從頭開始

「告訴我有關 SharePoint 2010 產品之身分識別和 Kerberos 驗證的所有須知」

如果您才剛開始並想了解 SharePoint 2010 產品、Kerberos 驗證及宣告驗證,您可以閱讀本文件的第一節。該節涵蓋身分識別和委派的基本概念,並提供宣告驗證和 Kerberos 驗證的入門。請務必遵循外部文章及其他資訊的連結,以建立可靠的知識基礎,再繼續閱讀逐步設定文章。

從 Office SharePoint Server 2007 升級

「告訴我 2007 版以來的變更,以及升級至 2010 版所需的準備」

如果您的現有 Microsoft Office SharePoint Server 2007 環境已設定為使用 Kerberos 驗證和 Kerberos 委派,您應該閱讀下列文章:

  • SharePoint 2010 產品的身分識別案例

  • 宣告入門

  • Windows 2008 R2 和 Windows 7 的 Kerberos 驗證變更

  • SharePoint 2010 產品的 Kerberos 設定變更

  • 從 SharePoint Server 2007 升級時的考量

如果您有其他關於如何為特定功能或案例設定委派的問題,請閱讀逐步設定文章,特別是設定檢查清單,以協助您在升級後確定環境正確設定。

逐步解說

「我需要如何在 SharePoint Server 及適用的 SharePoint Server 服務應用程式中設定 Kerberos 委派的詳細逐步指示」

逐步設定文章涵蓋數個可設定為使用 Kerberos 委派的 SharePoint 2010 產品案例。每個案例會有詳細的說明,並包含設定檢查清單和逐步指示,以協助您在環境中成功設定 Kerberos 驗證。涵蓋的案例包括:

請務必徹底檢閱第一個核心設定案例,因為這是後續所有案例的先決條件。

注意

這些案例包含 "SetSPN" 命令,您可以選擇從本文件複製並貼到 [命令提示字元] 視窗中。這些命令包含連字號字元。Microsoft Word 的 [自動格式設定] 功能往往會將連字號轉換成破折號字元。如果您在 Word 中開啟了這項功能,然後執行複製及貼上作業,這些命令將無法正常執行。將破折號變更為連字號可以修正此錯誤。若要關閉 Word 的 [自動格式設定] 功能,請從 [檔案] 功能表中選取 [選項],然後按一下 [校對] 索引標籤,再開啟 [自動校正] 對話方塊。

現有的 SharePoint 2010 產品環境

「我已有 SharePoint 2010 產品環境,但是似乎無法讓 Kerberos 驗證運作,我該如何驗證及偵錯設定?」

逐步設定>文章包含數個檢查清單,可協助以不同的案例分級環境。請特別注意案例 1:核心設定,該案例涵蓋可分級 Kerberos 設定的基本工具和技術。

SharePoint 2010 產品的身分識別案例

了解 SharePoint 2010 產品之驗證內容中的身分識別時,您可以從概念上檢視平台在三個主要案例中如何處理身分識別:傳入驗證、伺服器陣列之間/伺服器陣列內部的驗證,以及傳出驗證。

伺服器陣列驗證圖表

傳入身分識別

傳入驗證案例表示用戶端向平台表明身分的方式,亦即「驗證」Web 應用程式或 Web 服務。SharePoint Server 會使用用戶端的身分識別,來授權用戶端存取 SharePoint Server 加密的資源,例如網頁、文件等。

SharePoint 2010 產品支援兩種用戶端驗證平台的模式:傳統模式和宣告模式。

傳統模式

傳統模式允許您可能在舊版 SharePoint Server 中已熟悉的一般 Internet Information Services (IIS) 驗證方法。將 SharePoint Server 2010 Web 應用程式設定為使用傳統模式時,您可以選擇使用下列 IIS 驗證方法:

整合式 Windows 驗證

整合式 Windows 驗證可讓 Windows 用戶端流暢地使用 SharePoint Server 進行驗證,而不用手動提供認證 (使用者名稱/密碼)。使用者若從 Internet Explorer 存取 SharePoint Server,將使用執行 Internet Explorer 程序所用的認證,進行驗證;根據預設,這些認證即是使用者用於登入桌面的認證。在 Windows 整合模式下存取 SharePoint Server 的服務或應用程式,會嘗試使用執行中之執行緒的認證 (根據預設,此即是該程序的身分識別) 進行驗證。

NTLM

選取整合式 Windows 驗證時,NT LAN Manager (NTLM) 是預設通訊協定類型。此通訊協定利用三部分挑戰-回應序列驗證用戶端。如需 NTLM 的詳細資訊,請參閱 Microsoft NTLM (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196643&clcid=0x404) (可能為英文網頁)。

優點:

  • 容易設定,且一般不需要其他基礎結構/環境設定即可運作

  • 用戶端不屬於網域時,或不在 SharePoint Server 所在網域信任的網域時,也可以執行

缺點:

  • 每次用戶端驗證回應需要驗證,都需要 SharePoint Server 連絡網域控制站,因此會增加網域控制站的流量。

  • 不允許將用戶端認證委派給後端系統 (又稱為雙重躍點規則)。

  • 此為專屬通訊協定。

  • 不支援伺服器驗證。

  • 比 Kerberos 驗證更不安全

Kerberos 通訊協定

Kerberos 通訊協定是支援票證驗證的更安全通訊協定。如果用戶端電腦驗證要求包含有效使用者認證和有效服務主要名稱 (SPN),Kerberos 驗證伺服器就會授與票證,以回應這些要求,然後用戶端電腦便可使用票證存取網路資源。若要啟用 Kerberos 驗證,用戶端與伺服器電腦必須擁有網域金鑰發佈中心 (KDC) 的信任連線。KDC 會發佈共用秘密金鑰來啟用加密。用戶端與伺服器電腦還必須能夠存取 Active Directory 網域服務。在 Active Directory 中,樹系根網域即是 Kerberos 驗證轉介的中心。如需 Kerberos 通訊協定的詳細資訊,請參閱 Kerberos 第 5 版驗證通訊協定運作方式 (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196644&clcid=0x404) (可能為英文網頁) 及 Microsoft Kerberos (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x404) (可能為英文網頁)。

優點:

  • 最安全的整合式 Windows 驗證通訊協定

  • 允許委派用戶端認證

  • 支援手動驗證用戶端和伺服器

  • 產生較少的網域控制站流量

  • 開啟許多平台和廠商支援的通訊協定

缺點:

  • 需要其他基礎結構和環境設定以正常運作

  • 需要用戶端透過 TCP/UDP 連接埠 88 (Kerberos) 和 TCP/UDP 連接埠 464 (Kerberos 變更密碼 - Windows) 連線至 KDC (Windows 環境中的 Active Directory 網域控制站)

其他方法

除了 NTLM 和 Kerberos 驗證之外,SharePoint Server 支援其他類型的 IIS 驗證,例如基本、摘要及認證型驗證,本文件中將不會涵蓋。如需這些通訊協定之運作方式的詳細資訊,請參閱 IIS 6.0 中支援的驗證方法 (IIS 6.0) (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196646&clcid=0x404) (可能為英文網頁)。

宣告式驗證

宣告驗證支援是 SharePoint 2010 產品的新功能,並根據 Windows Identity Foundation (WIF) 所建置。在宣告模型中,SharePoint Server 接受有關驗證用戶端識別及授權用戶端的一或多個「宣告」。宣告採用 SAML 權杖的形式,是由受信任的授權單位敘述的用戶端相關事實。例如,宣告內容可能是「Bob 為網域 Contoso.com 之 Enterprise Admins 群組的成員」。如果此宣告來自 SharePoint Server 信任的提供者,平台可以使用此資訊驗證 Bob,並授權其存取 SharePoint Server 資源。如需宣告驗證的詳細資訊,請參閱宣告式身分識別及存取控制指南 (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=187911&clcid=0x404) (可能為英文網頁)。

SharePoint 2010 產品支援用於傳入驗證的宣告類型包括 Windows 宣告、表單型驗證宣告及 SAML 宣告。

Windows 宣告

在 Windows 宣告模式登入中,SharePoint Server 使用標準整合式 Windows 驗證 (NTLM/Kerberos) 對用戶端進行驗證,然後將產生的 Windows 身分識別轉譯為宣告身分識別。

表單型驗證宣告

在表單型驗證宣告模式中,SharePoint Server 會將用戶端重新導向至主控標準 ASP.NET 登入控制項的登入頁面。此頁面使用 ASP.NET 成員資格和角色提供者驗證用戶端,類似表單型驗證在 Office SharePoint Server 2007 中的運作方式。建立代表使用者的身分識別物件之後,SharePoint Server 會接著將此身分識別轉譯為宣告身分識別物件。

SAML 宣告

在 SAML 宣告模式中,SharePoint Server 會接受來自受信任外部安全性權杖提供者 (STS) 的 SAML 權杖。當使用者嘗試登入時,詳見註解會導向至外部宣告提供者 (例如 Windows Live ID 宣告提供者),以驗證使用者並產生 SAML 權杖。SharePoint Server 接受並處理此權杖,以增強宣告並建立使用者的宣告身分識別物件。

如需 SharePoint 2010 產品之宣告式驗證的詳細資訊,請參閱 SharePoint 宣告式身分識別 (可能為英文網頁)

傳入宣告驗證及「對 Windows Token 服務的宣告」(C2WTS) 的注意事項

某些服務應用程式需要您使用 Windows Identity Foundation (WIF) 的「對 Windows Token 服務的宣告」(C2WTS),將伺服器陣列內的宣告轉譯為 Windows 認證,以輸出驗證。您必須了解 C2WTS 僅適用於傳入驗證方法為傳統模式或 Windows 宣告時。如果設定宣告,C2WTS 僅需要 Windows 宣告;Web 應用程式不可以使用多種形式的 Web 應用程式宣告,這麼做會導致 C2WTS 無法運作。

SharePoint 2010 產品環境內的身分識別

SharePoint 2010 產品環境使用宣告驗證,進行內外部伺服器陣列之間與大多數 SharePoint 服務應用程式和 SharePoint 整合產品的通訊,而不論所使用的傳入驗證機制為何。這表示即使使用傳統驗證對特定 Web 應用程式進行驗證,SharePoint 產品也會將傳入身分識別轉換成宣告身分識別,以驗證宣告感知 (Claims-Aware) 的 SharePoint 服務應用程式和產品。透過標準化內外伺服器陣列之間通訊的宣告模型,平台可以從使用的連入通訊協定摘要本身。

注意

某些與 SharePoint Server 整合的產品 (例如 SQL Server Reporting Services) 不是宣告感知 (Claims-Aware) 產品,因此不會利用內部伺服器的宣告驗證架構。SharePoint Server 在其他案例中,也可能會依賴傳統 Kerberos 委派和宣告;例如,當 RSS 檢視器網頁組件設定為使用驗證的摘要時。請參閱每項產品或服務應用程式的文件,以判斷其是否可以支援宣告式驗證和身分識別委派。

輸出身分識別

SharePoint 2010 產品的輸出身分識別,表示伺服器陣列內的服務必須驗證外部企業營運系統和服務的情況。視情況而定,您可以使用下列兩種基本概念性模型之一來執行驗證:

受信任子系統

在受信任子系統中,前端服務驗證並授權用戶端,再驗證其他後端服務,但不會將用戶端身分識別傳遞給後端系統。後端系統「信任」前端服務代表它執行驗證和授權。實作此模型的最常用方式為使用共用服務帳戶驗證外部系統:

信任的子系統圖表

在 SharePoint Server 中,此模型可以多種方式實作:

  • 使用 IIS 應用程式集區識別 - 其達成方式通常是在 Web 應用程式中執行程式碼以提升權限,同時呼叫外部系統。其他方法 (例如使用 RevertToSelf) 也可以使用應用程式集區識別,來驗證外部系統。

  • 使用服務帳戶 - 其達成方式通常是在 Secure Store 中儲存應用程式認證,然後使用這些認證驗證外部系統。其他方法包括以內嵌連線字串等其他方式,來儲存服務帳戶認證。

  • 匿名驗證 - 外部系統不需要任何驗證。因此前端 SharePoint Server 服務不需要將任何身分識別傳遞給後端系統。

委派

在委派模型中,前端服務先驗證用戶端,然後使用用戶端的身分識別驗證其他執行各自驗證和授權的後端系統:

委派程序圖表

在 SharePoint 2010 產品 中,此模型可以多種方式實作:

  • Kerberos 委派 - 如果用戶端使用 Kerberos 驗證對前端服務進行驗證,Kerberos 委派可用來將用戶端的身分識別傳遞給後端系統。

  • 宣告 - 只要兩個服務之間彼此信任,且兩者皆為宣告感知 (Claims-Aware) 服務,宣告驗證即可在服務之間傳遞用戶端的宣告。

注意

目前,SharePoint Server 隨附的大部分服務應用程式不允許輸出宣告驗證,但是輸出宣告是未來會使用的平台功能。此外,今日許多常見的企業營運系統不支援傳入宣告驗證,亦即輸出宣告驗證可能無法使用,或需要其他開發才可以正常運作。

跨網域和樹系界限的委派

這些文章中有關 Kerberos 驗證的案例需要 SharePoint Server 服務和外部資料來源位於相同的 Windows 網域中,這對 Kerberos 限制委派為必要。Kerberos 通訊協定支援兩種委派類型:基本 (非限制) 和限制。基本 Kerberos 委派可以跨單一樹系中的網域界限,但是不論信任關係為何,皆無法跨樹系界限。Kerberos 限制委派在任何情況下,皆無法跨網域或樹系界限。

某些 SharePoint Server 服務可以設定為使用基本 Kerberos 委派,但是其他服務需要您使用限制委派。所有依賴「對 Windows Token 服務的宣告」(C2WTS) 的服務都必須使用 Kerberos 限制委派,才可以讓 C2WTS 使用 Kerberos 通訊協定轉換將宣告轉譯為 Windows 認證。

下列服務應用程式和產品需要 C2WTS 和 Kerberos 限制委派:

  • Excel Services

  • PerformancePoint Services

  • InfoPath Forms Services

  • Visio Services

下列服務應用程式和產品不受這些需求的影響,因此可以視需要使用基本委派:

  • Business Data Connectivity Service 及 Microsoft Business Connectivity Services

  • Access Services

  • Microsoft SQL Server Reporting Services (SSRS)

  • Microsoft Project Server 2010

下列服務應用程式不允許委派用戶端認證,因此不受這些需求的影響:

  • Microsoft SQL Server PowerPivot for Microsoft SharePoint

宣告入門

如需宣告概念和宣告式驗證的簡介,請參閱宣告簡介 (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196648&clcid=0x404) (可能為英文網頁) 及 SharePoint 宣告式身分識別 (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196647&clcid=0x404) (可能為英文網頁)。

Kerberos 通訊協定入門

如需 Kerberos 通訊協定的概念性概觀,請參閱 Microsoft Kerberos (Windows) (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196645&clcid=0x404) (可能為英文網頁)、Kerberos 說明 (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196649&clcid=0x404) (可能為英文網頁) 及詢問目錄服務小組:忙碌管理員適用的 Kerberos (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196650&clcid=0x404) (可能為英文網頁)。

Kerberos 通訊協定的好處

查看使用者如何設定 SharePoint Server (或任何 Web 應用程式) 使用 Kerberos 通訊協定的詳細資訊之前,請先概述 Kerberos 通訊協定及您想使用的原因。

一般而言,使用 Kerberos 通訊協定的主要原因有三個:

  1. 用戶端認證委派 - Kerberos 通訊協定可讓服務模擬用戶端的身分識別,以允許模擬服務代表用戶端將該身分識別傳遞給其他網路服務。NTLM 不允許此委派 (此 NTLM 限制稱為「雙重躍點規則」)。宣告驗證類似 Kerberos 驗證,可用來委派用戶端認證,但是需要後端應用程式為宣告感知 (Claims-Aware) 應用程式。

  2. 安全性 - AES 加密、手動驗證、資料完整性及資料隱私權的支援等功能,讓 Kerberos 通訊協定比其 NTLM 對應更安全。

  3. 可能提升效能 - Kerberos 驗證需要比 NTLM 更少的網域控制站流量 (視 PAC 驗證而定,請參閱 Microsoft 開放規格支援小組部落格:了解 Microsoft Kerberos PAC 驗證 (可能為英文網頁))。如果停用或不需要 PAC 驗證,驗證用戶端的服務不需要對 DC 進行 RPC 呼叫 (請參閱:當您在 Windows 2000 或 Windows Server 2003 的網域成員上執行高容量伺服器程式時,於使用者驗證程序中發生延遲)。Kerberos 驗證在用戶端與伺服器之間的流量也比 NTLM 少。與使用 NTLM 的一般三向信號交換相較下,用戶端可以透過雙向要求/回應來驗證網頁伺服器。然而,在個別交易的低延遲網路上,一般不會注意到此增強功能,而是在整體系統輸送量中才會注意到。請記住,許多環境因素會影響驗證效能;因此,在決定哪個方法的執行效能較佳之前,您應該在自己的環境中測試 Kerberos 驗證和 NTLM 的效能。

這是使用 Kerberos 通訊協定的不完整優點清單,還有其他原因,例如手動驗證、跨平台交互操作性,以及可跨網域轉移信任等。然而在大多數情況下,委派和安全性一般還是使用者採用 Kerberos 通訊協定的主要驅策因素。

Kerberos 委派、限制委派及通訊協定轉換

Windows 平台上的 Kerberos 第 5 版通訊協定支援兩種身分識別委派類型:基本 (非限制) 委派和限制委派:

類型 優點 缺點

基本委派

  • 可跨單一樹系中的網域界限

  • 需要比限制委派更少的設定。

  • 不支援通訊協定轉換

  • 安全。如果前端服務遭到入侵,用戶端身分識別可以委派給樹系中接受 Kerberos 驗證的任何服務。

限制委派

  • 可將非 Kerberos 傳入驗證通訊協定轉換成 Kerberos (範例:NTLM 轉換成 Kerberos、宣告轉換成 Kerberos)

  • 更安全。身分識別僅可委派給指定的服務。

  • 無法跨網域界限

  • 需要其他安裝程式設定

啟用 Kerberos 的服務可以跨多個服務和躍點多次委派身分識別。當身分識別穿梭於不同服務時,委派方法可以從基本變更為限制,但是無法從限制變更為基本。您必須了解此重要的設計詳細資訊:如果後端服務需要基本委派 (例如跨網域界限委派),後端服務的所有前端服務都必須使用基本委派。如果任何前端服務使用限制委派,後端服務無法將限制權杖變更為非限制權杖,以跨網域界限。

通訊協定轉換可讓啟用 Kerberos 的驗證服務 (前端服務) 將非 Kerberos 身分識別轉換成 Kerberos 身分識別,以委派給其他啟用 Kerberos 的服務 (後端服務)。通訊協定轉換需要 Kerberos 限制委派,因此轉換通訊協定的身分識別無法跨網域界限。根據前端服務的使用者權限,通訊協定轉換傳回的 Kerberos 票證可以是識別權杖或模擬權杖。如需限制委派和通訊協定轉換的詳細資訊,請參閱下列文章:

一般最佳作法是在需要 Kerberos 委派時,儘可能使用限制委派。如果需要跨網域界限進行委派,則委派路徑中的所有服務都必須使用基本委派。

Windows 2008 R2 和 Windows 7 的 Kerberos 驗證變更

Windows Server 2008 R2 和 Windows 7 引入 Kerberos 驗證的新功能。如需變更概觀,請參閱 Kerberos 驗證的變更 (https://go.microsoft.com/fwlink/?linkid=196655&clcid=0x404) 及 Kerberos 增強功能 (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196656&clcid=0x404) (可能為英文網頁)。此外,即使 SharePoint Server 伺服器陣列不支援,您也應該熟悉 IIS 7.0 核心模式驗證 (Internet Information Services (IIS) 7.0 核心模式驗證設定 (可能為英文網頁) (https://go.microsoft.com/fwlink/?linkid=196657&clcid=0x404) (可能為英文網頁))。

SharePoint 2010 產品的 Kerberos 設定變更

在 SharePoint 2010 產品中設定 Kerberos 驗證的大多數基本概念未變更。您仍然必須設定服務主要名稱,也仍然必須在電腦和服務帳戶上進行委派設定。但是,有幾項變更值得注意:

  • 限制委派 - 使用「對 Windows Token 服務的宣告」的服務需要此委派。要讓通訊協定轉換將宣告轉換成 Windows Token,就必須透過限制委派。

  • 服務應用程式 - 在 Office SharePoint Server 2007 中,SSP 服務需要特殊 SPN 及伺服器登錄變更,才可啟用委派。在 SharePoint 2010 產品中,服務應用程式使用宣告驗證及「對 Windows Token 服務的宣告」,因此不再需要這些變更。

  • Windows Identity Foundation (WIF) - WIF 的「對 Windows Token 服務的宣告」(C2WTS) 是 SharePoint 2010 產品 在委派時,將宣告轉換成 Windows Token 所利用的新服務。

從 Office SharePoint Server 2007 升級時的考量

如果將 Office SharePoint Server 2007 伺服器陣列升級至 SharePoint Server 2010,請在完成升級後考量下列幾點:

  • 如果 Web 應用程式變更 URL,請務必更新服務主要名稱以反映 DNS 名稱。

  • 刪除 SSP 服務主要名稱,因為 SharePoint Server 2010 不再需要。

  • 在執行需要委派之服務應用程式 (例如 Excel Services、Visio Graphics Service) 的伺服器上,啟動「對 Windows Token 服務的宣告」。

  • 將 Kerberos 限制委派設定為 [使用任何驗證通訊協定],讓 Kerberos 限制委派可以使用 C2WTS。

  • 確定已在 IIS 中停用核心模式驗證。