SharePoint や Outlook Anywhere などの多くの Microsoft アプリケーションのセッション認証は、NTLM に依存しています。NTLM には、影響を受けるアプリケーションまたは仮想サービスに対して推奨される変更とともに、このトピックで扱うロード バランシングに関するいくつかの固有の要件があります。

接続の多重化

NSX Advanced Load Balancer では、HTTP アプリケーション プロファイル内で接続の多重化がデフォルトで有効になっています。多重化により、SE とサーバ間で開いているアイドル状態の接続を共有できます。接続の多重化は接続の確立を大幅に高速化しますが、NTLM と互換性がありません。NTLM は、セッションまたは要求ではなく TCP 接続への信頼を確立します。NTLM に依存するアプリケーションの場合、NSX Advanced Load Balancer では、仮想サービスの HTTP アプリケーション プロファイルで [接続の多重化] オプションを無効にすることをお勧めします。[テンプレート] > [プロファイル] に移動して、[アプリケーション プロファイルの編集] ページにアクセスします。

NTLM 接続の自動検出

環境内で NTLM が有効になったり、バックエンド サーバの NTLM フローがデフォルトで有効になったりすることがあっても、まったく気付かれない場合があります。これにより、NTLM と接続の多重化の間で互換性の問題が発生する可能性があります。

仮想サービスで接続の多重化が有効になっている場合、NSX Advanced Load Balancer は応答ヘッダーを使用して NTLM 接続を自動検出し、接続が終了するまで特定の接続の多重化を無効にします。これにより、NTLM 以外のトラフィックのパフォーマンスを維持し、接続の切り替えを NTLM 接続のみに制限することができます。NSX Advanced Load Balancer は、WWW-Authenticate ヘッダーの NTLM ヘッダーを使用して NTLM アプリケーションを検出します。NTLM 文字列が WWW-Authenticate ヘッダーに存在する場合 (WWW-Authenticate: NTLM)、アプリケーションは NTLM ベースのアプリケーションと見なされます。

NSX Advanced Load Balancer バージョン 22.1.1 以降では、サーバ応答の www-authenticate ヘッダーに Negotiate ヘッダーのみが存在する場合 (WWW-Authenticate: Negotiate) でも、アプリケーションは NTLM ベースのアプリケーションと見なされます。つまり、NTLM 文字列または Negotiate が WWW-Authenticate ヘッダーに存在する場合、アプリケーションは NTLM アプリケーションと見なされます。

アプリケーション プロファイル構成では、接続方法変換のオプション detect_ntlm_app がデフォルトで有効になっています。これは、次の例に示すように、必要に応じて無効にすることができます。

[admin:controller-vmdc2]: > configure applicationprofile applicationprofile-1
[admin:controller-vmdc2]: applicationprofile> http_profile
[admin:controller-vmdc2]: applicationprofile:http_profile> no detect_ntlm_app
[admin:controller-vmdc2]: applicationprofile:http_profile> save
[admin:controller-vmdc2]: applicationprofile>
注：

  • クライアントからの要求ヘッダーに Kerberos 文字列が含まれている場合 (Negotiate: Kerberos)、接続方法は変更されません。これは NTLM ベースのアプリケーションとして検出されません。このようなシナリオでは、接続の多重化を無効にすることを推奨します。

  • 接続方法の変換は、接続に対して接続の多重化が有効になっている場合にのみ発生しますが、接続の多重化が有効かどうかに関係なく NTLM アプリケーションが検出されます。

接続方法の変換の識別

NSX Advanced Load Balancer は、接続方法の変換を識別するのに役立つログと統計情報を生成します。接続方法の変換が発生するたびに、[重要度] ログが生成されます。[重要度] ログを表示するには、[アプリケーション] > [仮想サービス] > [ログ] の順に移動します。[重要度] フィールドの値を確認します。

show virtualservice vs-ntlm internal と show pool pool-ntlm connpool を使用して統計情報を表示します。

