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.1rnHost: rnConnection: Closern
  • 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 /rn

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の構成をオンプレでも見直していった方が良いかもしれませんね。

OWAのカスタマイズ(メイン機能)

新しいOffice365では、今までPowerShellからしか実行できなかった設定変更のうち、利用頻度の高い物をGUI(Exchange管理センター)から実施できるようになりました。今回は、機能のON/OFFのうち、ニーズの多い物について説明したいと思います。
20130317_00

まずは、連絡先(画面上での表記はPeople)についてです。連絡先関係で制御ができるのは、主に以下のパターンです。

  1. ソーシャル連携(LinkedIn、Facebook)を無効化したい
  2. 「全てのグループ」「全ての会議室」などのアドレス帳を無効化したい
  3. グローバルアドレス帳自体を無効化したい
  4. Peopleの表示自体を消したい

1)のソーシャル連携、良く話を受けますがインターネット上の個人のアカウントと会社のメールのアドレス帳の連携は禁止したいという要望は日本の企業としては大きいようです。GUIからは「LinkedIn連絡先の同期」「Facebook連絡先の同期」のチェックを外します。PowerShellから実施する場合は、Set-OwaMailboxPolicyの「-LinkedInEnabled $false」「-FacebookEnabled $false」です。
20130317_08 20130317_09

2)について、Outlookではビル毎の会議室などのアドレス帳のサブセットを作った際に階層構造で表示できるのですが、OWAは名前順になってしまうので、見た目上あまり綺麗じゃないなどの場合に利用します。PowerShellだと「-AllAddressListsEnabled $false」です。

これを適用すると、個人の連絡先の他に[ディレクトリ]だけ表示されるようになります。
20130317_03

3)のグローバルアドレス帳(2番でいう[ディレクトリ])を無効化するというのは、PowerShellからしか実施できませんが、2の設定に加えて「-GlobalAddressListEnabled $false」を指定すれば表示を個人の連絡先だけにするということができます。

この状態でも、メール作成時などに検索をすることはできますので、アドレス一覧で運用するのが現実的では無いような大規模なユーザーではニーズがある設定かと思います。
20130317_02

4)はGUIからであれば[連絡先]のチェックを外す、PowerShellの場合は「-ContactsEnabled $false」で消せます。かなりドラスティックですが、個人の連絡先を消す場合はこの設定になります。前述の通り検索は可能なので、グローバルアドレス帳の検索のみでの運用としたい場合はこの設定にします。
20130317_11

続いては、予定表関係です。 予定表は他のグループウェアなどで管理しているので利用させたくない場合などに利用します。

GUIの場合は[予定表]のチェックボックスを、PowerShellであれば「-CalendarEnabled $false」で予定表自体の表示を消せます。Outlookと併用している場合など必要に応じて[アラームと通知]も消して下さい。
20130317_12

タスク(仕事)に関してはGUIの[タスク]かPowerShellの「-TasksEnabled $false」で設定ができます。私の試した限りでは、環境ではメール下部の[タスク]の表示は消えず、クリックするとタスク画面に移ったのがクリックしてもタスク画面に移れないという挙動に変更になりました。
20130317_06 20130317_07

メモ、OWAからの場合は受信トレイの下部フォルダから見れるようになっているのですが、これも消せます。GUIの[メモ]またはPowerShellの「-NotesEnabled $false」です。
20130317_10

さて、これらを全て消すと、Exchange Onlineしかサブスクリプションを設定しないユーザーはOutlookしか表示されなくなり、かなりシンプルになります。本当に限定的なWebメーラーとしての使い方をしたい場合にはアリかもしれません。
20130317_13

Set-OwaMailboxPolicy OwaMailboxPolicy-Default -TasksEnabled $false -CalendarEnabled $false -ContactsEnabled $false

ただ、将来的には会議室予約やタスク・スケジュールとの連携などExchangeのフル機能を利用し、業務を効率化していく事を是非目指していって欲しいですね。

最後に注意点ですが、これはあくまでOWAから接続できないように設定をしているのみですので、Outlookを利用した場合は普通に利用できます。そちらも合わせて制御するのであればOfficeのポリシーテンプレートとかで制御する必要があります。

Office 365 Enterpriseの独自ドメイン

前回のOffice 365 Midsize Businessに引き続き、今回はOffice 365 Enterpriseにおける独自ドメインについて書きたいと思います。

