ディレクトリ同期環境での配布グループ

Posted on 2013年4月21日 by genkiw • Posted in Exchange Online, Office365, Work, シングルサインオンとディレクトリ同期 • Leave a comment

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の差は、

AはExchangeのみで利用できるグループ
Bは権限の設定（オンプレミスのファイルサーバーやSharePoint Online）で利用できる

また、①②の差については、

①はActive Directoryでメンバーの変更を行う。この為、Office365で作成されたユーザーをメンバーに加えることはできず、同じくActive Directory上にいるディレクトリ同期されたユーザーのみメンバーにすることができる。
②は、Exchange Onlineの機能でセルフサービス配布グループ（配布グループの作成、削除、配布グループへの参加または脱退をグループの管理者に委任することができる）として構成することができる。
①は作成する際にADSIエディタなどでDisplayNameの属性を直接設定する必要がある。

などが大きいかと思います。

個人的な使い分けとしては、①のオブジェクトは少し作成・設定が面倒なので極力②をベースとして、

社内でファイルサーバの権限などと合わせて設定されている部署・部門毎のグループのみ①-Bとして作成し、人事異動などの際の管理を容易にする。SharePoint Onlineの権限もこのグループを利用する。
特定プロダクトやプロジェクトのMLなどについては②-Aとする。（同グループがSharePoint Onlineサイトを作成する場合は②-Bとする。）

とかがお勧めです。

また、その他として「動的配布グループ」という物が有ります。これは、全ユーザーの属性（例えば部門や住所、個別に設定した拡張属性を含みます）をベースとしたグループになります。このグループは、「唯一メーリングリストのメンバーとして誰が含まれているか、Outlook/OWAなどから見ることができない」物になります。

社外のアドレスや個人の携帯電話のアドレスが含まれているグループ
“組合員”など”再雇用者”などの比較的センシティブな情報を取り扱うグループ
“首都圏の全ユーザー”などメンテナンスが難しいグループ

などの場合に利用する事が多いかと思います。動的配布グループ自体は、オンプレミスで作成してもディレクトリ同期されないので、Office365側で作成します。（ベースとなる属性情報などはActive Directory側で作成します）

注意点としては、①は配布グループの細かい挙動に関する設定もオンプレミス側で実施する必要があります。デフォルトの設定から変更しなければならない場合は、特にGUIなどは用意されていないので、DisplayNameと同様にADSIエディタなどで直接値を入れなくてはいけません。主な設定項目は以下の通りです。

	デフォルト	変更可能な値
配布グループの管理者 (ManagedBy)	Organization Management	任意のユーザー（※DNを指定します）
メンバー展開後のNDRの送信先 (ReportToOwner,ReportToOriginator)	送信しない	①元の送信者 ②配布グループの管理者
配布グループに送信できるメンバー (msExchRequireAuthToSendTo)	全員	内部のユーザーのみ
グローバルアドレス帳への掲載 (msExchHideFronAddressLists)	載る	載せない

括弧内は対応するActive Directoryの属性。必要に応じてオンプレミスのADのスキーマを拡張する必要があります。

さすがに少し面倒なので、利用する際はPowerShellとかを上手く組み合わせて定型化することをお勧めさせて頂きます。

新しいOffice 365 ProPlusを移行前のE3で使う

Posted on 2013年4月16日 by genkiw • Posted in Office ProPlus, Office365, Work • Leave a comment

Office365のE3などを利用しているユーザーは、最新のOfficeがサブスクリプションで利用できます。ただし、現在アップデートがまだ行われていないテナントでは新しいOfficeを利用できません。

今回は、少しでも早く利用を開始したい方の為に、アップグレード前のE3テナントで新しいOffice（2013ベース）を利用できる方法を紹介します。

※本投稿による手順は、あくまで検証に基づく物でありMicrosoftによって正式にサポートされていない可能性が有ります。実施は自己責任で実行をお願いします。

まず、アップグレード前のテナントではOfficeのダウンロードリンクが表示されていません。アップグレード後のテナントからURLを直接抜いてくるのもスマートでは無いので、公開されている情報であるOffice Deployment Tool for Click-to-Runから利用したいと思います。

詳細は以前の記事を参照して頂ければと思いますが、setup.exeとconfiguration.xmlを取り出し、以下の様にxmlファイルを作成し、/downloadでイメージをダウンロードした後、/configureで各クライアントに展開します。

<Configuration>
  <Add SourcePath="\w15ad01share" OfficeClientEdition="32" >
    <Product ID="O365ProPlusRetail">
      <Language ID="ja-jp" />
    </Product>
  </Add>
  <Updates Enabled="TRUE" />
  <Display Level="None" AcceptEULA="TRUE" />
  <Logging Name="OfficeSetup.txt" Path="%temp%" />
  <Property Name="AUTOACTIVATE" Value="1" />