分析のための NTLM 検出の使用

NTLM 検出を使用すると、次のデータを取得できます。

  • NTLM 認証の状態

  • ユーザー名

NTLM 認証の状態

接続方法 (detect_ntlm_app) が有効になっている場合、NTLM 要求が傍受され、NTLM パラメータが検出され、この要求と応答から取得された情報が認証の状態やユーザー名の特定などの分析に使用されます。

傍受された NTLM 要求と応答に基づいて、次の状態が特定され、サポートされます。

認可なし：

クライアントが認証情報を指定せずにリソースにアクセスしようとすると、NTLM はクライアントに認証を要求します。このような要求は認可されていない要求です。

ネゴシエーション：

クライアントがネゴシエーションを開始し、サーバがネゴシエーション応答を送信します。

認証に成功：

クライアントは、認証情報を伝送する最後のメッセージ（NTLM メッセージ）を送信します。認証情報が正しい場合、サーバはユーザー名とパスワードが受け入れられたことを示す応答コードを送信します。これが認証に成功した状態です。

認証に失敗：

認証情報が正しくない場合は、認証に失敗したことを示す 401 状態コードが返されます。認証に失敗すると、重要なログが生成されます。

認証された要求：

NTLM 認証は接続ベースです。要求が認可されると、再認証が開始されない限り、同じ接続の後続のすべての要求が自動的に認可されます。このような自動認証された要求は、認証された要求と呼ばれます。

デフォルトでは、NSX Advanced Load Balancer はクライアントに送信される HTTP 応答の X-Accel ヘッダーを削除します。ただし、必要に応じてこのオプションを無効にできます。X-Accel ヘッダーはクライアントに送信される HTTP 応答と一緒に渡されます。

ユーザー名

ユーザー名は、認証が成功したかどうかに関係なく、要求のタイプ 3 NTLM メッセージから検出されます。これが完了すると、同じ接続の後続の要求は認証情報を伝送しません。これらの要求のアプリケーション ログには、最初に認可された要求と同じユーザー名が記載されます。これは、クライアントが再認可を要求するまで続行されます。

アプリケーション ログの NTLM ログは、次の識別に役立ちます。

  • NTLM フローが検出されたかどうか。

  • 認証の状態。

モニタリング

NTLM で認証されたアプリケーションでは、チェックを成功させるために、HTTP 健全性モニターは NTLM を介して検証する必要があります。これには、次の例のようなカスタムの外部モニターが必要です。

  • スクリプト

#!/bin/bash
#curl http://$IP:$PORT/Shared%20Documents/10m.dat -I -L --ntlm -u $USER:$PASS -I -L > /run/hmuser/$HM_NAME.out 2>/dev/null
curl http://$IP:$PORT/Shared%20Documents/10m.dat -I -L --ntlm -u $USER:$PASS -I -L  | grep "200 OK”

  • スクリプト変数

USER='foo\administrator' PASS=*****

401 認可できないエラー

クライアントが最初にサイトに接続すると、サーバは 401 エラー コードで応答します。このエラー コードは、クライアントが認可されておらず、最初に認証する必要があることをクライアントに対して示します。  これは、NTLM サイトへの接続の標準部分です。  デフォルトでは、NSX Advanced Load Balancer 認証プロファイルは、4xx 応答をエラーとして指定します。  その結果、健全性スコアが低下します（パフォーマンス スコアにマイナスの影響があります）。  これらの応答も「重要」としてログに記録されます。

401 応答が想定されるため、これらの応答コードを定義されたエラー リストから除外することを推奨します。  応答コードを除外するには、[テンプレート] > [プロファイル] に移動し、[分析] ページにアクセスします。  NTLM が有効な仮想サービスに適用されているプロファイルを編集します。  401 を [エラー分類]から [HTTP 状態コードを除外] セクションに追加し、[保存]をクリックします。