今回はAD FSを外部に公開するためのリバースプロキシである Web Application Proxy のインストールとセットアップを行う。使用するサーバはPRX1だ。

初めに、PRX1とFS1に接続しておこう。その際、使用するIDはドメインの管理者IDでなければならないので注意しよう（<ドメイン名>\cloudadmin）。

証明書のインポート

PRX1はリバースプロキシの役割を持ち、内部のサービスの"ふり"をして外部に公開される。"ふり"をするには、内部サービスと同じ証明書を持つ必要がある。そのために、前回FS1のデスクトップにエクスポートした sts の証明書をPRX1 にインストールする。

証明書の複製は簡単で、FS1のデスクトップ上の証明書をコピーし、PRX1のデスクトップに貼り付ければよい。リモートデスクトップクライアント間はファイルなどをコピー＆ペーストできるように設計されている。

証明書をコピーしたら、ダブルクリックして証明書のインポートを開始する。ウィザードが起動したら「ローカルコンピューター」を選択して「次へ」をクリックする。

以降の画面ではすべて既定値のまま「次へ」をクリックし、インポートを完了させる。

Web Application Proxy のインストール

次に、PRX1にWeb Application Proxy（WAP）をインストールする。「サーバーマネージャー」の「管理」メニューから「役割と機能の追加」を選択。「サーバー役割の選択」画面まで進んだら「役割」の一覧で「Remote Access」を選択する。

「次へ」を数回クリックして「役割サービスの選択」画面まで移動したら、「役割サービス」の一覧から「Web Application Proxy」を選択。その際ポップアップが表示されるので「機能の追加」をクリックする。

最後に「インストールオプションの確認」で確認を行って「インストール」をクリックする。インストールは3分程度で完了する。

Web Application Proxy のセットアップ

インストールが完了したらセットアップを行う。セットアップを開始する手順はおなじみの方法だ。サーバーマネージャーの右上にある旗印をクリックし、表示されたポップアップで「Webアプリケーションプロキシウィザードを表示する」をクリックする。

ウィザードが起動したら「次へ」をクリックする。「フェデレーションサーバー」の画面では、フェデレーションサービス名としてAD FSのホスト名（この例では sts.mynavi.mydns.jp）とAD FSに対して管理者権限を持つユーザーIDを指定する。ここで指定するホスト名は sts を使用していただきたい。そうしなければ、証明書の主体名との不一致が発生し、エラーとなる。

「AD FSプロキシの証明書」画面では、先ほどインストールした証明書を指定する。ここでは sts.mynavi.mydns.jp を指定している。

「確認」ページで構成内容を確認したら「構成」をクリックしてセットアップを完了させよう。特に問題がなければ1分程度で構成は完了する。

問題が発生するとすれば、以下の3点だろう。

  • AD FSのホスト名（sts.<ドメイン名>.mydns.jp）を間違えている。
  • AD FSに管理者権限を持つIDまたはパスワードを間違えている。
  • AD FSのFirewallでAD FSにアクセスするためのポートが空いてない（前回の演習の最後の部分を参照のこと）。

ここまでの作業が完了したら、サーバ PRX1 を再起動しよう。

PRX1 Firewall の設定変更

PRX1はリバースプロキシであるため、外部からのHTTPS（443）接続を受け入れる必要がある。再起動が完了したら再度PRX1にログオンし、サーバーマネージャーの「ツール」メニューから「セキュリティが強化されたWindows ファイアウォール」を起動しよう。

「受信規則」を右クリックし「新しい規則」を選択すると「新規の受信の規則ウィザード」が起動する。「規則の種類」で「ポート」を選択して「次へ」と進む。

「プロトコルおよびポート」で「特定のローカルポート」を選択し、ポート番号として443を指定して「次へ」。

「操作」ページでは「接続を許可する」が選択されていることを確認し「次へ」。「プロファイル」ページでは既定値のまま「次へ」。最後に「名前」ページで、このルールの名前を指定する。例えば、「HTTPS」とでも指定すればよいだろう。

「完了」をクリックすればルールが保存され、有効化される。

PRX1の受信規則の変更

Windows Firewall の設定だけでは足りず、Azure が持つパブリックIPに対してもHTTPSを受け入れるよう設定が必要だ。現在の設定ではRDP（3389）しか受け入れるように設定されていないため、パブリックなIPアドレスの受信規則を変更する必要がある。

まずは Azure Portalに接続し、PRX1を選択しよう。

右側にある「設定」の一覧から「ネットワーク インターフェイス」をクリックする。

ネットワーク インターフェイスには1枚のNICが表示されているはずなので、これをクリックしよう。演習通りの命名規約を使用していればNICの名前は PRX1-nic となっているはずだが、以下の図は残念ながらそれに沿っていない。

次に、ネットワークインターフェースの「設定」から「ネットワークセキュリティグループ」を選択し、さらに「ネットワークセキュリティグループ」の表示されている名前（図11の例ではPRX1）をクリックする。

右側の「設定」から「受信セキュリティ規則」をクリック。

既存のルールとして RDP（3389）を受け入れる設定が存在することがわかる。「追加」をクリックし、以下の図に示すよう、外部からの443番ポートへの接続を許可する。

