Windows Server 2012によるADFS構築

Windows Server 2012が発売された当初は、PowerShellモジュールが対応していなかった為に、レジストリをいじらないとOffice365へのシングルサインオンの設定ができなかったのですが、最近モジュールがバージョンアップされて、インストールできるようになったとのことで、早速試してみました。

今回は、検証環境としてこんな環境を作ってみたいと思います。(Office365は新しいバージョンのEnterpriseを利用しています。)
20130401_01

Office365のシングルサインオンの構成自体は、慣れていればかなり簡単に構成できるようになっていますが、少し事前の準備が必要な部分などが多いので、まずはその部分からいくつか説明します。

【準備①.ディレクトリ同期のアクティブ化】
Office 365管理センターの [ユーザーとグループ] – [シングルサインオン][管理]を開き、Active Directory同期の[アクティブ化]を選択します。これは、最大24時間かかると画面にも表示されますが、経験上も処理の完了までに数時間は掛かりますので、インストールの前日までに実施してアクティブ化しておくことをお勧めします。
20130331_54

【準備②.公的SSL証明書の発行】
ほとんどのケースにおいて、ADFSで利用する証明書は外部の公的機関の証明するSSL証明書が必要となります。(Go DaddyやComodoなどの安価な物でもOKです。) SSLの証明書の発行にはお金のやりとりや証明書類のやりとりなどで時間が掛かる場合があるので、早めに申請しておきます。

IISからであれば、[サーバー証明書]を開き[証明書要求の作成]からCSRを作成し、証明書が発行されたら[証明書要求の完了]をした後に秘密鍵と共に.pfxファイルに[エクスポート]しておきましょう。このファイルはAD FSならびにAD FS Proxy両方のサーバーで利用します。
20130331_55 20130331_56 20130331_57 20130331_58 20130331_59

【準備③.ADFSサービスアカウントの作成】
Active Directory内に、ADFSのサービス用アカウントを作成します。AD FSサービスはこのアカウントで実行されますが、パスワードの有効期限が切れた場合は動作できなくなりますので、[パスワードを無期限にする]を選択する必要があります。

AD FSサービスのインストール用のアカウントとして利用しないのであれば、特にドメインの管理権限は必要ありません。
20130331_07

【準備④.代替UPNサフィックスの設定(オプション)】
既存のActive Directoryが、インターネットから解決できないドメイン(例えばcontoso.local)で構成されている場合は、代替UPNサフィックスを作成して、ユーザーのUPN名を username@contoso.local から username@contoso.com に変更します。

Active Directoryドメインと信頼関係でプロパティを開き、[代わりのUPNサフィックス]の欄に自身で所有しているドメイン名を入力します。比較的ユーザー数が少ない場合などは、Active DirectoryユーザーとコンピューターからOffice365で利用するユーザーを選択した後、プロパティの[アカウント][UPNサフィックス]から代替UPNサフィックスに変更することができます。今後、新しくユーザーを作成する場合、プルダウンの中から代替UPNサフィックスが選択できるようになっているので、そちらを選択するようにします。
20130331_09 20130331_10 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で解決されるので問題ありません)
20130331_12 20130331_13

【準備⑥.必要なコンポーネントのダウンロード】
シングルサインオン環境の構築に必要なモジュールは、全て事前にダウンロードが可能です。インストールをスムーズに行うためにも、事前にダウンロードして準備しておくのがよろしいかと思われます。サインインアシスタント以外は、Office 365管理センターの [ユーザーとグループ] – [シングルサインオン][管理]のページからダウンロード可能です。

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

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

それでは、いよいよAD FSのセットアップに入っていきたいと思います。まずは、w15adfsをActive Directoryドメイン(w15jp.local)に所属させます。
20130331_06

そして、AD FSをインストールします。Windows Server 2008 R2などと違い、Windows Server 2012では標準でAD FSが役割として入っておりますので、[役割と機能の追加]から[Active Directoryフェデレーションサービス]を追加します。選択した際に、他に必要なモジュールも合わせて選択されます。
20130331_14 20130331_15 20130331_16 20130331_17 20130331_18 20130331_19

また、PowerShellモジュールのインストールに.NET Framework 3.5が必要なので、機能の欄で[.NET Framework 3.5 Features]を追加します。

この際、.NET Framerork 3.5の機能は、初期インストールされた際にデフォルトだとハードディスクにコピーされてきていないので、OSのインストールメディアをマウントし、そのパスを[代替ソースパスの設定]から指定します。(指定しないとインターネットからダウンロードして設定する形となりますので、環境にもよりますが時間がかかります。)
20130331_20 20130331_20-2 20130331_21 20130331_22 20130331_23 20130331_24 20130331_25 20130331_26 20130331_27

