MaxConcurrentApi 設定を使用して NTLM 認証のパフォーマンス チューニングを行う方法

  • [アーティクル]

この記事では、MaxConcurrentApi 設定を使用して NTLM 認証のパフォーマンス チューニングを行う方法について説明します。

適用対象: Windows Server 2012 R2
元の KB 番号: 2688798

概要

企業情報技術のコンシューマー化 (企業企業で使用されるスマートフォンやタブレットなどのコンシューマー向けデバイスの増加) の増加により、企業が企業環境でレガシ認証が大幅に増加するシナリオが増えています。 レガシ認証の増加により、クライアントの遅延やタイムアウトなどのパフォーマンスの問題が発生する可能性があります。

環境で認証のタイムアウトまたは遅延 (MaxConcurrentApi ボトルネックとも呼ばれます) を検出すると、この問題を解決する一般的な方法は、認証を行うワーカー スレッドの許可最大数を上げることです。 これを行うには、MaxConcurrentApi レジストリ値を変更してから、サーバー上の Net Logon サービスを再起動します。

ボトルネックの影響を受けるサーバーと、ボトルネックの遅延の原因となるサーバーを特定するのは困難な場合があります。 この記事では、MaxConcurrentApi 設定を使用して NT LAN Manager (NTLM) 認証のパフォーマンス チューニングを行う方法について説明します。 この記事では、MaxConcurrentApi 値を上げるサーバーとその値を設定する必要がある量を特定する管理者向けのガイダンスについて説明します。

解決方法

重要

このセクション、方法、またはタスクには、レジストリの編集方法が記載されています。 レジストリを誤って変更すると、深刻な問題が発生することがあります。 レジストリを変更する際には十分に注意してください。 保護を強化するため、レジストリを変更する前にレジストリをバックアップします。 こうしておけば、問題が発生した場合にレジストリを復元できます。 レジストリのバックアップ方法および復元方法の詳細を参照するには、以下のサポート技術情報番号をクリックしてください。
322756 Windows でレジストリをバックアップおよび復元する方法

この問題を解決するには、シナリオに関係するすべてのサーバーから取得されたパフォーマンス データを確認する必要があります。 その後、パフォーマンスの低下を示すサーバーの MaxConcurrentApi 設定を増やすことができます。

NTLM 認証の Netlogon 問題を報告するイベントがあります。次を参照してください。
2654097 Windows Server 2008 R2 で NTLM 認証の遅延とエラーを追跡する新しいイベント ログ エントリを使用できます

イベントは、次の 2 つのカウンターのアクティビティを示します。

  • イベント 5818/5819: イベントが有効になっている場合、"セマフォ ウェイター" があります。
  • イベント 5816/5817: "セマフォ タイムアウト" があります。

サーバーに最適な MaxConcurrentApi 値を決定するには、数式を使用して複数のデータ ポイントをまとめ、計算する必要があります。 MaxConcurrentApi の見積もりに使用するデータは次のとおりです。

  • Net Logon セマフォの取得
  • Net Logon セマフォのタイムアウト
  • Net Logon 平均セマフォホールドタイム
  • 完了したパフォーマンス ログの期間 (秒単位)

データを取得した後、次の数式を使用して、正しい MaxConcurrentApi 値を推定できます:(semaphore_acquires + semaphore_time アウト) * average_semaphore_hold_time time_collection_length / =<New_MaxConcurrentApi_setting
サーバーが認証の負荷を受けていたときから Net Logon パフォーマンス データを収集した後、ライン ビューの開始時刻と終了時刻を確認して、データ収集プロセスの期間を決定する必要があります。

注:

semaphore_acquiresとsemaphore_timeアウトのプレースホルダーは、セキュリティ チャネルの有効期間中に発生したタイムアウトの数を示す累積値を表します。 したがって、収集されるデータでは、数値がゼロから始まる可能性が最も高くなります。 パフォーマンス モニター (Perfmon.msc) で行ビューを使用する場合は、開始番号を終了番号から減算する必要があります。 次に、新しい MaxConcurrentApi 設定の数式で、この計算された数値を使用します。 データ収集中に発生したタイムアウトの数を確認するには、Perfmon.msc の Line View を使用し、末尾と開始位置のカウンターの行の上にマウス ポインターを置き、終了番号から開始番号を減算します。 その結果は、数式に入れる数値です。

