Kerberos 設定已知的問題 (SharePoint Server 2010)

  • 發行項

 

適用版本： SharePoint Server 2010

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

Kerberos 驗證和非預設連接埠

已知問題是嘗試驗證設定於非預設連接埠 (非 80 和 443 的連接埠) 上已啟用 Kerberos 的 Web 應用程式時，部分 Kerberos 用戶端 (包括 .NET Framework、Internet Explorer 7 和 8) 無法正確地形成服務主要名稱。問題的根本原因是用戶端沒有透過指定無連接埠號碼的 SPN，在 TGS 要求中適當地形成 SPN (如 TGS 要求的 Sname 中所述)。

範例：

如果 Web 應用程式是在 http://intranet.contoso.com:1234 執行，則用戶端會使用等於 http/intranet.contoso.com 的 SPN 要求服務的票證，而非 http/intranet.contoso.com:1234。

您可以在下列文章中找到問題的詳細資料：

若要解決此問題，請登錄具有或不具有連接埠號碼的 SPN。範例：

  • http/intranet

  • http/intranet.contoso.com

  • http/intranet:12345

  • http/intranet.contoso.com:12345

建議登錄非預設連接埠，確定如果問題在未來某個 Service Pack 或 Hotfix 中解決，則使用解決方法的應用程式還是可以繼續運作。

請注意，如果存在下列條件，則解決方法無法作用：

  • 非預設連接埠上執行一個以上的 Web 應用程式

  • Web 應用程式繫結至伺服器的主機名稱，或繫結至相同主機標頭 (在不同的連接埠上)

  • Web 應用程式 IIS 應用程式集區使用不同的服務帳戶

如果這些條件存在，則遵循此解決方法中的建議會產生不同服務帳戶登錄重複的 SPN，因而中斷 Kerberos 驗證。

如果您有在多個連接埠上共用一個通用主機名稱的多個網站，而且針對 Web 應用程式使用不同的 IIS 應用程式集區身分識別，則無法在所有網站上使用 Kerberos 驗證 (其中一個應用程式可以使用 Kerberos，而其餘應用程式需要另一個驗證通訊協定)。在此案例中，若要於所有應用程式上使用 Kerberos，則需要：

  1. 使用 1 個共用服務帳戶來執行所有 Web 應用程式

  2. 使用網站自己的主機標頭執行每個網站

Kerberos 驗證和 DNS CNAME

嘗試驗證已啟用 Kerberos 的服務，且該服務設定成使用 DNS CNAME (非 A 記錄) 解決，部分 Kerberos 用戶端 (包括 Internet Explorer 7 和 8) 會具有已知問題。問題的根本原因是用戶端不會透過使用主機名稱 (A 記錄) 而非別名 (CNAME) 來建立 SPN，進而在 TGS 要求中形成正確地 SPN。

範例：

A 記錄：wfe01.contoso.com

CNAME：intranet.contoso.com (別名 wfe01.contoso.com)

如果用戶端嘗試驗證 http://intranet.contoso.com，則用戶端不但不會正確地形成 SPN，也不會要求 http/wfe01.contoso.com 的 Kerberos 票證，而是要求 http/intranet.contoso.com

您可以在下列文章中找到問題的詳細資料：

https://support.microsoft.com/kb/911149/zh-tw

https://support.microsoft.com/kb/938305/zh-tw

若要解決此問題，請使用 DNS A 記錄而非 CNAME 別名來設定已啟用 Kerberos 的服務。KB 文章中提及的 Hotfix 會更正 Internet Explorer 的這個問題，但無法更正 .NET Framework (Microsoft Office SharePoint Server 用來進行 Web 服務通訊) 的問題。

Kerberos 驗證和核心模式驗證

注意

SharePoint 2010 產品不支援核心模式驗證。此資訊僅供參考。

從 IIS 7.0 版開始，具有稱為核心模式驗證的新驗證功能。IIS 網站設定成使用核心模式驗證時，HTTP.sys 會驗證用戶端的要求，而非應用程式集區的工作者處理序。因為 HTTP.sys 是以核心模式執行，所以這會產生較佳的效能，但是在設定 Kerberos 時也會更為複雜。原因是 HTTP.sys 是以電腦的身分識別執行，而非工作者處理序的身分識別。HTTP.sys 接收 Kerberos 票證時，預設會嘗試使用伺服器的加密金鑰 (也稱為秘密) 來解密票證，而非用來執行工作者處理序之身分識別的金鑰。