AD FSの構成の前に、事前準備の段階で用意しておいたSSL証明書を、IISマネージャーの[サーバー証明書]を開いてインポートしておきます。
20130331_35
20130331_36 20130331_37

引き続き、AD FSの初期設定を行います。AD FSファームの構築にはActive DirectoryへのSPNの設定権限が必要なので、ドメイン管理権限を持つアカウントでAD FSサーバーにログオンし、[管理ツール][AD FSの管理]を開き、[AD FSフェデレーションサーバーの構成ウィザード]を実行します。

今回は1台目のサーバーなので、[新しいフェデレーションサービスを作成する][●新しいフェデレーションサーバーファーム]を選択します。

また、AD FSサービス名の指定では前の工程でインポートしたSSL証明書を選択し、AD FSサーバーファームのサービスアカウント名/パスワードも事前に作成しておいた物を指定します。
20130331_38 20130331_39 20130331_40 20130331_41 20130331_42 20130331_43 20130331_44

画面上では必要な構成が未完了ですと表示されますが、AD FSのOffice 365とのフェデレーション設定は、AD FS管理コンソールではなくPowerShellから実施するのでこの画面は一旦閉じます。
20130331_45

PowerShellからの設定を行うため、Microsoft Online Servicesサインインアシスタントをインストールします。
20130331_28 20130331_29

続いて、Windows PowerShell用Windows Azure Actitive Directoryモジュールをインストールします。これも、特にパラメーターなどはなくインストールできます。
20130331_30 20130331_31 20130331_32 20130331_33 20130331_34

今回は、以前投稿した独自ドメインの追加手順で使ったドメインを用いてそのままシングルサインオンを構成しますので、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.などと表示されれば処理は完了です。
20130331_46

これで、AD FSのセットアップは完了です。

引き続き、ディレクトリ同期のセットアップに移ります。今回は、AD FSと同一サーバー上にディレクトリ同期ツールをインストールしますので、ディレクトリ同期のセットアップエラーのエントリーで記載したとおり、事前にMicrosoft Online Servicesサインインアシスタントをアンインストールしてからインストールを実行します。

ディレクトリ同期ツールのインストーラーを管理者として実行します。
20130331_47 20130331_48 20130331_49 20130331_50 20130331_51

引き続き、Windows Azure Active Directory同期ツールの構成ウィザードに移ります。事前準備のディレクトリ同期のアクティブ化が完了していることを確認し、Windows Azure Active Directory管理者の資格情報にはOffice365の全体管理者アカウントを、Active Directoryの資格情報にはEnterprise Adminsの権限のアカウントを指定します。
20130331_52 20130331_53
20130331_61 20130331_62 20130331_63 20130331_64 20130331_65

これで、AD FSを利用してOffice365にシングルサインオンする環境が整いました。

早速動作を確かめてみたいと思います。ディレクトリ同期されたアカウントにはOffice 365のライセンスが割り当てられていませんので、Office 365管理センターから[同期済みユーザーのアクティブ化]を行い、ライセンスを割り当てます。
20130331_66 20130331_67 20130331_68 20130331_69

また、クライアント側でも1つ設定を行う必要があります。ブラウザから現在のログオン情報をAD FSサーバーに渡せるように、[インターネットオプション][セキュリティ]から、[ローカルイントラネット]ADFSサービスのアドレスを追加します。また、[信頼済みサイト]に*.microsoftonline.com、*.outlook.com、*.sharepoint.com、*.lync.comも追加しておきます。
20130331_70

そして、Office365のサインイン画面から自分のActive Directoryのアドレスを入れると、Office365にシングルサインオンができます。
20130331_71 20130331_72 20130331_73

ちなみに、2回目以降はクリックだけでシングルサインオンできるようになります。
20130331_74

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

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

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

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

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

20130326_02

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

  • Interval : 30 seconds
  • Timeout : 91 seconds
  • Send String : GET /\r\n

20130326_03

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

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

20130326_05 20130326_06 20130326_07

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

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

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

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

20130326_10 20130326_11

バーチャルサーバができあがると、プールと同じようにStatusが緑のになります。
20130326_12

最後に、冗長化しているのでConfig Syncを行います。[Device]の[Overview]でMaster側のマシンを選択し、[Sync Device to Group]を選択して[Sync]します。
20130326_13

