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

  • [アーティクル]

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

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

現象

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

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

注:

同様の条件下では、Windows NTLM 認証は想定どおりに機能します。 Windows の動作を分析しない限り、Kerberos 認証の問題が表示されない場合があります。 ただし、このようなシナリオでは、Windows はグループ ポリシー設定を更新できない可能性があります。

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

原因

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

認証サービス Exchange の一環として、Windows は承認の目的でユーザーを表すトークンを構築します。 このトークン (承認コンテキストとも呼ばれます) には、ユーザーのセキュリティ識別子 (SID) と、ユーザーが属するすべてのグループの SID が含まれます。 また、ユーザー アカウント sIDHistory の属性に格納されているすべての SID も含まれます。 Kerberos は、Kerberos Ticket-Getting Ticket (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 では、ユーザーのグループ ポリシー設定を適用できない場合があります。

注:

その他の要因は、グループの最大数にも影響します。 たとえば、グローバル グループとドメイン ローカル グループの SID の領域要件は小さくなります。 Windows Server 2012以降のバージョンでは、Kerberos チケットに要求情報が追加され、リソース SID も圧縮されます。 どちらの機能も、スペース要件を変更します。

解決方法

この問題を解決するには、クライアント コンピューターを含め、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 はイベント (イベント ID 31) を記録できます。 この動作を有効にするには、コンピューター構成\管理用テンプレート\System\KDC\Warning for large Kerberos チケットを設定するグループ ポリシーを構成する必要があります。

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

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

TokenSize = 1200 + 40d + 8s

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

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

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

0x0000FFFF (64K) の値を持つMaxTokenSize場合は、約 1600 d クラスの SID または約 8,000 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をTokenSize取得するには、数式の値を 2 倍にする必要があります。

    重要

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

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

MaxTokenSize に影響を与える既知の問題

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

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

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

  • MaxTokenSize の値が 48,000 より大きい場合の既知の問題

    サービス拒否攻撃ベクトルを軽減するために、インターネット インフォメーション サーバー (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 転送のヘッダー サイズを制限する方法」を参照してください。

  • MaxTokenSize の値が 65,535 より大きい場合の既知の問題

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

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