NGINX Plus による Microsoft Active Directory Federation Services の高可用性

Microsoft Active Directory Federation Services (AD FS) を使用すると、Windows Server 上でアプリケーションをホストする組織は、エクストラネットを介して信頼できるビジネス パートナーの従業員にシングル サインオン (SSO) アクセスを拡張できます。 ビジネス パートナー間で ID 情報を共有することをフェデレーションと呼びます。

実際には、AD FS を使用すると、フェデレーション内の企業の従業員はローカル環境にログインするだけで済みます。 信頼できるビジネス パートナーに属する Web アプリケーションにアクセスすると、ローカル AD FS サーバーは、セキュリティ トークンの形式でユーザーの識別情報をパートナーの AD FS サーバーに渡します。 トークンは、ローカル Active Directory に保存されている従業員の個々の属性 (ユーザー名、ビジネス ロール、従業員 ID など) である複数のクレームから構成されます。 パートナーの AD FS サーバーは、トークン内のクレームをパートナーのアプリケーションが理解できるクレームにマッピングし、要求された種類のアクセスに対して従業員が承認されているかどうかを判断します。

AD FS 2.0以降では、高可用性(HA) を有効にして、アプリケーションの認証サービスに回復力と拡張性を追加できます。 AD FS HA クラスター (AD FSファームとも呼ばれます) では、複数の AD FS サーバーが単一のデータ センター内に展開されるか、複数のデータ センターに分散されます。 オールアクティブ HA 用に構成されたクラスターには、AD FS サーバー間でトラフィックを均等に分散するためのロード バランサーが必要です。 アクティブ/パッシブ HA 展開では、プライマリに障害が発生した場合に、ロード バランサーがバックアップ AD FS サーバーへのフェールオーバーを提供できます。

この投稿では、 AD FS 3.0およびAD FS 4.0 Server 2012 R2 と Windows Server 2016 をそれぞれ実行している環境で HA を提供するために NGINX Plus を構成する方法について説明します。

AD FS の標準 HA トポロジ

この投稿では、説明のために標準の AD FS ファーム トポロジを使用します。 これは推奨事項として、またはすべての可能な展開シナリオを網羅することを目的としたものではありません。 オンプレミス展開の場合、標準ファームは、企業イントラネット上の 1 つ以上の AD FS サーバーと、DMZ ネットワーク上の 1 つ以上のWeb アプリケーション プロキシ(WAP) サーバーで構成されます。 WAP サーバーはリバース プロキシとして機能し、外部ユーザーが企業イントラネットでホストされている Web アプリケーションにアクセスできるようにします。

ただし、WAP にはサーバーのクラスターを構成したり HA をサポートしたりするための組み込みの方法がないため、WAP サーバーの前にロード バランサーを展開する必要があります。 AD FS の HA を有効にするために、DMZ とイントラネットの境界にもロード バランサーが配置されます。 標準の AD FS ファームでは、Windows Server 2012 および 2016 のネットワーク負荷分散(NLB) 機能がロード バランサーとして機能します。 最後に、ファイアウォールは通常、ロード バランサーの外部 IP アドレスの前とネットワーク ゾーン間に実装されます。

標準 HA トポロジでの NGINX Plus の使用

前述のとおり、NLB は AD FS ファームの負荷分散を実行できます。 ただし、その機能セットは非常に基本的なものです (基本的なヘルスチェックと限定的な監視機能のみ)。 NGINX Plus には、実稼働 AD FS 環境での HA に不可欠な多くの機能があり、しかも軽量です。

ここで説明する標準トポロジの展開では、NGINX Plus が NLB を置き換えて、すべての WAP および AD FS ファームのトラフィックを負荷分散します。 ただし、AD FS を正しく操作するには、WAP サーバーからの実際の SSL 証明書を確認する必要があるため、NGINX Plus で AD FS サーバーの SSL 接続を終了させないことに注意してください (詳細については、このMicrosoft TechNet の記事を参照してください)。

実稼働環境では、NGINX Plus 自体の HA も実装することをお勧めしますが、ここでは示しません。手順については、NGINX Plus 管理者ガイドの「オンプレミス展開における NGINX Plus の高可用性サポート」を参照してください。

AD FS サーバーの負荷分散のための NGINX Plus の構成