少し待つと、Sync Statusが緑色のになります。
20130326_14

これで、設定は完了です。最後にポータルからサインインができるかどうかを確かめます。
20130326_15 20130326_16 20130326_17

問題なくサインオンできました。これで冗長化に必要な作業は完了です。
20130326_18

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

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アドレスが飛び飛びなのは他のマシンがいっぱいるからです。見づらくてスイマセン。)
20130325_00

BIG-IPは勿論スタンドアロンの構成にすることもできますが、2台用意することにより冗長構成も取ることができます。今回は、異なるHyper-Vホスト上に2台置いて冗長構成としたいと思います。基本的な手順は同じなので1台目の方で説明します。

まずは、F5のサイトからHyper-V用のイメージを落としてきます。今回は11.3のイメージが有ったのでそれを利用します。

では、VMを立てていきたいと思います。メモリは4096MB割り当てます。パフォーマンスを重視したい場合は8192MBでも良いようです。また、NICは11.3ではレガシーではない通常のNICが利用できます。最初のNICがManagement用のポートになるので、新規作成のウィザードではそのvSWを指定します。そして、仮想ハードディスクとして先ほどダウンロードしてきたVHDファイルを指定してウィザードを終了させます。
20130325_01 20130325_02 20130325_03 20130325_04 20130325_05

次に、作成したVMの設定画面を開き、いくつか修正をします。プロセッサは「数を2に」「予約を100%に」します。LBでは周りのサーバの負荷に影響されずに安定した動作が求められている上での推奨事項です。

20130325_06

ネットワークアダプタで、他に必要なポートを追加します。スタンドアロンの場合は「Management」「Internal」「External」で3つ、冗長構成とする場合は「HA」を加えた計4つのNICを作成します。(HA構成の場合も、フローティングIP(VIP)は実MACアドレスで通信を行うのでMACアドレススプーフィングのチェックは入れなくて大丈夫です。)
20130325_07

また、自動停止アクションで「ゲストオペレーティングシステムをシャットダウンする」を選択します。

20130325_08

同様に2号機側も同じような設定で作成します。

これで、Big-IPを起動します。普通のLinuxコンソールが立ち上がってきますので、デフォルトのID: root / Pass: defaultでログインします。
20130325_09

BIG-IPの設定は基本的にブラウザから行いますが、そこに接続する為のManagementのIPを設定する必要がある為、configコマンドを実行します。(もしManagementのセグメントでDHCPが有効化されているのであればこの工程は省略できます)
20130325_10

簡易的なユーティリティが立ち上がりますので、IPとサブネット、もし管理PCが異なるセグメントから接続してくる場合はデフォルトゲートウェイを設定します。なお、このインターフェイスは実際のサービスとは切り離されて利用されます。ここで設定したデフォルトゲートウェイは管理用にのみ利用されます。
20130325_11 20130325_12

設定したIPに対してブラウザから接続します。証明書エラーが出ると思いますが、無視して進めます。
20130325_13

初期パスワードはID: admin Pass: adminです。(先ほどのrootとは違うので注意して下さい)
20130325_14

初期設定は、セットアップユーティリティに従って実施します。
20130325_15

最初はライセンスのアクティベーションを行います。私の環境だとなぜか上手くオンラインでできなかったので、Activation MethodでManualを選択し、ブラウザからライセンスキーを取得して設定しました。正しいキーを入れてしばらく待つと、アクティベーションされます。
20130325_16 20130325_17 20130325_18

Resource Provisioningは特に今回は検証環境で意識しないのでそのままNextを選択します。
20130325_19

Management関連の設定です。先ほど設定したIPアドレスを確認(DHCPで割り当てていた場合はそれを固定設定)して、rootならびにadminのパスワードなどを適宜設定します。
20130325_20

続いて、ネットワークの構成です。Standard Network Configurationで行いますのでNextを選択します。
20130325_21

Redundancyの設定はそのままNextで進めます。
20130325_22

続いて、ネットワークインターフェイスの設定を行います。順番はInternal、External、HAのになります。また、最初にHyper-Vから作成したvNICが順に1.1,1.2,1.3として認識されていますので正しい値とvNICを割り当てます。
20130325_23 20130325_24 20130325_25

ConfigSync、Failover、Mirroringの設定はそれぞれデフォルトのままでNextとします。
20130325_26 20130325_27 20130325_28

これで、Active/Standbyのペア設定を行うためのActive機側の準備が整いました。続いて、Stanby機の方でも設定を行います。(Standby機の方はConfigure Peer Deviceの画面でFinishedを押してセットアップユーティリティを完了させておきます。)

