當使用者屬於多個群組時，Kerberos 的驗證問題

本文可協助您解決當使用者屬於許多群組時，Kerberos 驗證失敗的問題。

適用於：Windows 10 - 所有版本、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2
原始 KB 編號： 327825

徵狀

屬於大量安全組的使用者在驗證時發生問題。 驗證時，使用者可能會看到訊息，例如 HTTP 400 - 不正確的要求 (要求標頭太長，) 。 使用者在存取資源時也遇到問題，而且使用者的 群組原則 設定可能無法正確更新。

如需錯誤內容的詳細資訊，請參閱 HTTP 400 不正確的要求 (要求標頭太長) HTTP 要求的回應。

此行為會在任何目前支援的 Windows 版本中發生。 如需目前支援之 Windows 版本的資訊，請參閱 Windows 生命週期事實表。

原因

使用者無法驗證，因為 Kerberos 建置來代表使用者的票證不夠大，無法包含所有使用者的群組成員資格。

在 驗證服務 Exchange 中，Windows 會建置令牌來代表用戶進行授權。 此令牌 (也稱為授權內容) 包括使用者的 SID) (安全識別碼，以及使用者所屬所有群組的 SID。 它也包含儲存在用戶帳戶 sIDHistory 屬性中的任何 SID。 Kerberos 會將此令牌儲存在 Kerberos Ticket-Getting 票證 (TGT) 的許可權屬性憑證 (PAC) 資料結構中。 從 Windows Server 2012 開始，Kerberos 也會將令牌儲存在 Kerberos 票證中動態 存取控制) 數據結構 (Active Directory 宣告資訊中。 如果使用者是大量群組的成員，而且如果使用者或正在使用的裝置有許多宣告，這些欄位可能會佔用票證中的大量空間。

令牌具有固定的大小上限 (MaxTokenSize) 。 遠端過程調用 (RPC) 和 HTTP 等傳輸通訊協定會在為驗證作業配置緩衝區時依賴 MaxTokenSize 值。 MaxTokenSize 根據建置令牌的 Windows 版本，具有下列預設值：

• Windows Server 2008 R2 和更早版本，以及 Windows 7 和更早版本：12,000 個字節
• Windows Server 2012 和更新版本，以及 Windows 8 和更新版本：48,000 個字節

一般而言，如果使用者屬於超過120個通用群組，則預設 MaxTokenSize 值不會建立夠大的緩衝區來保存資訊。 使用者無法驗證，而且可能會收到 記憶體不足的 訊息。 此外，Windows 可能無法為使用者套用 群組原則 設定。

解決方案

若要解決此問題，請在參與 Kerberos 驗證程式的每部電腦上更新登錄，包括客戶端電腦。 建議您更新所有以 Windows 為基礎的系統，特別是當您的用戶必須跨多個網域或樹系登入時。

在每部計算機上，將登錄專案設定 MaxTokenSize 為較大的值。 您可以在子機碼中 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters 找到這個專案。 進行這項變更之後，計算機必須重新啟動。

如需判斷 的新值的 MaxTokenSize詳細資訊，請參閱本文的 計算令牌大小上限 一節。

例如，假設使用者使用依賴 SQL Server 用戶端的 Web 應用程式。 在驗證程式中，SQL Server 用戶端會將使用者的令牌傳遞至後端 SQL Server 資料庫。 在這裡情況下，您必須在 MaxTokenSize 下列每部計算機上設定登錄專案：

• 執行 Internet Explorer 的用戶端電腦
• 執行 IIS 的 Web 伺服器
• SQL Server客戶端電腦
• SQL Server 資料庫計算機

在 Windows Server 2012 (和更新版本) 中，如果令牌大小超過特定閾值，Windows 可以將事件記錄 (事件標識碼 31) 。 若要啟用此行為，您必須設定 群組原則 設定大型 Kerberos 票證的電腦設定\系統管理範本\System\KDC\Warning。

計算令牌大小上限

使用下列公式來計算 Windows 為特定用戶產生的令牌大小。 此計算可協助您判斷是否需要變更 MaxTokenSize。

TokenSize = 1200 + 40d + 8s

針對 Windows Server 2012 (和更新版本) ，此公式會定義其元件，如下所示：

• 1200。Kerberos 票證的估計額外負荷值。 視 DNS 功能變數名稱的長度和用戶端名稱的長度等因素而定，此值可能會有所不同。
• d. 下列值的總和：
  • 用戶帳戶網域外部的通用群組成員資格數目。
  • 儲存在帳戶 sIDHistory 屬性中的 SID 數目。 此值會計算群組成員資格和使用者 SID。
• s. 下列值的總和：
  • 用戶帳戶網域內的通用群組成員資格數目。
  • 網域本機群組中的成員資格數目。
  • 全域群組中的成員資格數目。

Windows Server 2008 R2 和舊版使用相同的公式。 不過，這些版本會將網域本機群組成員資格的數目視為 d 值的一部分，而不是 的 值。

如果您的 MaxTokenSize 值 為 0x0000FFFF (64K) ，您可能可以緩衝處理大約 1600 d 類別 SID 或大約 8000 s 類別 SID。 不過，有一些其他因素會影響您可以安全地用於的 MaxTokenSize值，包括下列各項：

• 如果您 使用信任的委派 帳戶，每個 SID 都需要兩倍的空間。

• 如果您有多個信任，請設定信任以篩選 SID。 此設定可減少 Kerberos 票證大小的影響。

• 如果您使用 Windows Server 2012 或更新版本，下列因素也會影響 SID 空間需求：

  • 有新的配置可在 PAC 中壓縮 SID。 如需詳細資訊，請參閱 KDC 資源 SID 壓縮。 這項功能可減少票證中 SID 所需的大小。
  • 動態 存取控制 會將Active Directory 宣告新增至票證，以增加大小需求。 不過，使用 Windows Server 2012 檔案伺服器部署宣告之後，您可能會預期會淘汰大量控制檔案存取的群組。 這項縮減可進而減少票證所需的大小。 如需詳細資訊，請參閱動態 存取控制：案例概觀。

• 如果您已將 Kerberos 設定為使用不受限制的委派，則必須將公式中的值加倍 TokenSize ，才能取得的有效估計 MaxTokenSize值。

  重要事項

  在 2019 年，Microsoft 將更新運送至 Windows，將 Kerberos 的未限制委派的預設設定變更為停用。 如需詳細資訊，請參閱在 Windows Server 中跨傳入信任 匯報 TGT 委派。

  由於廣泛使用資源 SID 壓縮，且不受限制的委派已被取代， MaxTokenSize 因此 48000 或更大的 48000 應該就足以應付所有案例。

影響 MaxTokenSize的已知問題

MaxTokenSize 48,000 個字節的值應該足以用於大部分的實作。 這是 Windows Server 2012和更新版本中的預設值。 不過，如果您決定使用較大的值，請檢閱本節中的已知問題。

• LSA 存取令牌的 1,010 個群組 SID 大小限制

  此問題類似於具有太多群組成員資格的使用者無法驗證，但控管問題的計算和條件不同。 例如，使用者在使用 Kerberos 驗證或 Windows NTLM 驗證時可能會遇到此問題。 如需詳細資訊，請參閱在 Windows Server 計算機上登入屬於超過 1,010 個群組成員的用戶帳戶可能會失敗。

• 使用大於 48,000 的 MaxTokenSize 值時的已知問題

  為了減輕阻斷服務攻擊媒介，Internet Information Server (IIS) 使用 64 KB 的有限 HTTP 要求緩衝區大小。 屬於 HTTP 要求一部分的 Kerberos 票證會編碼為 Base64 (6 位擴充為 8 位) 。 因此，Kerberos 票證會使用其原始大小的 133%。 因此，當 IIS 中的緩衝區大小上限為 64 KB 時，Kerberos 票證可以使用 48,000 個字節。

  如果您將登錄專案設定 MaxTokenSize 為大於 48000 個字節的值，且緩衝區空間用於 SID，則可能會發生 IIS 錯誤。 不過，如果您將登錄項目設定 MaxTokenSize 為 48,000 個字節，而且您使用 SID 和宣告的空間，就會發生 Kerberos 錯誤。

  如需 IIS 緩衝區大小的詳細資訊，請參閱 如何限制 IIS 從 Windows 2000 中用戶端接受的 HTTP 傳輸標頭大小。

• 使用大於 65,535 的 MaxTokenSize 值時的已知問題

  本文的舊版討論 的值最多為 100,000 個字節 MaxTokenSize。 不過，我們發現SMS系統管理員的版本在100,000個字節或更大時 MaxTokenSize 發生問題。

  我們也發現 IPSEC IKE 通訊協定不允許安全性 BLOB 大於 66,536 個字節，而且當 設定為較大的值時 MaxTokenSize 也會失敗。