入力が完了したら「OK」をクリックすると、1分程度で設定が反映される。下図に示すように一覧に表示されたら保存完了だ。

Web Application Proxy の動作確認

セットアップが完了したので、WAPの動作確認をしてみよう。ここでは、AD FSの動作確認の際に使用した以下のURLを外部に公開してみて、インターネット側からアクセス可能かどうかをチェックすることにする。

https://sts.<ドメイン名>.mydns.jp/adfs/ls/idpinitiatedsignon.aspx

PRX1に接続し、サーバーマネージャーの「ツール」メニューから「リモートアクセス管理」を選択する。

画面右側にある「タスク」から「公開」をクリックするとウィザードが起動するので「次へ」をクリックする。

「事前認証」画面では、これから公開するアプリケーションの事前認証を行うかどうかを指定することができる。事前認証するアプリケーションはAD FSに登録されている必要がある。今回は事前認証を使用せず「パススルー」で通過できることを確認するので「パススルー」を選択する。

公開設定画面が表示されたら、下図のように設定する。

「名前」欄はただの管理上の識別名なので適当でよい。ここでは「test」としている。外部URLは、外部からアクセスする際に使用するURLを指定する。以下に例を示したが、mynavi 部分は読者の環境に合わせて設定していただきたい。バックエンドサーバも同様に設定する。「外部証明書」はセットアップ時に設定した sts の証明書を使用する。

https://sts.mynavi.mydns.jp/adfs/ls/

上記の設定が終えたら「次へ」「公開」をクリックして公開を完了させる。 公開されるまでに数分を要するので、少し待とう。

次に、今登録した sts.<ドメイン名>.mydns.jp に外部からアクセスできるようにする必要があるが、ここではローカルPCのHOSTSを変更して対応することにする。そのために、まずはWAPの外部アドレスを知らなければならない。外部アドレスはAzure Portalから確認することができる。

Azure Portal を起動し、Virtual MachinesからPRX1を選択しよう。中央に「パブリックIPアドレス」と書かれているのがわかるだろうか。これがPRX1の外部向けのIPアドレスだ。 以下の図の例では13.78.61.150 と書かれている。これを sts.mynavi.mydns.jp のアドレスとしてHOSTSに登録する。

ここから先の作業は、今、皆さんが操作している「ローカルPC」での作業となるので注意しよう。Windows の場合、HOSTS ファイルは標準で以下のパスに保存されている。

C:\Windows\System32\drivers\etc\

HOSTSファイルが見つかったら、以下のように1行追加する。なお、これは筆者の環境なので、IPアドレスとドメイン名（mynavi）部分は自身の環境に合わせて変更していただきたい。

13.78.61.150 sts.mynavi.mydns.jp

なお、HOSTSファイルは既定では直接編集することができない。そこで以下のような操作手順を試みてみよう。

  • HOSTSファイルをコピーして、ドキュメントフォルダ等にペーストする。
  • コピーしたHOSTSファイルを編集して保存する。このとき、拡張子に.txtなどが付いていないことを確認する。HOSTSファイルには拡張子は必要ない。
  • 元のHOSTSファイルを HOSTS.bakなどにリネームする。
  • 編集したHOSTSファイルを元の場所に複製する。

以上が完了すると、手元のローカルPCからWAPを通してstsにアクセスできるようになっているはずだ。手元のブラウザから以下のURLを入力してみよう。

https://sts.<ドメイン名>.mydns.jp/adfs/ls/idpinitiatedsignon.aspx

アクセスできると 、以下のように証明書のエラーが表示されるはずだ。これは、sts.mynavi.mydns.jp の証明書が自己署名証明書であるせいだ。今回は気にする必要はない。もしこのエラーを解消したい場合は、作成したドメインのルート証明書（この演習では mynavi-DS1-CA）をエクスポートし、ローカルPCにインポートする必要がある。

「このサイトの閲覧を続行する」をクリックすると、以下の画面が表示される。この画面は、AD FSの動作テストでも確認した画面だ。

「サインイン」をクリックすると、以下のフォームに移動するので管理者IDとパスワードを入力して「サインイン」をクリックしよう。

以下の画面に切り替われば正しく動作している証拠だ。

ちなみに、AD FSの動作確認時には以下のポップアップが表示されたのに対し、今回はフォーム画面が表示されていることに気づいただろうか。これは、社内ネットワークではWindows 統合認証機能が機能してドメインコントローラによるポップアップが表示されたのに対し、インターネット側からアクセスした場合にはドメインコントローラが見えないため、リバースプロキシによるフォーム認証画面が表示されたからだ。

以上で、オンプレミスに相当する環境のセットアップはすべて完了した。残る作業は以下の通りだ。

  • Azure Active Directoryのディレクトリ（テナント）作成
  • Azure Active Directory とのユーザー同期設定
  • Azure Active Directory とのフェデレーション設定

最終回となる次回は上記全ての作業を完了させよう。

編集協力:ユニゾン

安納 順一
日本マイクロソフト テクニカル エバンジェリスト
主にインフラ系テクノロジーの日本市場への訴求を担当。近年はパブリッククラウド上のアイデンティティ・プロバイダーであるAzure Active Directoryを活用したセキュリティ基盤のデザインや実装方法などがメインのフィールドである。
Technetで個人ブログもさまざまな技術情報を発信している。