すいません、最初に言っておきます。この記事を投稿した時点ではMidsize Businessとの違いが見つけられませんでした。(今後変更になるかもしれないので、一応エントリーは分けて作成しておきます)

ドメイン関係のメニューなので、[ドメイン]メニューを開き、[ドメインの追加]を選択します。
20130316_01 20130316_02

Enterpriseのドメインの確認プロセスは、以下の3つのプロセスです。

  1. ドメイン名の確認
  2. 独自ドメイン名を持つユーザーの作成
  3. ドメインの目的の設定とDNSレコードのチェック

まずはドメインの確認を行います。ドメイン名を入力すると
20130316_03 20130316_04 20130316_05

そして、ここで出力された物をDNSサーバーに登録します。
20130316_06

DNSキャッシュのせいで少し時間が掛かる可能性が有りますが、これでドメインの所有確認が完了します。
20130316_07
20130316_08

続いてはこの独自ドメイン名を持つユーザーを追加するという工程ですが、これは後からでも追加できますので、特に追加せずに次に進みたいと思います。
20130316_09 20130316_10

最後に、独自ドメインを利用する上でのDNSのチェックです。以前はこの部分は後からトラブルシュートで実施することができましたが、今回からはウィザード中で実施する必要があるようです。

まずはドメインの用途を「Exchange Online」「Lync Online」「SharePoint Online」で選択します。デフォルトでは、Exchange OnlineとLync Onlineのチェックが付いていますが、SharePointのみ排他利用なので、チェックを入れる場合(サイト名として利用する場合)はExchange,Lyncでは利用できません。

ここでLyncのチェックを外したとしてもログオン用のIDとしてその独自ドメインを利用した場合、そのユーザーにLyncのサブスクリプションを付与するとその独自ドメインのSIPアドレスを持つアカウントがLyncで作成されてしまうので、あまり意味は持たないのかもしれません。

独自ドメイン名自体をExchange,Lyncにして、wwwなどのサブドメインを作成してそちらをSharePoint Onlineで利用されるというパターンが多いようです。
20130316_11 20130316_12 20130316_13

ここで表示されたレコードをDNSサーバーの方に設定させて、チェックが通ればこの工程は終了です。ちなみにここのチェックが完了していなくても、設定自体は完了しているのでOffice365は問題なく利用できます。特にSRVレコードが作成できない場合や、他のメール配信サーバーがあってSPFのTXTレコードの値をカスタマイズしている場合など、無視して利用する形になります。
20130316_14
20130316_15

ついでなので、PowerShellからドメインを追加する場合の手順について記載します。

ドメインの追加には、Windows PowerShell 用 Microsoft Online Services モジュールを立ち上げてOffice 365に接続後、New-MsolDomainコマンドレットを実行します。ドメイン認証用コードの取得はGet-MsolDomainVerificationDnsです。
20130316_18

確認はConfirm-MsolDomainコマンドレットで行います。エラーが出ない場合は成功です。画面の表示は変わりませんが、Get-MsolDomainでのStatusがUnverifiedからVerifiedに変わります。
20130316_18

また、最初に追加されたドメインの場合はそのテナントの既定のドメインにするという設定に自動的になりますので、そちらも必要に応じて修正します。

New-MsolDomain -Name ドメイン名
Get-MsolDomainVerificationDns -Mode DnsTxtRecord -DomainName ドメイン名
Confirm-MsolDomain -DomainName ドメイン名
Set-MsolDomain -Name ドメイン名 -IsDefault

1点だけ異なるのが、デフォルト状態でのドメインの用途がGUIから追加した場合はExchange OnlineとLync Onlineにチェックが入っていますが、PowerShellから作成した場合は用途に何も設定されていません。

このままだと、作成するDNSレコードの詳細などが分からないので[ドメイン]メニューから[DNS設定の表示]を開き、[ドメインの目的を変更する]でGUIのSTEP3のメニューを手動実行しましょう。

また、これは少し原因が分からないのですが、Confirm-MsolDomain コマンドレットで認証を行った場合、GUIの設定画面のSTEP1の最後の部分がエラーが出て完了できません。前述の通り、ドメインの認証さえ終わっていれば(GUIの場合DNS設定の表示が出せる状態、PowerShellの場合はGet-MsolDomainの値がVerifiedになっている状態)「セットアップが進行中です」のステータスのドメインでも問題なく利用できますが、少し気持ち悪いですね。

Office 365 Midsize Businessの独自ドメイン

