SE の雑記

Windows Azure Advent Calendar jp: 2011 の 9 日目のデプローイです。
Windows Azure ネタということで、毎度おなじみ VM Role でチャレンジです。

■AD FS Proxy を Azure 上に配置したときのイメージ図

フェデレーション ID (オンプレミスの AD のアカウント) を使用してOffice 365 をインターネット経由でアクセスする場合、DMZ に AD FS Proxy という認証の要求を HTTPS で受け、社内の AD FS に渡す役割のサーバーを配置します。
以下のような構成が一般的かと。

AD FS Proxy はインターネット経由のユーザーならびに Office 365 からアクセスできる場所に配置し、HTTPS の要求を受けられるように IIS を構成し、社内の AD FS とアクセスできるようにネットワークを構成する必要があります。
オンプレミスの環境で15GB ぐらいの VHD で AD FS Proxy を構築し動作確認をしておいて、そのイメージをインターネットにサクッと公開できる、そんな便利な環境がないかなと 10 秒ぐらい悩んだところ、アイツの存在を思い出しました。
そう、「VM Role」 です。
 
あとは、Windows Azure にデプロイした VM Role のインスタンスからオンプレミスの AD FS とガッツリ通信したい。
これまた 20 秒ぐらい悩んだところ頼れるアイツがいることに気づきました。
そう、「Windows Azure Connect」 です。
 
ということで、今回の投稿では、以下のような構成を組んで、VM Role 上の AD FS Proxy を使用して、フェデレーション ID で Office 365 にアクセスできる環境を作成してみます。

最初に書いてしまうと、今回の投稿の内容では完全自動化できていません…。
公開できるかの検証としてお読みいただければと思います。
# コード書ける方であれば、完全自動化できるかと。
AD DS / AD FS / AD FS Proxy のインストール、AD FS に Azure Connect のインストール、VM Role のイメージの準備 (Azure Connect の設定含む) に関しては省略しています。
また、カスタムドメインを使用していますので、ドメインを取得し、外部公開の DNS でカスタムドメインを公開できるようにする必要があります。
# クライアントからであれば、HOSTS で対応できますが、Office 365 からアクセスされる場合は、外部公開の DNS で解決される必要があるので。
今回の投稿では、カスタムドメインは、ムームードメインでドメイン取得 + ムームードメインの DNS 設定 を使用しています。?
ムームードメイン
全然関係ないですが、ムームードメインのマスコットは熊 (熊まとめ) のようです。
内輪ネタですがいつか、北の大地の荒ぶるクマーさん (おそらくアナログマ科) とコラボしないかな～とか考えていたりすると胸が熱くなりますね。
 

?

■VM Role を HTTPS で公開するための設定

AD FS Proxy とは HTTPS で通信をしますので、VM Role で HTTPS の Web サイトを公開する必要があります。
証明書に関しては、フェデレーションサービス名を共通名として設定したものを取得しておきます。
Web Role の場合は、Azure 上に使用する証明書をほすてっどサービスの証明書としてアップロードし、インスタンスの設定で証明書と HTTPS のエンドポイントを設定し、HTTPS によるアクセスを可能にします。
# このあたりは Windows Azure ホステッドサービスでSSL や 【Q】WindowsAzureでのSSL環境構築についてがとても参考になります。


 
VM Role の場合はプロトコルから https を選択することができず証明書の設定の項目もありません。
# 定義ファイルで設定できるスキーマ構成 (VirtualMachineRole Schema) になっているので、手動で プロトコルを https に設定したエンドポイントと証明書の設定を追加できるのですが、デプロイしてもインスタンスには反映されませんでした。

ということで、エンドポイントに関しては http エンドポイントとしてパブリックポートで 443 を使うように設定をしておき、証明書関係の設定はイメージの段階で事前に IIS に設定しておく必要がありそうです。
# サービスモデルには証明書の設定が含まれていませんので、ホステッドサービスの証明書として Azure 上に証明書をアップロードしておかなくても動作しました。
アップロードする前のイメージの状態で、フェデレーションサービス名を共通名として設定した証明書を IIS 上にインポートし、HTTPS (443) で使用する証明書としてバインドしておきます。

 
注意点としては一般化した Sysprep を行うと、HTTPS によるアクセスができなかった点です。
一般化した Sysprep を行った環境に対して HTTPS のサイトにアクセスしても正常に動作しませんでした。
IIS で HTTPS のバインドを確認し証明書を選択し直そうとすると以下のようなエラーが発生します。