</Configuration>

例えば、上記の場合は、/downloadを付けて実行するとイメージがw15ad01上の共有フォルダshareに最新の32bit版がダウンロードされます。

続いて、/configureスイッチを付けて実行すると、クライアントでインストールが実行されます。
c:>\w15ad01sharesetup.exe /configure \w15ad01shareconfiguration.xml

すると、スタートメニューに2013ベースの新しいOffice ProPlusがインストールされます。

何かのアプリケーション（例えばWord）を立ち上げると、Officeのライセンス認証を求められますので、ここでおもむろに既存E3テナントのメールアドレス（ID）、パスワードを入力します。

すると、アップグレード前のテナントでも認証され、新しいProPlusが利用できます。

ちなみに、このやり方の場合、Office2013自体が認証機能を持っているため、別途サインインアシスタントのインストールは必要ありません。

Office365の管理されたクイック実行

Posted on 2013年4月11日 by genkiw • Posted in Office ProPlus, Office365, Work • 1 Comment

Office 365で提供されるOffice Professional Plusは、従来のインストーラーを利用したインストールという方式ではなく、オンデマンドでのストリーミング配信という方式になりました。

ストリーミング配信には2種類あり、①クイック実行　②オンデマンドとなってます。オンデマンドは基本的にテンポラリで一時的に利用する物になりますが、今回は常用するクイック実行について話をしたいと思います。

クイック実行は、通常は各クライアントから直接Office365（実体はインターネット上のキャッシュサーバー）に要求が出され、ダウンロードされます。パッケージはExcelやWordなどのコンポーネント単位では無く、Officeスイート全体のパッケージとしてダウンロードされます。

また、毎日更新の有無がチェックされて常に最新の状態のOfficeが利用されるようになります。この更新は、「更新する必要のあるデータのみ」「Officeスイート全体として」ダウンロードされます。

このダウンロードならびに更新の適用についてですが、企業（特に中規模～大企業）で利用しようとすると、通常の方式だと「新規ならびに更新のタイミングで大量のインターネットトラフィックが発生する」「IT管理者が関知しないバージョンアップが実施される」などの問題が発生することが想定されます。

この為、クイック実行ではIT管理者により管理したOffice365の展開ということが可能になってます。共有フォルダ1つあれば実現できますので、簡単にその方法を紹介したいと思います。

まずは、Download Center(英語)からOffice展開ツールをダウンロードします。（ベータ用の物では無いバージョンをダウンロードして下さい。）

Office Deployment Tool for Click-to-Run
http://www.microsoft.com/en-us/download/details.aspx?id=36778

ダウンロードした物を実行すると、使用許諾が表示されるので、確認してContinueを押します。続いて、解凍先を求められるので、展開に利用する共有フォルダに展開します。

解凍が完了すると、configuration.xml と setup.exeという2つのファイルが作成されます。

まず、configuration.xmlの内容を修正して、ダウンロードするプロダクトのエディッションと言語パックを指定します。今回は、サンプルとして32bit版のOffice365の日本語、英語版をダウンロード対象としてみます。

.xmlファイルの構成が終わったら、setup.exe /download configuration.xml を実行します。

共有フォルダ配下にOffice – Data – (バージョン名)の階層のフォルダが作成され、現在のバージョンのファイルがダウンロードされます。また、xml内で指定された日本語と英語の言語パックもダウンロードされます。

あとは、実際の利用シーンに合わせてxmlファイルをカスタマイズし、管理者がテストされたバージョンのOfficeを利用者の言語に合わせて展開してあげればOKです。例えば、15.0.4481.1510のテストが完了したので、日本のユーザー向けに以下の様なconfiguration-jp.xmlを作成します。

このファイルを読み込むように指定して、クライアントPCからファイルサーバー上のsetup.exeを実行します。\serversharesetup.exe /configure \servershareconfiguration-jp.xml 　すると、コマンドを実行して数分でインストールされたプログラムとして登録されます。

ネットワークの帯域にも因りますが、1GB程度の転送が終了するとコマンドも終了します。実環境では、このコマンドを配信してインストールさせていくような感じになるかと思われます。

また、xml内で更新チェックの場所もファイルサーバーとして指定しましたので、インストール後の更新はそのファイルサーバーをチェックし、管理者により置かれた更新が有った場合、差分をダウンロードする形となります。

今後メインの配布・更新方法になっていくと思われますので、一杯触ってノウハウを溜めていきたいと思います。

詳細な情報などは以下のMicrosoftのサイトを参照になさって下さい。

【参考】
クイック実行用 Office 展開ツール
http://technet.microsoft.com/ja-jp/library/jj219422.aspx

Office 365 クイック実行製品をカスタマイズする方法
http://blogs.technet.com/b/office_jp/archive/2013/02/06/office-365-how-to-customize-clicktorun-for-office-365.aspx