平均セマフォのホールド タイムは、Perfmon.msc の既定のビューを [ライン ビュー] から [レポート ビュー] に変更することで決定できます。 たとえば、次のようなシナリオについて考えてみます。

  • セマフォが取得する値は 8,286 です。
  • セマフォのタイムアウト値は 883 です。
  • セマフォの平均ホールド時間は .5 (つまり、5 分の 1 秒) です。
  • レポートの期間は 90 秒です。

このシナリオでは、数式は次のようになります。
(8,286 + 883) *.5 / 90 =< 51

数式から派生した値が 150 以上の場合は、レガシ認証の負荷に対応するためにサーバーを追加する必要があります。

値が 150 未満の場合は、そのサーバーの MaxConcurrentApi レジストリ値を、数式で提案される値またはより大きい値に変更する必要があります。

注:

MaxConcurrentApi の値を 10 より大きくする場合は、運用環境で変更を実装する前に、非運用環境で目的の設定の負荷とパフォーマンスをテストする必要があります。 これは、この値を増やすことで他のリソースのボトルネックが発生しないようにすることをお勧めします。 また、各シナリオとビジネス環境に基づいて読み込み条件が変化する可能性があることに注意してください。 そのため、サービスの読み込みが変更された場合は、後で MaxConcurrentApi 値に別の設定が必要になる場合があります。