Standby機の設定が完了した後、Active機側でDiscover Configured Peer DeviceでNextを押して設定を進めます。
20130325_29 20130325_30

セカンダリ機の情報を入力し、Retrieve Device Informationを押すと、セカンダリ側の情報が取得できますので、Finishedします。
20130325_31 20130325_32

Device ManagementのOverviewから同期の状態が見れますので、ここでSyncを押すと同期が完了します。
20130325_33

Standby側のステータスも変更されます。
20130325_34

これで、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

(リンク)
BIG-IP LTM VEによるADFSの冗長化#2

SRVレコード対応のドメインレジストラ

Office365での独自ドメインの利用(RocketNet)でも書いたとおり、Office365のLyncでフェデレーションを利用する為にはSRVレコードが必要です。

残念ながら、日本のドメインレジストラに付帯してくるDNSホスティングサービスではOffice365の技術blog Office 365 で利用するための日本の主要なレジストラーにおける DNS の設定方法にも記載が有るとおり、ほとんど対応していない状況です。

Office365が発売されて時間も経ちましたので、折角なのでSRVレコードの対応状況を調べてみました。

まず、上記サイトでも紹介されていた5つのレジストラ

ですが、残念ながら現時点でもSRVレコードには対応していませんでした。折角なので、今後の対応予定が無いか尋ねてみます。Yahooのみメールでの問い合わせ窓口が分からなかったので送れませんでしたが

件名:DNSサービスの機能に関する問い合わせ

突然の問い合わせ失礼いたします、○○と申します。

マイクロソフトにて公開されております情報を読み、連絡をさせて頂いております。
 http://community.office365.com/ja-jp/blogs/office_365_technical_blog/archive/2012/05/14/office-365-dns-setting-for-major-japanese-registrar.aspx

マイクロソフトで拡販に力を入れているOffice365というサービスが有り、 中小企業を中心に
導入が進んでおります。この中で、LyncというIM/プレゼンス/テレビ会議などを実施することが
できるサービスが、他ユーザーやSkypeなど他サービスとの連携を行う際に SRVレコードの実装が
必須となっております。

ニーズとしては非常に大きいかと思うのですが、御社DNSサービスにおいて 今後SRVレコードに
対応される予定はございませんでしょうか?

よろしくお願い致します。

さすがにこの辺は回答早いですね。4サービスとも翌日には「対応予定無し」「貴重なご意見ありがとうございます」という感じの返答を頂きました。

という訳で、見つけられているレジストラは以下しか今のところは紹介できません。

ドメインレジストラのやっている無償のDNSホスティングはサービスでやっているような物ですから、新たなコンパネの機能開発投資は難しいというのは分かるんですけどね…。

SRVレコードを直接サポートというわけでは無いのですが、直接ゾーンファイルの内容をいじれるなど、間接的には以下でも実装可能ですね。

しっかり使うのであればVPSのLinux OSホスティングを月1000円くらいで借りてきて、そこでbindを運用。セカンダリ側だけレジストラに依頼するのが楽かもしれませんね。

Small BusinessでLync管理センターに接続

Exchange Onlineと同様、Small Businessのテナントからは、Lync Onlineの管理者画面(Lync管理センター)に接続するためのメニューは提供されていません。

管理者による設定は、全て管理ポータルの[サービス設定][IM、ミーティング、および会議]などの画面から設定を行う形になります。
20130320_09

ただ、こちらもExchange同様、管理者画面へのリンクが張られていないだけであり、実際は接続するすることは可能です。管理画面のURLは、https://admin.online.lync.com/lscp/?language=ja-JP です。(テナント毎に収容が異なる可能性が有ります。)
20130320_10

本来のURLは、上記から更に細分化されたhttps://admin0f.online.lync.com/lscp/?language=ja-JP&tenantID=(テナントID) などになります。上記のURLなどで接続できない、設定が反映されないなどの場合は、テナントIDは、上記管理画面のHTMLファイルのソースを見れば<div id=”TraceInfoDiv”>の中にTID=で入っていますので調べることが可能です。
20130320_08

非サポートの手順となりますので、いつ接続できなくなるか分からない/この画面から設定変更することによりその後のサービスの利用に支障を来す可能性が有る、など、接続の際には十分ご留意頂ければと思います。

Small BusinessでExchange管理センターに接続

Exchange Onlineのブラウザによる設定は、通常Exchange管理センター(略EAC、旧ECP:Exchangeコントロールパネル)から実施します。

