次の方法で共有

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

  • [アーティクル]

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

元の KB 番号: 327825

現象

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

エラーのコンテキストの詳細については、「HTTP 400 Bad Request (Request Header too long) responses to HTTP requests」を参照してください。

Note

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

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

原因

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

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

Note

その他の要因は、グループの最大数にも影響します。 たとえば、グローバル グループとドメイン ローカル グループの 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) をログに記録できます。 この動作を有効にするには、グループ ポリシー設定 Computer Configuration\Administrative Templates\System\KDC\Warning for large Kerberos tickets を構成する必要があります。

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

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

TokenSize = 1200 + 40d + 8s

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

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

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

0x0000FFFF (64K) のMaxTokenSize値がある場合は、約 1600 クラス SID または約 8,000 クラス SID をバッファーできます。 ただし、他の多くの要因が、次のような MaxTokenSizeに安全に使用できる値に影響します。

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

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

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

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

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

    重要

    2019 年、Microsoft は、Kerberos の制約のない委任の既定の構成を無効に変更した更新プログラムを Windows に出荷しました。 詳細については、「 Updates to TGT delegation across incoming trusts in Windows Server」を参照してください。

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

MaxTokenSize に影響する既知の問題

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

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

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

  • 48,000 より大きい MaxTokenSize の値を使用する場合の既知の問題

    サービス拒否攻撃ベクトルを軽減するために、インターネット インフォメーション サーバー (IIS) では、64 KB の制限された HTTP 要求バッファー サイズが使用されます。 HTTP 要求の一部である Kerberos チケットは Base64 としてエンコードされます (6 ビットは 8 ビットに拡張されます)。 そのため、Kerberos チケットでは元のサイズの 133% が使用されます。 そのため、IIS の最大バッファー サイズが 64 KB の場合、Kerberos チケットでは 48,000 バイトを使用できます。

    MaxTokenSize レジストリ エントリを 48,000 バイトを超える値に設定し、バッファー領域を SID に使用すると、IIS エラーが発生する可能性があります。 ただし、 MaxTokenSize レジストリ エントリを 48,000 バイトに設定し、SID とクレームの領域を使用すると、Kerberos エラーが発生します。

    IIS バッファー サイズの詳細については、「 IIS が Windows 2000 でクライアントから受け入れる HTTP 送信のヘッダー サイズを制限する方法を参照してください。

  • 65,535 より大きい MaxTokenSize の値を使用する場合の既知の問題

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

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