MaxConcurrentApi 設定を変更するには、次の手順に従います。

  1. [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。

  2. 次のレジストリ サブキーを見つけてクリックします。HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters

  3. [編集] メニューの [新規] をポイントし、[DWORD 値] をクリックします。

  4. 「MaxConcurrentApi」と入力し、Enter キーを押します。

  5. [編集] メニューの [変更] をクリックします。

  6. 新しい MaxConcurrentApi 設定を 10 進数で入力し、[OK] をクリック します。

  7. コマンド プロンプトで、次のコマンドを入力し、Enter キーを押します。
    net stop netlogon

  8. 次のコマンドを入力し、Enter キーを押します。
    net start netlogon

詳細

次のサポート技術情報の記事を使用して、レガシ認証のボトルネックのクライアント側の症状を詳しく確認できます。
975363 認証されたサービスに接続すると、資格情報の入力を断続的に求められたり、タイムアウトが発生したりします。このシナリオでは、認証のボトルネックが複数のサーバー上にある可能性があります。 そのため、特定のシナリオのすべてのサーバーが、負荷の高いサービスを行っている間にパフォーマンス データが確認されていることを確認する必要があります。

セマフォの取得、セマフォのタイムアウト、および平均セマフォホールド時間のカウンターは、クライアント要求のサービスに関連するすべてのアプリケーション サーバー、ドメイン コントローラー、および信頼されたドメイン コントローラーで確認する必要があります。

サーバーの負荷が高い間、パフォーマンス データを追跡する必要があります。 サーバーで最も多くのクライアント要求が表示されると、負荷が高い場合に発生します。 たとえば、電子メール サーバーのシナリオでは、パフォーマンス データを収集する最適なタイミングは、ユーザーが職場に到着し、電子メール メッセージをチェックするときです。

考慮すべきその他の項目は次のとおりです。

  • 値なしは、アクションが必要ないことを意味します。 セマフォホルダーカウンターとセマフォホールドタイムカウンターは、サーバーに持続的な負荷がない限り値を表示しません。 値が存在しない場合は、MaxConcurrentApi 値の変更は必要ありません。

  • 1 つのサイズがすべてに収まるわけではありません。 MaxConcurrentApi の値は、サーバーごとに異なる値である必要があります。 この状況は、複数のアプリケーション サーバーが 1 つのドメイン コントローラーから認証を受ける場合や、複数のサーバーでドメイン コントローラーが処理する必要がある大量の負荷を提供する同様のシナリオによって発生する可能性があります。

  • 信頼。 認証されているユーザーが信頼されたドメインからのユーザーである場合は、ローカル ドメイン コントローラーがアプリケーション サーバーに応答を提供する前に、ローカル ドメイン コントローラーが信頼されたドメイン コントローラーからの応答を待機する必要があるため、遅延が長くなる可能性があります。

  • ネットワーク待機時間。 ネットワーク待機時間は、MaxConcurrentApi のボトルネックを引き起こす際にも大きな役割を果たす可能性があります。 この問題は、クライアントがレガシ認証を無期限に待機しないように、MaxConcurrentApi セマフォが時間ベースのタイムアウト カウンターを使用する場合に発生する可能性があります。

  • コロケーション。 ネットワーク待機時間が存在し、MaxConcurrentApi スレッドを完了する際に遅延とボトルネックが発生している場合、一般的な解決策は、ネットワーク待機時間が短縮されるように、サーバーを同じ物理的な場所に配置することです。 たとえば、信頼されたドメインに Microsoft Exchange CAS サーバーがあり、ユーザーのドメインが別のリージョンまたは Active Directory サイトにあるドメイン モデルでは、ユーザーのドメイン コントローラーを Exchange CAS サーバーとそのドメイン コントローラーと同じ物理的な場所と Active Directory サイトに配置することを意味します。

  • ダウンストリーム遅延の可能性があります。 セマフォウェイターカウンター値が常に0(ゼロ)を超え続け、セマフォホルダーの値がそのサーバーのMaxConcurrentApi設定よりも小さい場合、ボトルネックはそのサーバー上にありません。 この場合は、ホスト コンピューターの完全修飾ドメイン名として一覧表示されているカウンター名に記載されているドメイン コントローラーを確認します。 そのドメイン コントローラーの セマフォ ウェイター と セマフォ ホルダー のパフォーマンス データを確認する必要があります。

  • 読み込みまたはネットワーク構成の変更。 サービスまたはネットワーク構成の負荷の今後の変更により、ネットワーク待機時間が発生する可能性があり、正しい MaxConcurrentApi 設定をもう一度測定する必要が生じる可能性があります。 従来の認証ボリュームが、MaxConcurrentApi 設定が調べられている範囲で確認される環境では、Net Logon パフォーマンス オブジェクト カウンターを継続的に監視して確認することを強くお勧めします。 これを行うには、スケジュールされたカスタム Perfmon.msc データ コレクターを使用するか、Microsoft System Center Operations Manager を使用するか、他の方法を使用します。

  • Windows Server 2008 の最大値。 Windows Server 2008 以降のバージョンの Windows で MaxConcurrentApi に許可される最大設定は 150 です。 使用しているサーバーが Windows Server 2008 R2 を実行していない場合は、次のサポート技術情報の記事に記載されている修正プログラムを適用して、使用可能な最大 150 個の設定を設定します。
    975363 認証されたサービスに接続すると、資格情報またはエクスペリエンスのタイムアウトが断続的に求められます

  • Windows Server 2003 の最大値。 Windows Server 2003 以前のバージョンの MaxConcurrentApi で許可されている最大設定は 10 です。

  • Windows Server 2012以降の既定値。 MaxConcurrentApi の既定値は、Windows Server 2012で変更されました。 メンバー サーバーとドメイン コントローラーの場合は 10 です。 メンバー ワークステーションの場合は 1 のままです。

  • Windows Server 2003 とパフォーマンス カウンター。 Windows Server 2003 の元のリリースには、Net Logon パフォーマンス カウンターが含まれていませんでした。 修正プログラムを適用して追加できます。

NTLM 認証全体の負荷を軽減し、最終的に MaxConcurrentApi セマフォの使用数を減らす場合は、NTLM 認証を繰り返し実行している未承認のクライアントまたは不明なクライアントまたはサービスを特定すると便利です。 この方法で繰り返し認証を行う場合は、Net Logon サービスのデバッグ ログを使用します。 Netlogon.log ファイルを使用して Net Logon サービスをデバッグする方法の詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を表示してください。
109626 Net Logon サービスのデバッグ ログの有効化

Security System-Wide Statistics オブジェクトの NTLM 認証の Perfmon.msc カウンターは、MaxConcurrentApi 追跡スレッドの使用回数を反映したものではありません。 Net Logon パフォーマンス カウンターに表示される MaxConcurrentApi セマフォの使用状況と NTLM 認証カウンターの増分の間には、1 対 1 の相関関係はありません。 NTLM 認証カウンターは、最適な MaxConcurrentApi 値を決定するのに役立ちません。

さらに、MaxConcurrentApi に関連するレガシ認証のパフォーマンス タイムアウトが表示されますが、Net Logon カウンター以外のパフォーマンス カウンターには反映されない可能性があります。 つまり、CPU 使用率やディスク、ネットワークの使用などの他のパフォーマンス メトリックでは、MaxConcurrentApi の負荷が高く、ユーザーに問題が発生している場合でも、負荷が表示されない可能性があります。

Net Logon サービスのデバッグ ログにエントリがあるドメイン コントローラーで、クライアントが ではなく送信していることを示す追加のdomainname\username最小化手順を<null>\username実行できます。 この手順については、Microsoft サポート技術情報の次の記事を参照してください。
923241 Active Directory ドメイン コントローラーに多数の外部信頼がある場合、Lsass.exe プロセスの応答が停止する可能性があります