AD FS サーバーの負荷分散のための NGINX Plus 構成は簡単です。 前述のように、AD FS サーバーは WAP サーバーからの実際の SSL 証明書を確認する必要があるため、DMZ イントラネット境界上の NGINX Plus インスタンスを構成して、SSL 暗号化トラフィックを終了したり処理したりせずに AD FS サーバーに渡します。

必須のディレクティブに加えて、次のディレクティブを構成に含めます。

• ゾーンは、すべての NGINX Plus ワーカー プロセスがアップストリーム グループ内のサーバーに関する構成および実行時の状態情報にアクセスできる共有メモリ内の領域を割り当てます。
• ハッシュは、送信元 IP アドレス (クライアントの) に基づいて、クライアントと AD FS サーバー間のセッションの永続性を確立します。 これは、クライアントが AD FS サーバーと単一の TCP 接続を確立する場合でも必要です。これは、特定の条件下では、セッションの永続性が有効になっていないと、一部のアプリケーションで複数のログイン リダイレクトが発生する可能性があるためです。
• status_zone は、NGINX Plus API がこのサーバーのメトリクスを収集し、組み込みのライブ アクティビティ監視ダッシュボードに表示できることを意味します ( API とダッシュボードは別々に設定されます)。

stream { アップストリーム adfs_ssl {ゾーン adfs_ssl 64k ; サーバー 10.11.0.5:443; # AD FS サーバー 1 サーバー 10.11.0.6:443; # AD FS サーバー 2 hash $remote_addr ; } サーバー { status_zone adfs_ssl ; listen 10.0.5.15:443; proxy_pass adfs_ssl; } }

　
WAP サーバーからのトラフィックが NGINX Plus を経由して AD FS サーバーに流れるようにするには、フェデレーション サービス名 (この例ではfs.example.com ) を NGINX Plus がリッスンしている IP アドレスにマッピングする必要もあります。 実稼働環境での展開の場合は、DMZ に DNS ホストAレコードを追加します。 テスト展開の場合、各 WAP サーバーのhostsファイルにエントリを作成するだけで十分です。ここでは、 hostsファイルでfs.example.comを 10.0.5.15 にバインドしています。

WAP サーバーからのトラフィックが AD FS サーバーに到達することをテストするには、 ipconfig /flushdnsコマンドを実行して DNS をフラッシュし、ブラウザーで AD FS の SSO ページ ( https://fs.example.com/adfs/ls/idpinitiatedsignon.htm)にログインします。

NGINX Plus を設定して WAP サーバーの負荷を分散する

ここで、外部クライアントから WAP サーバーへの HTTPS 接続を負荷分散するように NGINX Plus を構成します。 ベストプラクティスでは、トラフィックが AD FS サーバーに到達したときに SSL 暗号化されたままであることが規定されているため、NGINX Plus が HTTPS トラフィックを WAP サーバーに渡すように構成するには、次の 2 つの方法のいずれかを使用します。 SSL パススルーまたは SSL 再暗号化。

SSL パススルーの設定

より簡単な設定は、NGINX Plus で SSL 暗号化された TCP トラフィックを変更せずに WAP サーバーに転送することです。 このため、 AD FS サーバーの負荷分散のために、前のものと同様のストリームコンテキストで仮想サーバーを構成します。

ここで、NGINX Plus は別の一意の IP アドレス 10.0.5.100 で外部トラフィックをリッスンします。 運用環境では、公開されたアプリケーションの外部 FQDN は、パブリック ゾーンの DNS ホストAレコードの形式でこのアドレスを指す必要があります。 テストの場合は、クライアント マシンのhostsファイルのエントリで十分です。

注記： ストリームコンテキストで追加の HTTPS サービスを設定し、このサーバーと同じ IP アドレスでリッスンする場合は、マップ付きのssl_prereadディレクティブを使用して Server Name Indication (SNI) を有効にし、トラフィックを異なるアップストリームに正しくルーティングする必要があります。 これはこのブログの範囲外ですが、NGINX リファレンス ドキュメントには例が含まれています。

ストリーム { アップストリーム wap {
ゾーン wap 64k;
サーバー 10.11.0.5:443; #WAP サーバー 1
サーバー 10.11.0.6:443; #WAP サーバー 2
least_time connect;
}

サーバー {
status_zone wap_adfs;
listen 10.0.5.100:443;
proxy_pass wap;
}
}

HTTPS再暗号化の設定

SSL パススルーの代替として、 HTTPコンテキストで仮想サーバーを構成して HTTPS トラフィックを受け入れることにより、NGINX Plus の完全なレイヤー 7 機能を活用できます。 NGINX Plus はクライアントからの HTTPS 接続を終了し、WAP サーバーへの新しい HTTPS 接続を作成します。

証明書ファイルと秘密キー ファイル ( example.com.crtとexample.com.key )には、公開されたアプリケーションの外部 FQDN が共通名 ( CN ) またはサブジェクト別名 ( SAN ) プロパティに含まれています。この例では、FQDN はfs.example.comです。

proxy_ssl_server_nameおよびproxy_ssl_nameディレクティブは、必要な Server Name Indication (SNI) ヘッダーを有効にし、SSL Client Hello で送信されるリモート ホスト名を指定します。 ヘッダーは、公開されたアプリケーションの外部 FQDN (この例ではfs.example.com)と一致する必要があります。

proxy_set_headerディレクティブを使用して、関連情報を WAP サーバーに渡し、ログに記録できるようにします。

• X-Real-IPヘッダーには、 $remote_addr変数でキャプチャされた送信元 (クライアント) の IP アドレスが含まれます。
• X-Forwarded-For は、クライアント要求からのそのヘッダーを、クライアントの IP アドレスが付加された状態で伝達します (クライアント要求にヘッダーがない場合は、そのアドレスのみ)。
• x-ms-proxyヘッダーは、ユーザーがプロキシ サーバーを経由してルーティングされたことを示し、NGINX Plus インスタンスをそのサーバーとして識別します。

ここで示したディレクティブに加えて、NGINX と NGINX Plus は、SSL/TLS のパフォーマンスとセキュリティを向上できるさまざまな機能を提供します。 詳細については、ブログをご覧ください。

http { アップストリーム wap { ゾーン wap 64k; サーバー 10.0.5.11:443; サーバー 10.0.5.10:443; least_time ヘッダー; } サーバー { listen 10.0.5.100:443 ssl; status_zone fs.example.com; サーバー名 fs.example.com; ssl_certificate /etc/ssl/example.com/example.com.crt; ssl_certificate_key /etc/ssl/example.com/example.com.key; location / { proxy_pass https://wap; # 'https' は再暗号化を有効にしますproxy_ssl_server_name on ; proxy_ssl_name $host ; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header x-ms-proxy $server_name; } } }

WAP サーバーのないトポロジで NGINX Plus を構成する

外部クライアントが AD FS サーバーにアクセスできるようにする場合は、DMZ と企業イントラネットの境界で外部トラフィックを終了し、 x-ms-proxyヘッダーを挿入して外部認証の試行を識別することがベスト プラクティスです。 WAP サーバーはこれら両方の機能を実行しますが、前のセクションで設定したように、NGINX Plus も実行します。

一部のユースケースでは WAP サーバーは必要ありません。たとえば、IP ネットワークや信頼レベルなどの高度な要求ルールを使用しない場合などです。 このような場合、WAP サーバーを排除し、NGINX Plus を DMZ とイントラネットの境界に配置して、内部 AD FS サーバーへのリクエストを認証することができます。 これにより、ハードウェア、ソフトウェア、運用コストが削減されます。

この構成は、標準の HA トポロジの構成に代わるものです。 これは、WAP サーバーの負荷分散のためのHTTPS 再暗号化構成とほぼ同じですが、ここでは NGINX Plus が外部リクエストを内部ネットワーク内の AD FS サーバーに直接負荷分散します。

アップストリーム adfs { ゾーン adfs 64k;
サーバー 192.168.5.5:443; # AD FS サーバー 1
サーバー 192.168.5.6:443; # AD FS サーバー 2
least_time ヘッダー;
}

サーバー {
listen 10.0.5.110:443 ssl;
status_zone adfs_proxy;
サーバー名 fs.example.com;
ssl_certificate /etc/ssl/example.com/example.com.crt;
ssl_certificate_key /etc/ssl/example.com/example.com.key;

場所 / {
proxy_pass https://adfs;
proxy_ssl_server_name on;
proxy_ssl_name $host;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header x-ms-proxy $server_name;
}
}

AD FS 展開で NGINX Plus をお試しください。今すぐ30 日間の無料トライアルを開始するか、お問い合わせの上、ユースケースについてご相談ください。