概要

マイクロソフトのWebサーバーであるインターネットインフォメーションサービス（IIS）は、Active Directoryまたはスタンドアロン（LDAPベースの認証）システムに対してユーザーを検証するために、いくつかの認証メカニズムを統合しています。 NTLM ネットワークおよび両方の環境で使用できるアプリケーションで使用できるWindowsチャレンジ/レスポンス認証プロトコルです。

2つの異なるシナリオを考慮に入れることができます。 対話式NTLM認証 認証を提供するために必要なユーザーデータを格納するために使用されるクライアントとドメインコントローラーの2つのシステムの複合です。 非インタラクティブNTLM認証 ユーザがアプリケーション内の特定のリソースにアクセスできるようにするために、クライアント、アプリケーションサーバ、およびドメインという3つの異なるシステムが含まれます。

ASP.NETの偽装 WebアプリケーションがMicrosoft IISに依存するユーザーを認証および承認することを許可します。

この記事では、非対話型ユーザー認証シナリオ用にNTLMプロトコルを統合するアプリケーションの負荷分散方法について説明します。

NTLMはどのように機能しますか？

NTLMプロトコルは、認証されたセッションを確立するために、特定のクライアントが合計6ステップのハンドシェイクを開始するHTTP / Sプロトコルに依存しています。

認証済みセッションハンドシェイクには、次の手順が必要です。

1. クライアントは、Webサーバーに対して特定のリソースの匿名リクエストを開始します。

GET / HTTP

2. サーバーは、許可されていないメッセージとクライアントが使用する必要がある認証方法で応答します。

401 Unauthorized
WWW-Authenticate: NTLM

3. クライアントは、NTLM形式の認証確認を含む要求を再送信します。

GET / HTTP
Authorization: NTLM <base64-encoded first NTLM message>

4. サーバーは許可されていないメッセージで応答し、クライアントに詳細情報を要求します。

401 Unauthorized
WWW-Authenticate: NTLM <base64-encoded second NTLM message>

5. クライアントは、残りのセッション情報を含めて要求を再送信します。

GET / HTTP
Authorization: NTLM <base64-encoded third NTLM message>

6. サーバーはドメインコントローラと接続して認証要求を完了し、クライアントに認証を確認します。

HTTP 200 OK

このハンドシェイクは、HTTP要求ではなく、すべての新しい接続で必要であり、手順3〜6の間、接続を維持する必要があることに注意してください。接続が閉じている場合、ハンドシェイクのこの部分を繰り返す必要があり、手順5から繰り返すことは無効です。一方、接続が認証されると、Authorizationヘッダーを再度送信する必要はありません。アクセスされたリソースに関係なく、接続は閉じられません。

NTLM認証を使用してWebアプリケーションを負荷分散する方法

Zevenetには、単純なレイヤの2 TCPロードバランサまたは高度な機能のためのレイヤ4プロキシを使用して、負荷分散して高可用性のNTLMベースのWebアプリケーションを構築する7の主な方法があります。

レイヤ4での単純なNTLMロードバランシング

簡単な設定でWebアプリケーションとNTLM認証サポートの負荷を分散するために、L4xNATプロファイルを使用してLSLBベースのファームを作成できます。 HTTPまたはHTTPSプロトコルを使用できます。

次に、グローバル設定で、使用されているプロトコルが TCP しかし私達は選ぶことができます NAT or DTA 必要なトポロジーに従って。

メディアサービス/製品セクションでは、特定のクライアントの認証が常に同じバックエンドに送信されるように、永続性を設定する必要があります。そうしないと、接続認証を実行できませんでした。

最後に、バックエンドのリストを追加し、以下のセクションに示すようにヘルスチェックを設定します。

レイヤ7でのNTLMロードバランシング

このオプションはLSLBモジュールとHTTPファームを通して設定されたレイヤ7プロキシでNTLMサポートでHTTP / Sデータを扱うことを可能にします。これには、仮想サービスのSSL要件に従って、HTTPまたはHTTPS用のファームを作成する必要があります。唯一の違いはリスナーで設定グローバル設定作成された農場の

この層では、持続性または接続固定を作成するためにアプリケーションがまだセッションCookieを作成できないため、次のものを使用できます。クッキーの挿入 NTLM認証の最初のハンドシェイク中にロードバランサが新しいcookieを作成することを許可するオプション。

最後に、バックエンドのリストを追加し、以下のセクションに示すようにヘルスチェックを設定します。この種のファームに含まれるプロキシレベルで追加のアプリケーションオプションを構成することができ、NTLMサポートは影響を受けません。

NTLM認証Webサイトの高度なヘルスチェック

NTLM認証済みアプリケーションのカスタムの高度なヘルスチェックを作成するには、パスの下に作成する必要があります / usr / local / zevenet / app / libexec 以下に示すように、バックエンドをチェックするスクリプト。例えば、 check_ntlm.sh 適切な権限を持ちます。

#!/bin/bash

# get input parameters
BACKEND=$1
PORT=$2
USER=$3
PASS=$4
URI=$5
STRING=$6

/usr/bin/curl http://${BACKEND}:${PORT}${URI} --ntlm -negotiate -u ${USER}:${PASS} 2>/dev/null | grep "${STRING}" &>/dev/null

if [ $? == 0 ]
then
	# if the curl command doesn't fail then notify that the backend is up
	echo "Server ${BACKEND}:${PORT} OK"
	exit 0
fi

# if the the curl command fails then notify that the backend is down
echo "Server ${BACKEND}:${PORT} is not OK"
exit 1

メディア監視>>ファームガード該当する場合、またはファームサービスをチェックインするコマンドに追加する

以下を実行して、ヘルスチェックスクリプトをテストできます。

/usr/local/zevenet/app/libexec/check_ntlm.sh 192.168.0.99 80 johndoe johnsecret "/my/uri" "DOCTYPE html"

バックエンドのIPアドレスが 192.168.0.99 ポートは 80 HTTP、 ジョン・ドウ ドメイン内のダミーユーザーです。 ジョンシークレット ダミーのパスワード 「/ my / uri」 確認するURIです。 「DOCTYPEhtml」 要求が成功したときに応答データ内で見つけるストリングです。

サービスのヘルスチェックに含めるために、ドメインにログインできるが権限のないダミーユーザーを作成することをお勧めします。それが使用する理由です ジョン・ドウ カスタムヘルスチェックのダミーユーザー

ヘルスチェックをコマンドラインからテストして準備ができたら、NTLMサポートを使用して構成されたファームに割り当てることができます。

負荷分散されたNTLM Webアプリケーションを楽しんでください。