この辺については以下の技術情報が該当していそうです。
IIS7.x: A Common Mistake when reinstalling IIS 7.x – errors 0x80070490 and 0x80070002
MachineKeys For IIS 7.0
Got Error 0x80070520 When Binding Certificate to Web Site on IIS 7
Make sure that IIS 7.0 configuration files contain no encrypted properties before you use the Sysprep tool to deploy a Windows Vista image
サクッと現象を解決するために、Sysprep の最中に使用する証明書を再度インポートするように仕掛けておきます。
応答ファイルに書いても対応できるのですが、今回は SetupComplete.cmd を使って Sysprep の一連の流れの中で証明書を再インポートするようにしておきます。
# SetupComplete.cmd の解説についてはこちら>? Sysprep 中に任意のコマンドを実行する方法について
証明書 (.pfx) を VM Role のイメージの中に入れておき、以下のような内容の SetupComplete.cmd を作成します。
# 今回は証明書を C:temp に配置しています。

このファイルを %WinDir%SetupScripts に配置しておくと Sysprep の中でコマンドが実行され証明書の再インポート (上書きインポート) が行われ、正常にアクセスができるようになります。
# 一般化しない Sysprep であればこの現象は発生しません。
証明書の入れ替えを考えると以下のような構成が取れると楽そうですね。

VM Role で HTTPS のサービスを提供する場合、この辺の設定が毎回必要になるのですかね…。
SSL を使う場合、一般化した Sysprep のテストが必要になりそうです。
 
HTTPS の設定が終わったらこのイメージを VM Role のイメージとしてアップロードします。
ここまでの作業で、赤線の箇所が完了です。

 
イメージのアップロードには時間がかかりますので、その時間は クラウド ガール 技術解説マンガ を読んでみるとよいかもです。
あとは、クラウド ガール壁紙・待ち受け の壁紙に登場している WebMatrix のヒーロー WebMatrixMan を探してみるのもいいかもしれないですね。
# WebMatrix についてはこちら > Free Web Development Tools for Windows | Microsoft WebMatrix
 

■DNS の設定

イメージのアップロードが終わったら名前解決のために DNS の設定を行います。
Windows Azure では、通常 [～.cloudapp.net] という DNS 名が使用されます。
AD FS Proxy へのアクセスは AD FS で設定している、フェデレーションサービス名で行うのが一般的な方法になります。
# フェデレーションサービス名を [sts.hogehoge.hoge] としている場合、証明書の共通名も [sts.hogehoge.hoge] というような形になるかと。

 
そのため、クライアントからのアクセスをする際には以下のように VM Role のインスタンスへの接続をフェデレーションサービス名を使用して名前解決が可能なようにする必要があります。

通常、Windows Azure でデプロイしたインスタンスは [～.cloudapp.net] という DNS 名で公開されますので、この [～cloudapp.net] の DNS 名を [hogehoge.hoge] として解決する必要があります。
この名前解決は Office 365 からも実施できる必要がありますので、外部に公開されている DNS に対して設定をする必要があります。
ここでは、CNAME を使用して名前の変換を行います。

今回使用している、ムームードメインの場合 (ムームー DNS) は以下のような設定になります。
# hogehoge.hoge というドメイン名を取得している場合。

ここまでの作業で以下まで完了です。

ここまでの作業で外部への公開に関しては一通り設定が終わりましたので、VM Role をデプロイします。
# サービス構成ファイルに、Azure Connect の設定も忘れずにしておきます。
 
この際、普通のデプロイでは物足りず 「ナイスデプロイ！」 をされたい アジュラー の方は 「WindowsAzureへの正しいデプロイとVIPスワップ」 がとても参考になると思います。
# ナイスデプロイについてはこちらも参考になります >? 【デプロイ王子】夜中に「デプロ～イ」と叫びたくなる動画
 
 

■オンプレミスの AD FS の名前解決

