Azure AD Application Proxy 構築ガイド（３）冗長化対応

#はじめに
　これまで [構築ガイド（１）](https://qiita.com/Aida1971/items/ae42d1ae371794f12780)、[構築ガイド（２）](https://qiita.com/Aida1971/items/b7e7d3b0d70fabc9f609)にてシングル構成の [Azure AD Application Proxy](https://docs.microsoft.com/ja-jp/azure/active-directory/application-proxy-publish-azure-portal) の構築手順を紹介してきました。今回は本番環境に対応するための冗長化構成について説明していきます。なおオンプレミス側のシステムが既に冗長化されている場合には、オンプレミス環境にアプリケーションプロキシサーバー (Application Proxy Connector) をもう一台追加するだけで作業は完了します。

#冗長化対応システム構成
　ここでは、オンプレミス環境に該当するマイクロソフトサーバー製品を Azure IaaS として仮想ネットワーク上に構築するシナリオで説明しています。仮想ネットワークをオンプレミスネットワークと置き換えて解釈する事も可能です。

![System.png](https://qiita-image-store.s3.amazonaws.com/0/166732/84a33003-cc22-0434-f9ae-e3b3d4353354.png)
###概要
　Azure AD Application Proxy はイントラネットシステムをインターネットへ WEB 公開する為のサービスです。このため Azure IaaS の構成例では、内部ロードバランサー (Internal LB) の配下に 2 台の WEB サーバーをぶら下げる形になります。中継サーバーである Application Proxy Connector は、この内部ロードバランサーの VIP に対してリクエストを転送する形となります。

**注意点１.** 
　ロードバランサー配下で負荷分散をする場合、IaaS VM は**[可用性セット](https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/manage-availability#configure-multiple-virtual-machines-in-an-availability-set-for-redundancy)**内に配置しなければなりません。この設定は後から変更する事ができないため、WEB サーバーのデプロイ時に忘れずに可用性セットに入れる必要があります。
![SVSET.png](https://qiita-image-store.s3.amazonaws.com/0/166732/5948a673-2dde-3114-6ca3-c327133e5569.png)


**注意点２．**
　AD と Azure AD 間の同期を実行する AD Connect サーバーは同時に複数台での稼働をサポートしていないため、ここでは1台構成となります。必要に応じてスタンバイサーバーを待機させる事は出来ますが、クライアントからの要求処理には無関係のサーバーであり、冗長構成は必要としません。 

#構築手順

　本記事では、設定がわかりづらい内部ロードバランサーの VIP に対する名前解決や委任 (Delegation) 設定を中心に説明しています。汎用的な AD, Application Proxy Connector, IIS の追加サーバーのインストール手順などは割愛しています。

###Azure 側の作業
####Internal Load Balancer のデプロイ
　手順詳細は割愛しますが、以下の記事が参照となります。注意点としては内部ロードバランサーの VIP は DNS 名前解決の観点から静的に割り当てます。また**死活監視用のプローブは HTTP でなく TCP プローブにてポート 80 を監視**します。これは統合認証がかかっているサイトのため HTTP 応答が 401 となるためです。HTTP プローブを利用したい場合には、別途プローブ呼び出し用に認証がないコンテンツを用意する必要があります。

　
　冗長・負荷分散に必須「Azure ロードバランサー」の作成
　https://www.cloudou.net/load-balancer/lb002/

　以下は公式ドキュメントとなります。外部 (Public) 用の作成手順ですが、内部 (Internal) を選択してから、ロード バランサー規則を作成すれば同じとなります。ロード バランサー規則を利用するので、下記記事の NAT 規則手順は不要です。

　Azure ポータルを使用したインターネットに接続するロード バランサーの作成
　https://docs.microsoft.com/ja-jp/azure/load-balancer/load-balancer-get-started-internet-portal

###オンプレミス側 (AD サーバー) の作業
1. オンプレミス AD 上の DNS サービスで 内部ロードバランサーの VIP に対する名前解決を設定します。HOST(A) レコードの追加で onpremise-lb を静的 VIP に対して解決します。　
　![DNS.png](https://qiita-image-store.s3.amazonaws.com/0/166732/e5db7ec1-2472-f2e7-bd86-5eca91640977.png)　

2. オンプレミス AD 上に IIS 実行アカウントとして IISAdmin ユーザーを作成します。
　
　![1.png](https://qiita-image-store.s3.amazonaws.com/0/166732/2b93fb15-c958-2e78-4182-ff3c8a68b903.png)　
　

3. コマンドプロンプトを起動し、setspn コマンドで aida-factory\IISAdmin に対して、SPN（サービス プリンシパル名）を登録します。SPN の登録にはドメイン管理者権限が必要です。
####**`setspn -A http/onpremise-lb aida-factory\IISAdmin`** 
![3.png](https://qiita-image-store.s3.amazonaws.com/0/166732/e2f95136-4b5c-28bf-90d0-e275c6d40e21.png)
　
　**参考資料：サービス プリンシパル名の登録**
　https://blogs.msdn.microsoft.com/crmjapan/2010/01/28/5073/
　

4. Active Directory ツールの [ユーザーとコンピューター] を起動します。プロキシサーバー (onpremise-proxy) のプロパティを開き、下記順番で選択し、最後に [Add] ボタンを押します。
　![6.png](https://qiita-image-store.s3.amazonaws.com/0/166732/7a1edecd-db86-d6f1-9d1f-2c1496504bd0.png)
　
　
5. オブジェクト名に IISAdmin と入力し名前を解決し、[OK] ボタンを押しダイアログを閉じていきます。
　![5.png](https://qiita-image-store.s3.amazonaws.com/0/166732/2d23feba-fe5e-e6a5-867b-50a18d675fbd.png)
　
　
6. 正常に登録された場合、Expanded チェックボックスを入れると onnpremise-lb と FQDN 名の２つが登録されているのが確認できます。最後に [OK] ボタンを押して完了です。
　![4.png](https://qiita-image-store.s3.amazonaws.com/0/166732/f1fdd46f-918a-2fe7-40f0-0733acd269bf.png)
　　
　※ 上記手順の画面イメージではプロキシサーバー (onpremise-proxy) は 1 台ですが、冗長化対応済みで 2 台ある場合は、同じ作業をそれぞれのプロキシサーバーに対して実施します。

###オンプレミス側 (WEB サーバー) の作業
1. 冗長化され複数台ある IIS サーバーの全てで、WEBサイトの実行アカウントをドメインユーザー aida-factory\IISAdmin に変更・統一します。
　![IIS01.png](https://qiita-image-store.s3.amazonaws.com/0/166732/04ff91e5-f87a-0959-94d4-a41305d56548.png)
　

2. IIS の場合、追加設定が必要なため管理ツールから Configuration Editor を起動し、useAppPoolCredentials プロパティを True に変更します。
　![aaa.png](https://qiita-image-store.s3.amazonaws.com/0/166732/b49d0d86-6e1f-1c8f-3e9b-d3288840a803.png)
　![bbb.png](https://qiita-image-store.s3.amazonaws.com/0/166732/ced972e8-f7ea-e845-c561-5117a91aece8.png)

#動作検証（内部呼び出し）
　ここまでの設定で、仮想ネットワーク内のプロキシサーバー (Application Proxy Connector) から内部 URL で Web サイトへアクセスが出来る事を確認します。この呼び出しが成功したら、最後の仕上げとして Azure AD Application Proxy の設定を負荷分散先へと変更します。

　**内部負荷分散 URL : http://onpremise-lb/**

###Azure AD Application Proxy の設定更新
1. Azure ポータルより Azure Active Directory - エンタープライズ アプリケーション - すべてのアプリケーションから、[構築ガイド（２）](https://qiita.com/Aida1971/items/b7e7d3b0d70fabc9f609)で作成したアプリケーションを選択します。
　

2. シングルサインの設定で SPN を負荷分散用の SPN に変更します。
　
![IIS01.png](https://qiita-image-store.s3.amazonaws.com/0/166732/6d7d8ab3-8b96-00d0-306b-a803fec1b9a6.png)
　
3. アプリケーションプロキシの設定で、内部 URL を、負荷分散用の URL に変更します。
　
![IIS01.png](https://qiita-image-store.s3.amazonaws.com/0/166732/2263d93b-7b7a-9f14-431a-f5769a4f4b9d.png)

#動作検証（外部呼び出し）
　以上で、負荷分散環境の構築は完了です。[構築ガイド（２）動作検証手順](https://qiita.com/Aida1971/items/b7e7d3b0d70fabc9f609#%E5%8B%95%E4%BD%9C%E6%A4%9C%E8%A8%BC)を参考に、動作検証を実施します。