ユーザーが多数のグループに属している場合の Kerberos 認証の問題

この記事は、ユーザーが多数のグループに属している場合の Kerberos 認証エラーの問題を解決するのに役立ちます。

適用対象: Windows 10 - すべてのエディション、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2
元の KB 番号: 327825

現象

多数のセキュリティ グループに属しているユーザーの認証に問題があります。 認証時に、 HTTP 400 - 無効な要求 (要求ヘッダーが長すぎる) などのメッセージが表示されることがあります。 また、ユーザーはリソースへのアクセスに問題があり、ユーザーのグループ ポリシー設定が正しく更新されない可能性があります。

エラーのコンテキストの詳細については、「HTTP 要求に対する HTTP 400 無効な要求 (要求ヘッダーが長すぎる)応答」を参照してください。

この動作は、現在サポートされている Windows バージョンのいずれかで発生します。 現在サポートされているバージョンの Windows の詳細については、「 Windows ライフサイクルのファクト シート」を参照してください。

原因

Kerberos がユーザーを表すために作成するチケットが、ユーザーのすべてのグループ メンバーシップを含むのに十分な大きさではないため、ユーザーは認証できません。

認証サービス Exchange の一部として、Windows は承認のためにユーザーを表すトークンを構築します。 このトークン (承認コンテキストとも呼ばれます) には、ユーザーのセキュリティ識別子 (SID) と、ユーザーが属しているすべてのグループの SID が含まれます。 また、ユーザー アカウント sIDHistory の属性に格納されているすべての SID も含まれます。 Kerberos は、Kerberos Ticket-Getting チケット (TGT) の特権属性証明書 (PAC) データ構造にこのトークンを格納します。 Windows Server 2012以降、Kerberos では、Kerberos チケットの Active Directory 要求情報 (動的Access Control) データ構造にもトークンが格納されます。 ユーザーが多数のグループのメンバーであり、使用されているユーザーまたはデバイスに対するクレームが多数ある場合、これらのフィールドはチケット内の多くのスペースを占有する可能性があります。

トークンの最大サイズは固定です (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 する必要があります。

• インターネット エクスプローラーを実行しているクライアント コンピューター
• IIS を実行している Web サーバー
• SQL Server クライアント コンピューター
• SQL Server データベース コンピューター

Windows Server 2012 (以降のバージョン) では、トークン サイズが特定のしきい値を超えた場合、Windows はイベント (イベント ID 31) をログに記録できます。 この動作を有効にするには、大きな Kerberos チケットに対してコンピューターの構成\管理用テンプレート\System\KDC\Warning を設定するグループ ポリシーを構成する必要があります。

最大トークン サイズの計算

次の数式を使用して、Windows が特定のユーザーに対して生成するトークンのサイズを計算します。 この計算は、 を変更 MaxTokenSizeする必要があるかどうかを判断するのに役立ちます。

TokenSize = 1200 + 40d + 8s

Windows Server 2012 (以降のバージョン) の場合、この数式では、そのコンポーネントを次のように定義します。

• 1200。 Kerberos チケットの推定オーバーヘッド値。 この値は、DNS ドメイン名の長さやクライアント名の長さなどの要因によって異なる場合があります。
• d. 次の値の合計。
  • ユーザーのアカウント ドメインの外部にあるユニバーサル グループのメンバーシップの数。
  • アカウントの属性に格納されている SID の sIDHistory 数。 この値は、グループ メンバーシップとユーザー SID をカウントします。
• s. 次の値の合計。
  • ユーザーのアカウント ドメイン内にあるユニバーサル グループ内のメンバーシップの数。
  • ドメイン ローカル グループ内のメンバーシップの数。
  • グローバル グループのメンバーシップの数。

Windows Server 2008 R2 以前のバージョンでは、同じ数式が使用されます。 ただし、これらのバージョンでは、ドメイン ローカル グループ メンバーシップの数が、s 値ではなく d 値の一部であると見なされます。

0x0000FFFF (64K) の値があるMaxTokenSize場合は、約 1600 d クラスの SID または約 8000 s クラスの SID をバッファーできます。 ただし、その他の要因の多くが、 に安全に使用 MaxTokenSizeできる値に影響を与えます。これには、次のものが含まれます。

• 委任アカウントに信頼済みを使用する場合、各 SID には 2 倍の領域が必要です。

• 複数の信頼がある場合は、SID をフィルター処理するように信頼を構成します。 この構成により、Kerberos チケット サイズの影響が軽減されます。

• Windows Server 2012以降のバージョンを使用している場合は、次の要因も SID 領域の要件に影響します。

  • PAC 内の SID を圧縮するための新しいスキームがあります。 詳細については、「 KDC リソース SID 圧縮」を参照してください。 この機能により、チケット内の SID に必要なサイズが縮小されます。
  • 動的Access Controlは、Active Directory 要求をチケットに追加し、サイズ要件を増やします。 ただし、Windows Server 2012 ファイル サーバーで要求を展開した後は、ファイル アクセスを制御する多数のグループを段階的に除外することが予想されます。 この縮小により、チケットに必要なサイズを減らすことができます。 詳細については、「動的Access Control: シナリオの概要」を参照してください。

• 制約のない委任を使用するように Kerberos を構成している場合は、 の有効な見積もりMaxTokenSizeを取得するために、数式の値を 2 倍TokenSizeにする必要があります。

  重要

  2019 年、Microsoft は、Kerberos の制約のない委任の既定の構成を無効に変更した更新プログラムを Windows に配布しました。 詳細については、「Windows Server での受信信頼間の TGT 委任への更新」を参照してください。

  リソース SID の圧縮は広く使用されており、制約のない委任は非推奨であるため、 MaxTokenSize すべてのシナリオで 48000 以上で十分になります。

MaxTokenSize に影響する既知の問題

MaxTokenSizeほとんどの実装では、48,000 バイトの値で十分です。 これは、Windows Server 2012 以降のバージョンの既定値です。 ただし、より大きな値を使用する場合は、このセクションの既知の問題を確認してください。

• LSA アクセス トークンの 1,010 グループ SID のサイズ制限

  この問題は、グループ メンバーシップが多すぎるユーザーを認証できないが、問題を管理する計算と条件が異なる点で似ています。 たとえば、Kerberos 認証または Windows NTLM 認証を使用しているときに、この問題が発生する可能性があります。 詳細については、「 1,010 を超えるグループのメンバーであるユーザー アカウントのログオンが Windows Server ベースのコンピューターで失敗する可能性がある」を参照してください。

• 48,000 を超える MaxTokenSize の値を使用する場合の既知の問題

  サービス拒否攻撃ベクトルを軽減するために、インターネット インフォメーション サーバー (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 バッファー サイズの詳細については、「 Windows 2000 のクライアントから IIS が受け入れる HTTP 送信のヘッダー サイズを制限する方法」を参照してください。

• 65,535 を超える MaxTokenSize の値を使用する場合の既知の問題

  この記事の以前のバージョンでは、 の最大 100,000 バイト MaxTokenSizeの値について説明しました。 ただし、 が 100,000 バイト以上の場合 MaxTokenSize 、SMS 管理者のバージョンに問題があることがわかりました。

  また、IPSEC IKE プロトコルでは、セキュリティ BLOB が 66,536 バイトを超えることを許可せず、大きな値に設定されている場合 MaxTokenSize にも失敗することが確認されました。