最後にオンプレミスとの接続の部分について、手動で設定をします。
デプロイが終わったら Azure Connect の設定をして、VM Role と AD FS の接続されるように設定しておきます。

 
Azure Connect の設定が反映されたら、フェデレーション ID を使用して、Office 365 にアクセスをしてみます。
デプロイ直後の状態だと Office 365 のサインイン画面からフェデレーション ID を使用するためのリンクをクリックすると

フェデレーション ID のドメインで使用するフェデレーションサービス名にリダイレクトされるのですが画面が表示できないと思います。

このエラーですが、VM Role 上の AD FS Proxy とオンプレミスの AD FS が通信をとれていないために発生しています。

 
VM Role にリモートデスクトップで接続して AD FS のイベントログからエラーを確認してみます。

フェデレーションサービス名を使用して、AD FS と通信がができないためにエラーが発生しています。
通常、AD FS Proxy では hosts ファイルにフェデレーションサービス名を? AD FS の IP アドレスとして設定をして、名前解決をします。
Azure Connect を使用することで、Azure Connect で設定しているサーバー間の通信をすることができますが、この接続には Windows Azure Connect Relay を使用して通信が行われています。

フェデレーションサービス名の名前解決に関してはこのネットワークを使用して行う必要があります。
そのため、Azure Connect でオンプレミスの環境と接続が可能になった後に AD FS に割り当てられている Azure Connect Relay の IPv6 のアドレスをフェデレーションサービス名として解決するように VM Role の hosts に記載をします。
# AD FS に割り当てらている Azure Connect Relay の IPv6 アドレスに関しては、Azure Connect で接続が確立された後に、AD FS で ipconfig /all を実行すると確認ができます。Azure Connect で接続がされた状態であれば、VM Role から AD FS サーバーのコンピューター名で Ping を実行しても確認ができます。

 
この設定をすることで、VM Role 上のAD FS Proxy とオンプレミスの AD FS がフェデレーションサービス名を使って通信ができるようになります。
この辺を事前にうまく設定しておければいいのですが、 インスタンス / AD FS サーバーの再起動等で、Azure Connect が再接続された場合は IPv6 のアドレスも変わってしまうようなので、良い方法が思いつきませんでした。

hosts の設定が終わったら、VM Role で AD FS のサービスを再起動します。
# Azure Connect で接続が確立され、hosts により名前解決ができている状態で AD FS のサービスが起動される必要があります。

再起動後に AD FS Proxy の AD FS 2.0 のイベントログを確認して、オンプレミスの AD FS のフェデレーションサービスからエンドポイントの一覧を取得できていれば設定は完了です。

 

■動作確認

AD FS Proxy と AD FS が Azure Connect を経由して接続できる状態になったら、ポータルから再度アクセスをすると、VM Role 上で実行している AD FS Proxy でフェデレーション ID を連携できるようになっています。

AD FS Proxy を経由して、Office 365 のポータルにもアクセスができました。

Windows Phone からも VM Role 上の AD FS Proxy を経由してアクセスができました。

VM Role Adapter を使って、Azure Connect の接続が終了し、オンプレミスの環境とアクセスができるようになったタイミングで、

• AD FS の Azure Connect Relay の IPv6 アドレスを取得
• hosts ファイルにフェデレーションサービス名の IP として取得した IP を設定
• VM Role の AD FS のサービスを再起動

といった順で処理を組むことで自動化できるかと思うのですが、実際に試せていません。
# AD FS を NLB で組んでいる場合でも、特定の AD FS サーバーとピアツーピアで接続しないといけないという課題はあります。
オンプレミスの NLB の仮想アドレス、ハードウェアロードバランサに対して Azure Connect で接続できないと思いますので。
 
長々と書いてしまいましたが、DMZ に配置するサーバーを? VM Role でAzure 上に配置して、オンプレミスで必要なリソースに関しては Azure Connect を使って接続をするという方法を AD FS Proxy を使用して検証してみた一例でした。
インスタンス数を増やせば冗長化された AD FS Proxy を外部に公開することもできるかと。
# 今回の方法では、インスタンス毎にに hosts の設定をしないといけないですが。
AD FS Proxy はサイレントインストール (adfssetup.exe /quiet /proxy) & コマンドで構成 (FspConfigWizard.exe) ができるのでスタートアップタスクを使用すれば Web Role で構築することが可能かもしれないですね。
ということでこの辺で Windows Azure Advent Calendar 9 日目のデプローイは終わりにしたいと思います。