MaxConcurrentApi 設定を使用して NTLM 認証のパフォーマンス調整を行う方法

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

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

はじめに

エンタープライズ 情報テクノロジのコンシューマ化の増加 (企業で使用されるスマートフォンやタブレットなどのコンシューマー向けデバイスの増加) は、企業が企業環境で従来の認証を大幅に増加するシナリオの数を増やしています。 従来の認証が増加すると、クライアントの遅延やタイム アウトなどのパフォーマンスの問題が発生する可能性があります。

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

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

解決方法

重要

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

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

NTLM Netlogon 認証の問題を報告するイベントがあります。以下を参照してください。
2654097サーバー 2008 R2 で NTLM 認証の遅延と障害を追跡する新しいイベント ログ エントリWindows利用可能

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

  • イベント 5818/5819: イベントが有効になっている場合、"Semaphore Waiters" があります。
  • イベント 5816/5817: "Semaphore Timeouts" があります。

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

  • Net Logon セマフォが取得する
  • Net Logon semaphore のタイム アウト
  • Net Logon の平均セマフォ保持時間
  • 完了したパフォーマンス ログの期間 (秒単位)

データを取得した後、次の数式を使用して、正しい MaxConcurrentApi 値を推定できます :( semaphore_acquires + semaphore_time-outs) * 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 認証済みサービスに接続するときに、資格情報の入力を求めるメッセージが断続的に表示される場合や、タイム アウトが発生する場合、認証ボトルネックがシナリオ内の複数のサーバーにある可能性があります。 したがって、特定のシナリオ内のすべてのサーバーが、負荷の高いサービスを行っている間にパフォーマンス データを確認する必要があります。

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

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

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

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

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

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

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

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

  • 考えられるダウンストリーム遅延。 Semaphore Waiters カウンター値が常に 0 (ゼロ) を超え 、Semaphore Holders 値がそのサーバーの MaxConcurrentApi 設定より小さい場合、ボトルネックは、そのサーバー上に位置しません。 この場合は、ホスト コンピューターの完全修飾ドメイン名としてリストされているカウンター名に含まれるドメイン コントローラーを確認します。 そのドメイン コントローラーの Semaphore Waiters と Semaphore Holders のパフォーマンス データを確認する必要があります。

  • 読み込みまたはネットワーク構成の変更。 サービス中またはネットワーク構成の負荷が今後変化すると、ネットワーク遅延が発生し、正しい MaxConcurrentApi 設定を再び測定する必要が生じ得る可能性があります。 従来の認証ボリュームが MaxConcurrentApi の設定が調べられる程度に見られる環境では、Net Logon パフォーマンス オブジェクト カウンターを継続的に監視して確認することを強く推奨します。 スケジュールされたカスタム Perfmon.msc データ コレクターを使用するか、Microsoft System Center Operations Manager を使用するか、他のメソッドを使用して実行できます。

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

  • Windowsサーバー 2003 の最大数。 サーバー 2003 以前のバージョンの MaxConcurrentApi でWindowsの最大設定は 10 です。

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

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

NTLM 認証の繰り返しおよび継続的な認証を実行している未承認または不明なクライアントまたはサービスを特定すると、NTLM 認証全体の負荷を軽減し、MaxConcurrentApi セマフォの使用回数を最終的に減らす場合に役立ちます。 その方法で繰り返し認証を行う場合は、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 カウンター以外のパフォーマンス カウンターには反映されない可能性があります。 つまり、MaxConcurrentApi の負荷が重く、ユーザーが問題を抱えている場合でも、CPU の使用、ディスク、ネットワークの使用などの他のパフォーマンス メトリックに負荷が表示されません。

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