Office 365 ProPlus 管理者シリーズ: クライアントの展開オプション
http://blogs.technet.com/b/microsoft_office_/archive/2012/12/07/office-365-proplus.aspx

Set-MsolDomainAuthentocation

Posted on 2013年4月5日 by genkiw • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • Leave a comment

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を利用して、

Office365のドメインの認証方式をID/PASSによる通常の方式に変換
ADFSのOffice365の設定を削除
Active DirectoryのID情報を元に、Office365のユーザーに対して初期パスワードを発行

といった流れになりますが、AD FSサーバに接続できないとこのコマンド自体が発行できませんので、AD FSサーバー障害時など、そもそもアクセスできない場合は、Set-MsolDomainAuthenticationsコマンドレットで上記1番のみ実行し、その後3番の工程を手動で実施するという手法を取る形になります。

Windows Server 2012によるADFS Proxy構築

Posted on 2013年4月3日 by genkiw • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • Leave a comment

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の資格情報でサインインすることができます。

Office365アップデート通知（その後）

Posted on 2013年4月3日 by genkiw • Posted in Office365, Office365全般, Work • Leave a comment

喜んだのもつかの間、延期通知が来ましたorz

さて、バージョンアップはいつになることやら…

Office365アップデート通知

Posted on 2013年4月2日 by genkiw • Posted in Office365, Office365全般, Work • Leave a comment

ついに私のP1テナントにもアップグレード通知が来ました。

予想と違ったのは、以下くらいですかね？

1ヶ月前予告が無かった（P1だから？）
アップグレードの延期オプションがP1でも有った

ポータルにログインすると、しっかり通知文が出るようになりました。

ちなみに、通知メールのfromは Microsoft Office 365 Team <Office365@microsoftonline.com> タイトルはサービスに関する通知: Office 365 サービスのアップグレードが 2013年・・・・・日に予定されています です。

管理者の権限を持っているユーザー全員＋パートナー（登録している場合）に対して送信されますので、spamだと思って捨てないようにお気を付け下さい。

Windows Server 2012によるADFS構築

Posted on 2013年3月31日 by genkiw • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • 13 Comments

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サフィックスが選択できるようになっているので、そちらを選択するようにします。
20130331_11

【準備⑤.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管理センターの [ユーザーとグループ] – [シングルサインオン][管理]のページからダウンロード可能です。

Microsoft Online Servicesサインインアシスタント（msolidcli_64bit.msi）
Windows PowerShell用Windows Azure Actitive Directoryモジュール（AdministrationConfig-JA.msi）
ディレクトリ同期ツール（dirsync-ja.exe）

これで、準備は完了です。

それでは、いよいよ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の冗長化#2

Posted on 2013年3月26日 by genkiw • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • 1 Comment

BIG-IP LTM VEによるADFSの冗長化#1に準備した環境に、いよいよAD FSの冗長化設定を行っていきたいと思います。

まずは、カスタムのモニターを作成します。

ADFS側のモニターです。Intervalは少し長めにしますが、実際のID/PASSでログオンできるかどうかまでモニターしてますので、かなり正確にKeepAliveすることができるかと思います。

Interval : 30 seconds
Timeout : 91 seconds
Send String : GET /adfs/fs/federationserverservice.asmx HTTP/1.1rnHost: rnConnection: Closern
Receive String : HTTP/1.1 200 OK
User Name : (ADFSでのアクセスが可能なADのアカウント)
Password : (上位アカウントのパスワード)

AD FS Proxy側は少しシンプルに、IISでTCP/443から正常応答が来るかどうかで判定しています。

Interval : 30 seconds
Timeout : 91 seconds
Send String : GET /rn

これで、AD FS側とAD FS Proxy側のモニターが作成できました。

続いて、プールを作成します。（今回は単体の用途で利用しますので、ノードはプールの作成の中で同時に作成します。）　AD FS、AD FS Proxyそれぞれで適切なモニタを設定した物を作成し、Load Balancing MethodをLeast Connections (member)にし、適切なサーバーのIPアドレスをノードに追加します。

正しく作成され、サーバも正常稼働している場合はプールのStatusが緑色の●の表示となります。

最後に、応答するVIP(バーチャルサーバ)を作成します。

IPアドレス等の他には、以下の様な設定を行います。

Type : Performance (Layer 4)
Source Address Translation : Auto Map
Default Pool : (先ほど作成した物)

バーチャルサーバができあがると、プールと同じように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

BIG-IP LTM VEによるADFSの冗長化#1

Posted on 2013年3月26日 by genkiw • Posted in Office365, Work, シングルサインオンとディレクトリ同期 • 1 Comment

BIG-IP LTM VEによるADFSの冗長化#2

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アドレススプーフィングのチェックは入れなくて大丈夫です。）