8/31に開催されるOffice365勉強会に登壇させて頂く事になりました。
今回話すテーマとしては、ここ半年で出てきたディレクトリ同期によるパスワード同期や、二要素認証、Windows Server 2012 R2での新しいADFSなどの新しい技術要素を踏まえた上で、今、企業でOffice365を利用する際のIDやパスワード管理はどうするのが良いのかについて少し話したいと思います。
名称：第6回 Office365勉強会
日時：2013/8/31 13:00～18:00
場所：品川グランドセントラルタワー 31F セミナールームA
詳細：http://www.office365room.com/o365-meeting/o365meeting-6/
登録は こちら から。
土曜日の午後ですが、お時間の許す方は是非ご参加頂ければと思います。
Office365のアクセス制御の実装方式としまして、一番一般的なのはADFSを利用したクレームルールによるアクセス制御になります。クレームにはExchangeにアクセスしてくるクライアントのIPやプロトコルなどの情報がOffice365側で付与されて伝送されてきますので、それとユーザーの所属するグループなどの情報を合わせてアクセス制御を実装します。
ここ1～2年の間で、（非常に細かいことですが）少しここの仕組みでOffice365側で変更になった部分があるので紹介します。
まず、従来のアクセス方式について説明します。Office365のExchange Onlineは、メールボックスがシンガポールか香港のどちらかがプライマリとして設定されています。また、ユーザーがアクセスするCASサーバはどちらのデータセンタも同じURLでのアクセスとなるため、1/2の確立で自分のメールボックスが無いCASにアクセスされます。
この際、Outlook（Outlook Anywhere）やActiveSyncなど、HTTPSによる通信でリダイレクトがサポートされているプロトコルについては、メールボックスがこのサイトに無い旨クライアント側に通知され、メールボックスの存在するサイト（下の図で言えばシンガポール）のCASサーバにリダイレクトされます。
この結果、ADFS（ADFS Proxy経由）に渡されてくる送信元IPは、元のグローバルIP：Aが渡されてきます。
次に、POPやIMAPなど、プロトコル的に「リダイレクト」の処理がサポートされていない場合です。この場合、CASサーバは適切なサイトへの接続（下の図で言うと香港→シンガポール）を「Proxy」処理します。
これが行われると、ADFSには送信元IPとしてグローバルIP：AならびにグローバルIP：Cの両方が渡されます。
この原理により、POP/IMAPのプロトコルをADFSで送信元IP制限を掛ける場合、Exchange OnlineのIP帯についても許可IPリストに入れておく必要がありました。
変更点
①クライアントのIPアドレスとしてIPv6がサポートされました。
Exchange Onlineの接続ポイントとしてIPv6がサポートされました。合わせて、クライアントのIPv6アドレスについても問題なくADFSサーバ側に情報として渡されるようになりました。
ADFSのクレームルールでは、文字列の正規表現でのマッチングで判定をします。「IPv6でもアクセスできるように許可する」「既存の許可ルールが、別のIPv6アドレスにマッチングしないようにする」などの確認が必要になります。
②MicrosoftデータセンタのIP帯のアドレスがマスクされてADFS側に渡されなくなりました。
これは、上記POP/IMAPアクセスの際に従来「グローバルIP：AならびにグローバルIP：C」が渡されてきた物から香港DCのIP帯であるCの方がマスクされて「グローバルIP：A」のみADFSに渡されてくる形になります。
http://community.office365.com/ja-jp/wikis/sso/927.aspx にも、以下のように記載があります。
・クライアント IP アドレスおよび要求を渡した各プロキシのアドレスを示す複数の IP アドレスは、 コンマで区切って指定されます。 ・Exchange Online インフラストラクチャに関連する IP アドレスは一覧に表示されません。
これにより、ADFSのクレームルールを作成する場合に、プロトコルの挙動（リダイレクトかProxyか）の差について作成者は意識せずに作れるようになりました。
ただし、現時点で1つ問題点というか、制限事項が確認されています。このマスクされるIPアドレスについては別途Microsoft側で定められているようなのですが、それにシンガポールDC、香港DCなど【同一DCで動作しているWindows AzureサービスのIP帯】も一部含まれているようです。
この為、Windows Azure上で展開されているExchange Online対応のサービスについて、適切なIPアドレスが渡されてこない可能性があります。IntuneのクライアントアクセスのIPアドレス帯については未確認ですが、同じ原理でいけば可能性はあると思います。
いずれIPアドレスのリストなどが精査されて直ることを期待してますが、動作原理を知っているのといないのでは有事の際に対応にも差が出るかと思いますので、細かいことですがここでご紹介させて頂きました。
なお、この記事は一部検証結果に基づいた個人的な推察を交えて記載しておりますので、もし事実に反することや、既に解消されたということが書かれていた場合は訂正させて頂きますので、連絡を頂ければと思います。
Office365のディレクトリ同期ツールがバージョンアップして、パスワード同期の機能が実装されたとのことで、早速試してみました。
インストール方法は今までと基本的に変わりません。Office365のテナント側でディレクトリ同期を有効化した上で以下の手順でインストールします。
1. .NET 3.5の機能をインストールする
ディレクトリ同期ツールのインストールには、.NET Frameworks 3.5が必要になります。無い場合はエラーになります。
2.ディレクトリ同期ツールをインストールする
続いてdirsync-ja.exeを実行してセットアップします。190MB程になったので、かなりファイルサイズが大きくなりましたね。最後の画面でチェックボックスを入れ、そのまま構成ウィザードを実行します。
3,構成ウィザードを実行する
ディレクトリ構成ウィザードでは、Office365の全体管理者のID/PASS、Active DirectoryのEnterprise Adminsの権限を持ったアカウントのID/PASSを指定します。
ちなみに、6/6現在のバージョン(1.0.6385.0012)だとハイブリッド機能にバグがあるらしく、ここは有効化しない方が良いと思われます。新しく.0024のバージョンが近日中に公開されると思われます。（Exchangeが組織内にある場合のみ有効化可能です）
[パスワード同期]ここの項目が新しく加わってます。[パスワード同期を有効にする]のチェックボックスをチェックしてから[次へ]をクリックします。
これでインストールは完了です。初回同期でオブジェクトが作成されると共に、パスワードの初期同期も実行されます。このため、Active Directoryのパスワードですぐログインができるようになりました。
さて、それでは少し細かい所を触っていきましょう。まず、MIISClientを事項するのに必要な権限がMIISAdminsからFIMSyncAdminsに変わりましたので、運用でMIISClientを触っている人は気をつけた方が良いでしょう。
また、ディレクトリ同期用のアカウントがMSOL_AD_SYNCからAAD_xxxxxxに変更されました。
また、パスワード同期が有効化されていても、Office365側でもパスワードを変更することが可能です。ただし、オンプレミスのADにパスワードは同期されません。つまり、ディレクトリ同期と同様、同期の方向はAD→Office365の一方向です。
次に、パスワードの同期間隔です。ご存じの通り、ディレクトリ同期ツールは3時間に1度しか同期されません。さすがにパスワードの同期がそれほど長いかかると実用に耐えないということか、パスワードの同期のみ、より短時間で同期されるとMicrosoftのサイトにも記載されてます。
試しにパスワードリセットしてみると、ものの1分ほどでディレクトリ同期サーバのイベントログに変更要求とその成功が記録され、パスワードが同期されています。ちなみに、ディレクトリ同期のコンソール画面であるMIISClientには何も表示されません。
色々と試したところ、どうやら2分間隔で定期的にパスワード変更が有った場合にそれを同期させているようです。細かいところだと、2分間の間に複数回同じIDで変更が掛かった場合は最新のパスワード情報のみ同期され、また、仮パスワード（次回ログオン時に変更を要求する物）については同期されないようです。
これを利用すると、管理者としてはプロビジョニングとパスワード管理の簡素化、利用者に対しても複数のパスワードを管理しなくて良いという利便性が提供できるので、手軽なソリューションとして利用できそうです。
Exchange Onlineでメーリングリストとして利用できる配布グループには、配布グループと（メールが有効な）セキュリティグループの2種類があります。また、ディレクトリ同期を有効にしている場合は、それぞれそのグループがオンプレミスのADで環境化で作成した物と、Office365で作成した物で、計4種類のグループが存在します。
今回は、その4種類を以下の通りとして、簡単にその特徴と使い分けについて紹介したいと思います。
| ①オンプレミスのAD上で作成 | ②Office365上で作成 | |
| A.配布グループ | dg1@contoso-jp.com | dg2@contoso-jp.com |
| B.セキュリティグループ | sg1@contoso-jp.com | sg2@contoso-jp.com |
A,Bの差は、
また、①②の差については、
などが大きいかと思います。
個人的な使い分けとしては、①のオブジェクトは少し作成・設定が面倒なので極力②をベースとして、
とかがお勧めです。
また、その他として「動的配布グループ」という物が有ります。これは、全ユーザーの属性（例えば部門や住所、個別に設定した拡張属性を含みます）をベースとしたグループになります。このグループは、「唯一メーリングリストのメンバーとして誰が含まれているか、Outlook/OWAなどから見ることができない」物になります。
などの場合に利用する事が多いかと思います。動的配布グループ自体は、オンプレミスで作成してもディレクトリ同期されないので、Office365側で作成します。（ベースとなる属性情報などはActive Directory側で作成します）
注意点としては、①は配布グループの細かい挙動に関する設定もオンプレミス側で実施する必要があります。デフォルトの設定から変更しなければならない場合は、特にGUIなどは用意されていないので、DisplayNameと同様にADSIエディタなどで直接値を入れなくてはいけません。主な設定項目は以下の通りです。
| デフォルト | 変更可能な値 | |
| 配布グループの管理者 (ManagedBy) |
Organization Management | 任意のユーザー （※DNを指定します） |
| メンバー展開後のNDRの送信先 (ReportToOwner,ReportToOriginator) |
送信しない | ①元の送信者 ②配布グループの管理者 |
| 配布グループに送信できるメンバー (msExchRequireAuthToSendTo) |
全員 | 内部のユーザーのみ |
| グローバルアドレス帳への掲載 (msExchHideFronAddressLists) |
載る | 載せない |
括弧内は対応するActive Directoryの属性。必要に応じてオンプレミスのADのスキーマを拡張する必要があります。
さすがに少し面倒なので、利用する際はPowerShellとかを上手く組み合わせて定型化することをお勧めさせて頂きます。
Office365の管理用PowerShellでは、シングルサインオンを行うのに必要なドメインの設定を行うことができます。
マイクロソフトが標準で提供するAD FSを利用する場合は、Office365側の設定とオンプレミスのADFSサーバの内容を一緒に更新してくれるNew-MsolFederatedDomain、Update-MsolFederatedDomain、Convert-MsolDomainToFederatedやConvert-MsolDomainToStandardコマンドレットが用意されており、同時に設定を更新してくれます。
対して、Shibbolethなど、AD FSとは異なる方式でシングルサインオンを構成しようとした場合、Office365ドメインの設定のみ変更をする必要があります。この場合に用意されているコマンドレットがSet-MsolDomainAuthenticationです。例えば、contoso.comのドメイン名の用途をシングルサインオンに構成したい場合は、以下の様にします。
Set-MsolDomainAuthentication -Authentication Federated -DomainName contoso.com
通常ドメインに戻したい場合は以下になります。
Set-MsolDomainAuthentication -Authentication Managed -DomainName contoso.com
コマンドとその処理対象に対するイメージはこんな感じです。
これは、AD FSに障害が発生して、緊急避難的にフェデレーションIDからクラウドIDにするのにも利用できます。通常はConvert-MsolDomainToStandardを利用して、
といった流れになりますが、AD FSサーバに接続できないとこのコマンド自体が発行できませんので、AD FSサーバー障害時など、そもそもアクセスできない場合は、Set-MsolDomainAuthenticationsコマンドレットで上記1番のみ実行し、その後3番の工程を手動で実施するという手法を取る形になります。
Windows Server 2012によるADFS構築に引き続き、今回はADFS ProxyサーバをWindows Server 2012上に構成してみたいと思います。
作成する環境はこんな感じです。通常はDMZ上の別セグメントに構成しますが、検証を行う上ではあまり関係ないので。
AD FSの時よりは準備は少ないです。基本的には公的証明書（通常はAD FSで利用している物と同じ物）をエクスポートした物さえ有れば良いです。今回は、Digicertさんで取った公的証明書を利用しています。ちなみに、なぜAD FS Proxyが必要だとか、公的証明書が必要だとかは過去の記事をご参照下さい。
まずは、hostsファイルを構成します。AD FS Proxyは通常インターネット上のDNSサーバを向いており、AD FSサービス名（例: sts.contoso.com）に対して接続をしようとした場合、自分自身のグローバルIPアドレスに解決してしまって接続できません。これを、DNSの名前解決より優先されるhostsファイルに書くことにより、AD FSサーバーに接続しに行くようにします。
続いては、[役割と機能の追加]で[Active Directoryフェデレーションサービス]を追加します。
依存する関連サービスのIISなども同時にインストールされます。
AD FSでは、[フェデレーションサービスプロキシ]を選択します。IISはデフォルトのままで大丈夫なので、次へを押していくとインストールが完了します。
続いて、SSL関係の設定を行います。IISサービスマネージャーを開き、[サーバー証明書]の項目を選びます。[インポート]を選択し、用意しておいた証明書（.pfxファイル）とパスワードを入力します。エクスポートできるようにチェックは付けておきます。
続いては、インポートした証明書を利用してSSLのサイトを作成します。IISマネージャーの[サイト]を開き、[Default Web Site]をクリックして[バインドの編集]を選択します。デフォルトでは、HTTP（ポート80）でしか応答しないようになっているので、HTTPS（ポート443）で先ほどのSSL証明書を利用してAD FSサービス名に対して応答するようにします。
最後に、AD FS Proxyの構成です。スタートメニューの[ADFSフェデレーションサーバープロキシの構成ウィザード]を選択します。
フェデレーションサービス名を入力すると、AD FSサービスへのアクセスの資格情報を求められます。ここでは、AD FSにアクセスできる管理アカウントを指定します。次へを押すと、構成が完了です。
OSの基本機能でほぼいけますので、簡単ですね。
また、外部DNSでAD FSサービス名をAD FS Proxyに接続できるグローバルIPアドレスに解決できるように構成しておきます。必要に応じて、AD FSの実際のアドレスにNATするようにFirewallの設定を行います。
動作確認の為、接続してみます。ポータルからIDを入力すると、自動的に画面がリダイレクトし、AD FS Proxyのフォーム認証画面に飛びます。ここで、ID/PASSを入力してして[サインイン]をクリックすると、Office365にActive Directoryの資格情報でサインインすることができます。
Windows Server 2012が発売された当初は、PowerShellモジュールが対応していなかった為に、レジストリをいじらないとOffice365へのシングルサインオンの設定ができなかったのですが、最近モジュールがバージョンアップされて、インストールできるようになったとのことで、早速試してみました。
今回は、検証環境としてこんな環境を作ってみたいと思います。（Office365は新しいバージョンのEnterpriseを利用しています。）
Office365のシングルサインオンの構成自体は、慣れていればかなり簡単に構成できるようになっていますが、少し事前の準備が必要な部分などが多いので、まずはその部分からいくつか説明します。
【準備①.ディレクトリ同期のアクティブ化】
Office 365管理センターの [ユーザーとグループ] – [シングルサインオン][管理]を開き、Active Directory同期の[アクティブ化]を選択します。これは、最大24時間かかると画面にも表示されますが、経験上も処理の完了までに数時間は掛かりますので、インストールの前日までに実施してアクティブ化しておくことをお勧めします。
【準備②.公的SSL証明書の発行】
ほとんどのケースにおいて、ADFSで利用する証明書は外部の公的機関の証明するSSL証明書が必要となります。（Go DaddyやComodoなどの安価な物でもOKです。） SSLの証明書の発行にはお金のやりとりや証明書類のやりとりなどで時間が掛かる場合があるので、早めに申請しておきます。
IISからであれば、[サーバー証明書]を開き[証明書要求の作成]からCSRを作成し、証明書が発行されたら[証明書要求の完了]をした後に秘密鍵と共に.pfxファイルに[エクスポート]しておきましょう。このファイルはAD FSならびにAD FS Proxy両方のサーバーで利用します。
【準備③.ADFSサービスアカウントの作成】
Active Directory内に、ADFSのサービス用アカウントを作成します。AD FSサービスはこのアカウントで実行されますが、パスワードの有効期限が切れた場合は動作できなくなりますので、[パスワードを無期限にする]を選択する必要があります。
AD FSサービスのインストール用のアカウントとして利用しないのであれば、特にドメインの管理権限は必要ありません。
【準備④.代替UPNサフィックスの設定（オプション）】
既存のActive Directoryが、インターネットから解決できないドメイン（例えばcontoso.local）で構成されている場合は、代替UPNサフィックスを作成して、ユーザーのUPN名を username@contoso.local から username@contoso.com に変更します。
Active Directoryドメインと信頼関係でプロパティを開き、[代わりのUPNサフィックス]の欄に自身で所有しているドメイン名を入力します。比較的ユーザー数が少ない場合などは、Active DirectoryユーザーとコンピューターからOffice365で利用するユーザーを選択した後、プロパティの[アカウント][UPNサフィックス]から代替UPNサフィックスに変更することができます。今後、新しくユーザーを作成する場合、プルダウンの中から代替UPNサフィックスが選択できるようになっているので、そちらを選択するようにします。
【準備⑤.ADFSサービス名の内部DNSへのレコードの作成】
ADFSサービス名は、内部DNSと外部DNSで異なるIPアドレスとして解決される必要があります。
（内部DNS…AD FSサーバー群、外部DNS…AD FS Proxyサーバー群）
内部のDNS（通常はActive DirectoryのDNS）において、代替UPNサフィックスのゾーンが存在しない場合は、それを追加します。contoso.com全体としてゾーンを作成しても良いですし、AD FSのサービス名（sts.contoso.com）のみのゾーンを作成しても構いません。今回は、AD FSサービス名のゾーンを作成して進めます。
ゾーンの準備ができたら、AD FSサービス名のAレコードを作成します。通常は、AD FSファームで利用する仮想IPを指定しますが、今回は検証環境で1台しかないので同じIPアドレスを指定します。
※なお、MXレコードやAutodiscoverのCNAMEレコードなど、Office365のドメインの情報で追加するように表示された物は外部DNSのみではなく内部DNSにも忘れずに書くようにして下さい。（内部DNSにゾーンが存在しない場合は外部DNSで解決されるので問題ありません）
【準備⑥.必要なコンポーネントのダウンロード】
シングルサインオン環境の構築に必要なモジュールは、全て事前にダウンロードが可能です。インストールをスムーズに行うためにも、事前にダウンロードして準備しておくのがよろしいかと思われます。サインインアシスタント以外は、Office 365管理センターの [ユーザーとグループ] – [シングルサインオン][管理]のページからダウンロード可能です。
これで、準備は完了です。
それでは、いよいよAD FSのセットアップに入っていきたいと思います。まずは、w15adfsをActive Directoryドメイン（w15jp.local）に所属させます。
そして、AD FSをインストールします。Windows Server 2008 R2などと違い、Windows Server 2012では標準でAD FSが役割として入っておりますので、[役割と機能の追加]から[Active Directoryフェデレーションサービス]を追加します。選択した際に、他に必要なモジュールも合わせて選択されます。
また、PowerShellモジュールのインストールに.NET Framework 3.5が必要なので、機能の欄で[.NET Framework 3.5 Features]を追加します。
この際、.NET Framerork 3.5の機能は、初期インストールされた際にデフォルトだとハードディスクにコピーされてきていないので、OSのインストールメディアをマウントし、そのパスを[代替ソースパスの設定]から指定します。（指定しないとインターネットからダウンロードして設定する形となりますので、環境にもよりますが時間がかかります。）
AD FSの構成の前に、事前準備の段階で用意しておいたSSL証明書を、IISマネージャーの[サーバー証明書]を開いてインポートしておきます。
引き続き、AD FSの初期設定を行います。AD FSファームの構築にはActive DirectoryへのSPNの設定権限が必要なので、ドメイン管理権限を持つアカウントでAD FSサーバーにログオンし、[管理ツール][AD FSの管理]を開き、[AD FSフェデレーションサーバーの構成ウィザード]を実行します。
今回は1台目のサーバーなので、[●新しいフェデレーションサービスを作成する][●新しいフェデレーションサーバーファーム]を選択します。
また、AD FSサービス名の指定では前の工程でインポートしたSSL証明書を選択し、AD FSサーバーファームのサービスアカウント名/パスワードも事前に作成しておいた物を指定します。
画面上では必要な構成が未完了ですと表示されますが、AD FSのOffice 365とのフェデレーション設定は、AD FS管理コンソールではなくPowerShellから実施するのでこの画面は一旦閉じます。
PowerShellからの設定を行うため、Microsoft Online Servicesサインインアシスタントをインストールします。
続いて、Windows PowerShell用Windows Azure Actitive Directoryモジュールをインストールします。これも、特にパラメーターなどはなくインストールできます。
今回は、以前投稿した独自ドメインの追加手順で使ったドメインを用いてそのままシングルサインオンを構成しますので、Convert-MsolDomainToFederatedコマンドレットを利用して行います。AD FSサーバー上からWindows PowerShell用Windows Azure Active Directoryモジュールを起動し、以下のコマンドを入力します。
$LiveCred = Get-Credential Connect-MsolService -Credential $LiveCred Convert-MsolFederatedDomainToFederated -DomainName w15jp.info
1行目のコマンドの際にID/PASSの入力を求められますので、Office365の全体管理者のID/PASSを指定します。Successfully Updated ‘w15jp.info’ domain.などと表示されれば処理は完了です。
これで、AD FSのセットアップは完了です。
引き続き、ディレクトリ同期のセットアップに移ります。今回は、AD FSと同一サーバー上にディレクトリ同期ツールをインストールしますので、ディレクトリ同期のセットアップエラーのエントリーで記載したとおり、事前にMicrosoft Online Servicesサインインアシスタントをアンインストールしてからインストールを実行します。
ディレクトリ同期ツールのインストーラーを管理者として実行します。
引き続き、Windows Azure Active Directory同期ツールの構成ウィザードに移ります。事前準備のディレクトリ同期のアクティブ化が完了していることを確認し、Windows Azure Active Directory管理者の資格情報にはOffice365の全体管理者アカウントを、Active Directoryの資格情報にはEnterprise Adminsの権限のアカウントを指定します。
これで、AD FSを利用してOffice365にシングルサインオンする環境が整いました。
早速動作を確かめてみたいと思います。ディレクトリ同期されたアカウントにはOffice 365のライセンスが割り当てられていませんので、Office 365管理センターから[同期済みユーザーのアクティブ化]を行い、ライセンスを割り当てます。
また、クライアント側でも1つ設定を行う必要があります。ブラウザから現在のログオン情報をAD FSサーバーに渡せるように、[インターネットオプション][セキュリティ]から、[ローカルイントラネット]にADFSサービスのアドレスを追加します。また、[信頼済みサイト]に*.microsoftonline.com、*.outlook.com、*.sharepoint.com、*.lync.comも追加しておきます。
そして、Office365のサインイン画面から自分のActive Directoryのアドレスを入れると、Office365にシングルサインオンができます。
ちなみに、2回目以降はクリックだけでシングルサインオンできるようになります。
BIG-IP LTM VEによるADFSの冗長化#1に準備した環境に、いよいよAD FSの冗長化設定を行っていきたいと思います。
まずは、カスタムのモニターを作成します。
ADFS側のモニターです。Intervalは少し長めにしますが、実際のID/PASSでログオンできるかどうかまでモニターしてますので、かなり正確にKeepAliveすることができるかと思います。
AD FS Proxy側は少しシンプルに、IISでTCP/443から正常応答が来るかどうかで判定しています。
これで、AD FS側とAD FS Proxy側のモニターが作成できました。
続いて、プールを作成します。（今回は単体の用途で利用しますので、ノードはプールの作成の中で同時に作成します。） AD FS、AD FS Proxyそれぞれで適切なモニタを設定した物を作成し、Load Balancing MethodをLeast Connections (member)にし、適切なサーバーのIPアドレスをノードに追加します。
正しく作成され、サーバも正常稼働している場合はプールのStatusが緑色の●の表示となります。
最後に、応答するVIP(バーチャルサーバ)を作成します。
IPアドレス等の他には、以下の様な設定を行います。
バーチャルサーバができあがると、プールと同じようにStatusが緑の●になります。
最後に、冗長化しているのでConfig Syncを行います。[Device]の[Overview]でMaster側のマシンを選択し、[Sync Device to Group]を選択して[Sync]します。
少し待つと、Sync Statusが緑色の●になります。
これで、設定は完了です。最後にポータルからサインインができるかどうかを確かめます。
問題なくサインオンできました。これで冗長化に必要な作業は完了です。
Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm”
https://devcentral.f5.com/blogs/us/big-ip-and-adfs-part-1-ndash-ldquoload-balancing-the-adfs-farm-rdquo
ADFSやADFS Proxyを冗長化する場合、アプリケーションレベルでの障害をKeepAliveにより検知し、自動的に切り離しを行おうとすると、Microsoft標準のNLBでは実現できず、ハードウェアのLBが必要になります。
従来は専用機を利用して高価なシステムとなっていたハードウェアロードバランサを利用した構成ですが、昨今、仮想上で動作する仮想化アプライアンスなどが安価に利用できるようになってきました。
今回はF5のBIG-IP Local Traffic Manager Virtual Edition(Hyper-V)などが発売され、比較的安価に、しかも冗長構成で組めるとのことで、手元のADFS環境に導入できるかどうか試してみました。
論理的には以下の様な感じの構成で組みたいと思います。（IPアドレスが飛び飛びなのは他のマシンがいっぱいるからです。見づらくてスイマセン。）
BIG-IPは勿論スタンドアロンの構成にすることもできますが、2台用意することにより冗長構成も取ることができます。今回は、異なるHyper-Vホスト上に2台置いて冗長構成としたいと思います。基本的な手順は同じなので1台目の方で説明します。
まずは、F5のサイトからHyper-V用のイメージを落としてきます。今回は11.3のイメージが有ったのでそれを利用します。
では、VMを立てていきたいと思います。メモリは4096MB割り当てます。パフォーマンスを重視したい場合は8192MBでも良いようです。また、NICは11.3ではレガシーではない通常のNICが利用できます。最初のNICがManagement用のポートになるので、新規作成のウィザードではそのvSWを指定します。そして、仮想ハードディスクとして先ほどダウンロードしてきたVHDファイルを指定してウィザードを終了させます。
次に、作成したVMの設定画面を開き、いくつか修正をします。プロセッサは「数を2に」「予約を100%に」します。LBでは周りのサーバの負荷に影響されずに安定した動作が求められている上での推奨事項です。
ネットワークアダプタで、他に必要なポートを追加します。スタンドアロンの場合は「Management」「Internal」「External」で3つ、冗長構成とする場合は「HA」を加えた計4つのNICを作成します。（HA構成の場合も、フローティングIP（VIP）は実MACアドレスで通信を行うのでMACアドレススプーフィングのチェックは入れなくて大丈夫です。）
また、自動停止アクションで「ゲストオペレーティングシステムをシャットダウンする」を選択します。
同様に2号機側も同じような設定で作成します。
これで、Big-IPを起動します。普通のLinuxコンソールが立ち上がってきますので、デフォルトのID: root / Pass: defaultでログインします。
BIG-IPの設定は基本的にブラウザから行いますが、そこに接続する為のManagementのIPを設定する必要がある為、configコマンドを実行します。（もしManagementのセグメントでDHCPが有効化されているのであればこの工程は省略できます）
簡易的なユーティリティが立ち上がりますので、IPとサブネット、もし管理PCが異なるセグメントから接続してくる場合はデフォルトゲートウェイを設定します。なお、このインターフェイスは実際のサービスとは切り離されて利用されます。ここで設定したデフォルトゲートウェイは管理用にのみ利用されます。
設定したIPに対してブラウザから接続します。証明書エラーが出ると思いますが、無視して進めます。
初期パスワードはID: admin Pass: adminです。（先ほどのrootとは違うので注意して下さい）
初期設定は、セットアップユーティリティに従って実施します。
最初はライセンスのアクティベーションを行います。私の環境だとなぜか上手くオンラインでできなかったので、Activation MethodでManualを選択し、ブラウザからライセンスキーを取得して設定しました。正しいキーを入れてしばらく待つと、アクティベーションされます。
Resource Provisioningは特に今回は検証環境で意識しないのでそのままNextを選択します。
Management関連の設定です。先ほど設定したIPアドレスを確認（DHCPで割り当てていた場合はそれを固定設定）して、rootならびにadminのパスワードなどを適宜設定します。
続いて、ネットワークの構成です。Standard Network Configurationで行いますのでNextを選択します。
Redundancyの設定はそのままNextで進めます。
続いて、ネットワークインターフェイスの設定を行います。順番はInternal、External、HAのになります。また、最初にHyper-Vから作成したvNICが順に1.1,1.2,1.3として認識されていますので正しい値とvNICを割り当てます。
ConfigSync、Failover、Mirroringの設定はそれぞれデフォルトのままでNextとします。
これで、Active/Standbyのペア設定を行うためのActive機側の準備が整いました。続いて、Stanby機の方でも設定を行います。（Standby機の方はConfigure Peer Deviceの画面でFinishedを押してセットアップユーティリティを完了させておきます。）
Standby機の設定が完了した後、Active機側でDiscover Configured Peer DeviceでNextを押して設定を進めます。
セカンダリ機の情報を入力し、Retrieve Device Informationを押すと、セカンダリ側の情報が取得できますので、Finishedします。
Device ManagementのOverviewから同期の状態が見れますので、ここでSyncを押すと同期が完了します。
Standby側のステータスも変更されます。
これで、HA構成のロードバランサが設定できました。続いては実際のADFSの冗長化に取り掛かりたいと思います。
（参考）
Manual: BIG-IP Virtual Edition Setup Guide for Microsoft Hyper-V
http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ve-hyper-v-setup-11-3-0.html
Big-IP and ADFS Part 1 – “Load balancing the ADFS Farm”
https://devcentral.f5.com/blogs/us/big-ip-and-adfs-part-1-ndash-ldquoload-balancing-the-adfs-farm-rdquo
BIG-IP LTM Virtual Edition Trial セットアップガイド
http://f5networks.co.jp/shared/pdf/BIG-IP_TB_setup_ve_trial.pdf
Office365は、プランE・プランP共にディレクトリデータベースとしてWindows Azure Active Directoryを利用しています。Azure側は特に両者の区別はなく展開されており、利用するサービスが違うという扱いです。
この為、Windows Azure Active Directoryのポータルにサインオンすると、プランPとしてはサポートされていない（メニューに出てこない）シングルサインオンなどのメニューもプランE同様に表示されます。ここでは、Windows Azure Active Directoryを利用してADFSによるシングルサインオンをセットアップする手順を紹介致します。
ポータルにOffice365のアカウントを利用してサインインします。ポータルが表示された後は、メニューから独自ドメインを追加します。
手順はOffice365と同じです。ドメイン名を入力後に表示される ms=MSｘｘｘｘｘｘｘｘ という値をそのドメインのTXTレコードに追加して、確認を行います。
追加後はそのドメインの用途を選択する画面になりますので、必要なサービスを選択します。続いてその独自ドメインをOffice365で利用する際に必要なDNSレコードが表示されます。後から再度表示させることもできますので、ここではDNSの設定はせずに先に進みたいと思います。
続いて、新たなメニュー「統合」を開き、「ディレクトリ同期」のメニューを開きます。ADFSの展開前に、まず最初に時間のかかる（経験上、数時間以上掛かる場合もあります）「アクティブ化」を選択します。選択後はバックグラウンドで処理が行われていますので、シングルサインオンの設定に進みたいと思います。
まず、ADFS2.0 RTWをダウンロードし、インストールします。ついでにADFS 2.0 RU2（KB2681514）もインストールしておきます。
ADFSの設定ウィザードに行く前に、準備（①必要な証明書をIISにインストールする ②ADFSの実行用アカウントを作成する）をしておきます。ウィザードは特に上記2つの設定が出るくらいです。デフォルトWebサイトを先に作成している場合、デフォルトWebサイトの構成で警告が出ますが、特に問題は無いので先に進みます。
続いて、ドメインでシングルサインオンを有効化します。前項でドメインを既に追加している場合は、Convert-MsolDomainToFederatedコマンドレットを、新規で追加したドメインをシングルサインオンとして構成する場合はNew-MsolFederatedDomainコマンドレットを使用します。ここでは、新規追加の場合を例に挙げておきます。
事前準備として、サインインアシスタントとWindows PowerShell用Microsoft Online Servicesモジュールをインストールしておきます。
Connect-MsolService New-MsolFederatedDomain -DomainName contoso.com New-MsolFederatedDomain -DomainName contoso.com
1回目のNew-MsolFederatedDomainコマンドの後に、所有確認用のDNSレコードが表示されますので、追加後に再度同じコマンドを実行します。このコマンド終了後、今回は同じマシンにディレクトリ同期もインストールしようと思っており、これが残っているとディレクトリ同期のインストールに失敗するのでサインインアシスタントを一回アンインストールします。
次に、ディレクトリ同期のインストールです。10/23現在、Windows Azure Active Directoryポータルからダウンロード可能なディレクトリ同期ツールは、残念ながら今年いっぱいでサポート終了が決まっている32bit版なので、64bit版をOffice365からダウンロードするのが良いと思います。
ディレクトリ同期ツールは、インストールに比較的時間はかかるものの、特に選択肢は無くそのまま終了します。また、ここでサインインアシスタントが同時にインストールされてます。同梱されているバージョンが単体で入手できる物より少し古いので、気になる方はWindowsUpdateでバージョンアップすると良いと思います。
一旦Office365のポータルに戻って、ディレクトリ同期が有効化されたことを確認してからディレクトリ同期の設定に入ります。
必要な情報は、Office365のインポート/エクスポートに利用するOffice365の管理者アカウントと、ADからの同期用アカウント（MSOL_AD_SYNC）の設定を行うのに必要なADの管理者アカウントの情報です。
と、ここまでの工程を実施すると、
プランP1のテナントでもディレクトリ同期やシングルサインオンができるようになります。
ちなみに、Windows Azure Active Directoryポータルを経由しなくても、直接PowerShellコマンドレット（Set-MsolDirSyncEnabled -EnableDirSync $true）とかでも有効化できます。
ただし、プランP1のサポートはコミュニティサポートのみであり、コミュニティでは基本的にシングルサインオンなどは対象外となっているようなので、お試しの際はあくまで自己責任で実施されるようお願い致します。
