MaxConcurrentApi 設定を使用して NTLM 認証のパフォーマンス チューニングを行う方法
この記事では、MaxConcurrentApi 設定を使用して NTLM 認証のパフォーマンス チューニングを行う方法について説明します。
元の KB 番号: 2688798
はじめに
企業情報技術のコンシューマー化 (企業企業で使用されるスマートフォンやタブレットなどのコンシューマー向けデバイスの増加) の増加により、企業環境でレガシ認証が大幅に増加する可能性があるシナリオが増えています。 レガシ認証の増加により、クライアントの遅延やタイムアウトなどのパフォーマンスの問題が発生する可能性があります。
環境で認証のタイムアウトまたは遅延 (MaxConcurrentApi のボトルネックとも呼ばれます) を検出した場合、問題を解決する一般的な方法は、その認証にサービスを提供するワーカー スレッドの最大数を上げることです。 これを行うには、MaxConcurrentApi レジストリ値を変更してから、サーバー上の Net Logon サービスを再起動します。
ボトルネックの原因となっているサーバーと、ボトルネックの遅延の原因となっているサーバーを特定することは困難な場合があります。 この記事では、MaxConcurrentApi 設定を使用して NT LAN Manager (NTLM) 認証のパフォーマンス チューニングを行う方法について説明します。 この記事には、MaxConcurrentApi 値を上げるサーバーとその値を設定する必要がある量を識別する管理者向けのガイダンスが含まれています。
解決方法
重要
このセクション、方法、またはタスクには、レジストリの編集方法が記載されています。 レジストリを誤って変更すると、深刻な問題が発生することがあります。 したがって、次の手順を注意深く実行してください。 保護のために、レジストリを変更する前に、バックアップします。 その後、問題が起こった場合は、レジストリを復元できます。 レジストリをバックアップおよび復元する方法の詳細については、次の記事の番号をクリックして表示される Microsoft サポート技術情報の記事を参照してください。
322756 Windows でレジストリをバックアップおよび復元する方法
この問題を解決するには、シナリオに関係するすべてのサーバーから取得されたパフォーマンス データを確認する必要があります。 その後、パフォーマンスの低下を示すサーバーの MaxConcurrentApi 設定を増やすことができます。
NTLM 認証の問題を報告する Netlogon イベントがあります。次を参照してください。
2654097 Windows Server 2008 R2 で NTLM 認証の遅延と失敗を追跡する新しいイベント ログ エントリを使用できます
イベントは、次の 2 つのカウンターのアクティビティを示します。
- イベント 5818/5819: イベントが有効になっている場合は、"Semaphore Waiters" があります。
- イベント 5816/5817: "セマフォ タイムアウト" があります。
サーバーに最適な MaxConcurrentApi 値を決定するには、数式を使用して複数のデータ ポイントをまとめ、計算する必要があります。 MaxConcurrentApi の推定に使用するデータは次のとおりです。
- Net Logon semaphore acquires
- Net Logon Semaphore のタイムアウト
- Net Logon の平均セマフォの保持時間
- 完了したパフォーマンス ログの期間 (秒単位)
データを取得した後、次の数式を使用して、正しい MaxConcurrentApi 値を推定できます:(semaphore_acquires + semaphore_time-outs) * average_semaphore_hold_time / time_collection_length = <New_MaxConcurrentApi_setting
サーバーの認証負荷が発生したときから Net Logon のパフォーマンス データを収集した後、行ビューの開始時刻と終了時刻を確認して、データ収集プロセスの期間を決定する必要があります。
Note
プレースホルダーの 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 レジストリ値を、数式によって提案される値または大きな値に変更する必要があります。
Note
MaxConcurrentApi の値を 10 より大きくする場合は、運用環境で変更を実装する前に、非運用環境で必要な設定の負荷とパフォーマンスをテストする必要があります。 この値を大きくしても、他のリソースのボトルネックが発生しないようにすることをお勧めします。 さらに、負荷条件は、各シナリオとビジネス環境に基づいて変更される可能性があることに注意してください。 そのため、サービスの負荷が変更された場合、MaxConcurrentApi の値は後で別の設定が必要になる場合があります。
MaxConcurrentApi 設定を変更するには、次の手順に従います。
[スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。
次のレジストリ サブキーを見つけてクリックします:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters[編集] メニューの [新規] をポイントし、[DWORD 値] をクリックします。
「MaxConcurrentApi」と入力し、Enter キーを押します。
[ Edit メニューの Modify をクリックします。
新しい MaxConcurrentApi 設定を 10 進数で入力し、 OK をクリックします。
コマンド プロンプトで、次のコマンドを入力し、Enter キーを押します。
net stop netlogon次のコマンドを入力して、Enter キーを押します。
net start netlogon
詳細
次のサポート技術情報の記事を使用して、レガシ認証のボトルネックのクライアント側の症状をより詳細に特定できます。
975363 Authenticated Services に接続すると、資格情報の入力を求めるメッセージが断続的に表示されたり、タイムアウトが発生したりします。このシナリオでは、認証のボトルネックが複数のサーバー上にある可能性があります。 そのため、特定のシナリオのすべてのサーバーが、負荷の高いサービスを行っている間にパフォーマンス データがレビューされるようにする必要があります。
セマフォ取得、セマフォ タイムアウト、および平均セマフォホールド時間のカウンターは、クライアント要求の処理に関係するすべてのアプリケーション サーバー、ドメイン コントローラー、および信頼されたドメイン コントローラーで確認する必要があります。
サーバーの負荷が高い間は、パフォーマンス データを追跡する必要があります。 負荷が大きいのは、サーバーでクライアント要求が最も多い場合です。 たとえば、電子メール サーバーのシナリオでは、パフォーマンス データを収集する最適なタイミングは、ユーザーが職場に到着してメール メッセージを確認するタイミングです。
その他の考慮事項は次のとおりです。
アクションが不要であることを意味する値はありません。 Semaphore Holders と Semaphore Hold Time カウンターには、サーバーに持続的な負荷がない限り値は表示されません。 値が存在しない場合は、MaxConcurrentApi 値を変更する必要はありません。
1 つのサイズがすべてに収まらない。 MaxConcurrentApi の値は、サーバーごとに異なる値である必要があります。 この状況は、複数のアプリケーション サーバーが 1 つのドメイン コントローラーから認証を受ける場合や、ドメイン コントローラーが処理する必要がある大量の負荷を複数のサーバーが提供する同様のシナリオによって発生する可能性があります。
信頼。 認証されているユーザーが信頼されたドメインからのユーザーである場合、ローカル ドメイン コントローラーがアプリケーション サーバーへの応答を提供する前に、ローカル ドメイン コントローラーが信頼されたドメイン コントローラーからの応答を待機する必要があるため、遅延が長くなる可能性があります。
ネットワーク待機時間。 ネットワーク待機時間は、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 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 サービスのデバッグ ログを有効にする
セキュリティ システム全体の統計オブジェクトの NTLM 認証の Perfmon.msc カウンターは、MaxConcurrentApi 追跡スレッドの使用回数を反映したものではありません。 Net Logon パフォーマンス カウンターに表示される MaxConcurrentApi セマフォの使用状況と NTLM 認証カウンターの増分の間には、1 対 1 の相関関係はありません。 NTLM 認証カウンターは、最適な MaxConcurrentApi 値を決定する場合には役立ちません。
さらに、MaxConcurrentApi に関連するレガシ認証のパフォーマンス タイムアウトが表示されますが、Net Logon カウンター以外のパフォーマンス カウンターには反映されない可能性があります。 これは、MaxConcurrentApi の負荷が高く、ユーザーが問題を抱えている場合でも、CPU 使用率やディスクやネットワークの使用などの他のパフォーマンス メトリックに負荷が発生しない可能性があることを意味します。
追加の最小化手順は、クライアントがdomainname\usernameではなく<null>\usernameを送信していることを示すエントリが Net Logon サービス デバッグ ログに含まれているドメイン コントローラーで実行できます。 この手順については、Microsoft サポート技術情報の次の記事で説明します。
923241 Active Directory ドメイン コントローラーに多数の外部信頼がある場合、Lsass.exe プロセスの応答が停止する可能性があります