ただし、新しいOffice 365のSmall Business(Premium含む)については、Exchange、SharePoint、Lyncの設定をそれぞれの画面から実施するのでは無く、管理ポータル上から一元的に実施できるようにインターフェイスが変更されています。

例えば、サービス設定の画面からは予定表の共有やActiveSyncの設定が行えます。
20130320_01 20130320_02 20130320_03

ユーザーとグループからは、外部連絡先/配布グループ/共有メールボックスの作成などが行えます。
20130320_06 20130320_07

ただし、現在の時点で設定できる項目は少なく、従来行えていたようなよりきめ細やかな設定などは実施することができません。

また、OWAの設定メニューの[オプション]を押せば、Exchange管理センターにつながりますが、個人用の設定の画面のみであり、従来接続できた[組織]の設定の画面に行くことができません。(MidsizeBusiness/Enterpriseであれば、上部の[管理者▼]メニューの[Exchange]から接続できますが)
20130320_04

そこで、Exchange管理センターに接続したい場合は、管理者アカウントから上記画面に接続した後、ブラウザのアドレスバーの/ecp/以降の文字列?rfr=owa…以降を全て削除したURL(https: //pod510xx.outlook.com/ecp/ )に対して接続します。そうすると、管理者アカウントのデフォルト画面である組織の管理画面に接続することができます。
20130320_05

PowerShellからの接続同様、【利用できるけどサポート無し】というポリシーでの利用となるかと思いますのでご使用の際にはご留意頂ければと思います。

特定条件下でConnect-MsolServiceが失敗する

久しぶりにADFSの環境を構築しようとして、検証環境でConnect-MsolServiceコマンドレットでWindows Azure Active Directoryに接続しようとしたところ、なぜか以下のエラーが出て接続できない事象が発生するようになりました。

PS C:\> Connect-MsolService -Credential $LiveCred 
Connect-MsolService : 要求チャネルは、応答を待機してから 00:00:59.8905882 後に
タイムアウトしました。Request の呼び出しに渡すタイムアウト値を増やすか、Binding
 の SendTimeout 値を増やしてください。この操作に割り当てられた時間は、より長い
タイムアウト時間の一部であった可能性があります。
発生場所 行:1 文字:1
+ Connect-MsolService -Credential $LiveCred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], Tim
   eoutException
    + FullyQualifiedErrorId : System.TimeoutException,Microsoft.Online.Adminis
   tration.Automation.ConnectMsolService
Connect-MsolService : 種類 'Microsoft.Online.Administration.Automation.Microsof
tOnlineException' の例外がスローされました。
発生場所 行:1 文字:1
+ Connect-MsolService -Credential $LiveCred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Connect-MsolService], Mic
   rosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.Micro
   softOnlineException,Microsoft.Online.Administration.Automation.ConnectMsol
  Service

エラーの内容からすると、単なるタイムアウトっぽいです。
20130318_01

他の環境から実行したところ特に問題く接続できるので、クラウド側の障害とかでは無さそうに思えます。下の方のレイヤでの障害が疑われるので、とりあえずWireSharkでパケットを追ってみると、何となくそれらしい所が見つかりました。
20130318_02

Connect-MsolServiceでは、まずlogin.microsoftonline.com(実体はlogin.microsoftonline.com.nsatc.net)に接続しに行った後、provisioningapi.microsoftonline.com(実体はprd-provisioning.msods.nsatc.net)に接続しにいくのですが、このprd-provisioning.msods.nsatc.netがAAAAレコードを持っているというところがポイントの様です。

というのも、この検証環境のOSはデフォルトの構成で適当に組んでいるので内部セグメントではIPv6が有効化されており、ドメコン上のDNSサーバで名前解決もできるのですが、ルーターやFirewall、回線はIPv6対応していなく、IPv6でインターネットに向けて通信ができないという、ちょっと特殊な環境です。

ご存じの通り、Windowsでは同一ホスト名に対してIPv4とIPv6の両方で接続ができる場合、IPv6での接続を優先的に試みます。今回、IPv6の通信がタイムアウトで失敗してIPv4にフェールバックされてくる前に、PowerShellの接続モジュールの方が耐えきれなくなってタイムアウトしている…という状況のようです。

…というわけで、IPv6を切ったら何の問題も無く繋がるようになりました。
20130318_05
20130318_04

Office365も段々とIPv6対応してくるサービスが増えてくるようなので、もう少ししっかりIPv6の構成をオンプレでも見直していった方が良いかもしれませんね。