如果單一 Web 伺服器設定成使用核心模式驗證，則伺服器在新增至網域時會自動登錄 HOST SPN，因此 Kerberos 不會使用任何其他設定或其他 SPN。如果多個 Web 伺服器進行載入平衡，則預設核心模式驗證設定不會運作，或者，因為用戶端沒有方法可確定在 TGS 要求中所接收的服務票證會使用驗證要求的伺服器，所以至少會間歇地失敗。

若要解決此問題，您可以執行下列動作：

Kerberos 驗證和工作階段驗證

您可能會注意到在透過 IIS 7.0 和更新版本使用 Kerberos 驗證時，驗證流量增加。這可能是與 IIS 中的 Windows 驗證設定相關，特別是：

AuthPersistNonNTLM

選用 Boolean 屬性。

指定 IIS 是否自動重新驗證每個非 NTLM (例如，Kerberos) 要求，包括相同連線上的非 NTLM。True 會啟用相同連線的多個驗證。

預設值為 False。

注意

False 設定表示在相同的連線上只會驗證一次用戶端。IIS 會快取伺服器上已建立之 TCP 工作階段的 Token 或票證。

authPersistSingleRequest

選用 Boolean 屬性。

將此旗標設定為 True，可對某個連線上的單一要求指定持續驗證。IIS 會在每個要求結束時重設驗證，並強制在工作階段的下一個要求重新驗證。

預設值為 False。

如需如何在 IIS 7.0 中設定持續性驗證的指示，請參閱在 IIS 7.0 中搭配使用整合式 Windows 驗證與 Kerberos 驗證通訊協定時，效能可能會變慢和實作存取控制 (可能為英文網頁)。

Kerberos 驗證和重複/遺漏 SPN 問題

設定 Kerberos 驗證時，很容易就會不小心設定重複的服務主要名稱，尤其是使用 SetSPN -A 或 ADSI 編輯器 (adsiedit.msc) 工具建立 SPN 時。一般建議是使用 SetSPN -S 建立 SPN，原因是 -S 參數會在建立指定的 SPN 之前檢查是否有重複的 SPN。

如果您懷疑環境中有重複的 SPN，請使用 SetSPN -X 命令查詢環境中的所有重複的 SPN (僅限 Windows 2008 或更新版本)。如果傳回任何 SPN，則您應該調查 SPN 的登錄原因，並刪除任何重複和不需要的 SPN。如果您的兩個服務是使用兩個不同的身分識別來執行，而且都使用相同的 SPN (重複 SPN 問題)，則需要將其中一個服務重新設定成使用不同的 SPN，或共用通用服務身分識別。

如果您懷疑未登錄 SPN，或未以需要的格式進行登錄，則可以使用 SetSPN -Q <插入 SPN> 來查詢特定 SPN 是否存在。

Kerberos 最大 Token 大小

在部分環境中，使用者可能是多個 Active Directory 群組的成員，這樣會增加其 Kerberos 票證的大小。如果票證成長地太大，則 Kerberos 驗證可能會失敗。如需如何調整最大 Token 大小的詳細資訊，請參閱 使用者屬於多個群組時 Kerberos 驗證問題的新解決方法 (https://support.microsoft.com/kb/327825/zh-tw)。

注意

調整最大 Token 大小時，請注意，如果您設定的最大 Token 大小超出登錄設定的最大值，則可能會看到 Kerberos 驗證錯誤。建議最大 Token 大小不要超出 65535 (十進位)、FFFF (十六進位)。

Windows Server 2008 和 Windows Vista 的 Kerberos 驗證 Hotfix

使用 AES 演算法時，Kerberos 驗證在執行 Windows Server 2008 或 Windows Vista 的電腦上失敗，且錯誤碼為 0X80090302 或 0x8009030f (https://support.microsoft.com/kb/969083/zh-tw) 時。

您可能需要在環境中執行 Windows Server 2008 或 Windows Vista 的所有電腦上，安裝 Kerberos 驗證的 Hotfix。這包括執行 SharePoint Server 2010、SQL Server 或 Windows Server 2008 (SharePoint Server 嘗試使用 Kerberos 驗證來進行驗證) 的所有電腦。如果您發現支援案例所述的徵狀，請遵循支援頁面中的指示以套用 Hotfix。