2月より新たに提供開始された1-250名規模の企業向けのプラン、Office 365 Midsize Businessにおける独自ドメインの使用について紹介したいと思います。

Midsize Businessのメニュー体系は、プランEとほぼ同じです。独自ドメインの追加は[ドメイン]メニューの[ドメインの追加]から実施します。
20130315_01 20130315_02

Small Business Premiumが5ステップだったのに対して、こちらはDNSサーバをユーザー側で用意する分、手順が3ステップとかなり簡単になっています。

  1. ドメイン名の確認
  2. 独自ドメイン名を持つユーザーの作成
  3. ドメインの目的の設定とDNSレコードのチェック

まずは、追加したい独自ドメイン名を入力します。
20130315_03 20130315_04

手順の中では主要レジストラの手順が紹介されていますが、日本の場合は[一般的な手順]を読むと良いでしょう。
20130315_05

既存のDNSサーバに指定されたTXTレコードを記載します。ちなみに、このゾーンは試験用に作ったドメインということでデフォルトのTTL(最初の行)が300秒に設定されてますが、通常は3600(1時間)とか86400(1日)とかが多いと思うので、その場合はレコード毎のTTLを少し落として設定しても良いですね。(後でSPFとして利用されるTXTレコードの設定値をチェックする工程があるので、そこでの確認時間短縮のため)
20130315_06

最初のうちは以前の値がキャッシュされていたり、セカンダリDNS側への伝搬が完了していなかったりするので認証されなかったりしますが、キャッシュがクリアされ次第認証されます。(以前にTXTレコードが1つも無かった場合は、”そんなレコードは無い”という情報が他のDNSサーバでキャッシュされている可能性がありますが、ネガティブキャッシュと呼ばれるこの種のキャッシュの生存期間はSOAレコードの最後の行:minimumで指定されています。上記例であれば1日。気になるようであれば300秒とかに短縮しておきましょう)
20130315_07 20130315_08

続いて、独自ドメイン名のアカウントを作成できます。特に後からでも追加できますので、ここでは[今はユーザーを追加しません]を選択します。
20130315_09 20130315_10

次に、ドメインの目的とDNSのレコードチェックを行います。用途としては、ほぼ2択であり「(デフォルト)①Exchange、Lyncでサービス用のIDとして利用する」「②SharePointのWebサイトとして利用する」のどちらかになります。

ちなみに、ここで下の高度なセットアップを開いて[社内のメールボックスがOffice365で動作するようにセットアップ~]を選択すると、オンプレミスのExchange 2010とのハイブリッド構成用のコネクタの作成などがこの工程中で実施できます。
20130315_11 20130315_13

DNSサーバに設定するレコードの一覧が表示されます。メールで利用するTXTレコード、MXレコードの値が.protectionのサブドメインの付く新しい値に変わっているので、前のバージョンに慣れていた方は入力ミスにご注意下さい。
20130315_14 20130315_15

以前はここでウィザードは終了だったのですが、ここでDNSレコードがしっかり登録できたかどうかのチェックが終わらないと、セットアップが完了しないようになりました。以前もトラブルシュートの画面から設定を手動で確認することができたのですが、今回からは必須要件になったようです。

全てのレコードの設定が正しくないとエラーがでます。TXTとMXが正しく設定しているのに確認が取れないという場合は、おそらく手順1のチェックの際に取得した値をMicrosoft側のDNSがキャッシュとして保持していた場合のエラーなので、おとなしくキャッシュがクリアされる時間を待って再度確認します。

この工程ですが、チェックが完了していなくてもドメインの使用自体は既にできるようになっておりますので、お急ぎの場合は[閉じて後で戻る]などでも良いと思います。その場合、ドメインメニューを開いた場合のステータスが[セットアップが進行中]になります。そのリンクをクリックするとまたこのウィザードに戻る事が可能です。
20130315_16 20130315_17

これが完了すると、ドメインが正しく追加されます。DNSの設定を確認したりドメインの目的を編集したい場合は、[DNS設定の表示]を開いて行います。
20130315_18
20130315_19

余談ですが、また追加後の独自ドメインのステータスが[アクティブ]になりましたね。これ、以前のバージョンで、リリース当初は[アクティブ]だったのですが、途中からいつのまにか[確認済み]に仕様変更されていて、よくユーザーから「マニュアルの手順通りにやっても書いてある結果(アクティブ)にならない。どうしてだ?」と問い合わせを受けたものです…