Office365を独自ドメインで利用する(プランP)

(2012/2/4更新)メニューのスナップショットを現行の物に変更

Office365は、SOHO、小規模企業向けのプランP(IT スタッフまたは専門家のいない、従業員が 25 人未満の組織)と、中規模企業以上の規模の企業向けのプランEがございます。機能的に一部制約がある(例えば、AD FSは利用できない)などの話は聞いてましたが、どうやら独自ドメインでの運用に大きな違いがあるらしいということで、試用版の環境をお借りして検証を実施してみました。

①まず、管理メニューのドメインからドメインの追加を選択し、ドメイン名を入力します。
 

ドメインの確認方法について表示されますので、プルダウンメニューから一般的な手順を選択すると、認証用のDNSレコード情報が表示されます。
 

Office365で独自ドメインを利用するには所有確認の為の認証が必要となりますが、認証を行うには、ここで表示されるレコード(TXTレコードもしくはMXレコード)を、ユーザが管理しているDNSサーバに設定する必要があります。つまり、ユーザはドメインを取得するだけでなく、そのドメインのレコード情報を設定できるDNSサーバを用意する必要があります。

ここでは、ドメインの登録事業者の中で、無料でDNSホスティングを提供してくれていて、かつTXTレコードにも対応しているGMO Internetさんのお名前.comを利用してドメインを設定してみたいと思います。新規で取得したドメインという設定ですが、既存の場合にも適用できるようにいくつか工程を挟んでいきます。

②お名前.comにログオンした後に、ドメイン編集メニューからレンタルDNSレコード設定をクリックします。複数ドメインを管理されている場合は、Office365で利用したい独自ドメイン名を選択し、入力画面へ進むをクリックします。
 

ホスト名は空欄のまま、TYPEに【TXT】を、VALUEに【MS=msxxxxxxx】と上記で出ていた認証用のDNSレコードの値を入力し、追加をクリックします。レコード追加の項目に正しい値が入力されていることを確認し、下の【レンタルDNSレコード設定用ネームサーバ設定確認】のチェックボックスが入っていることを確認し、確認画面へ進むをクリックし、確認するをクリックします。
 

確認画面の後に、DNSレコードが登録されます。
 

ここで、登録が終わったと思ってすぐにOffice365の認証を行ってはいけません。実際に、私はここで急いでクリックをしてしまった結果、認証に24時間掛かってしまいました。というのも、画面では処理が完了したと出ていますが、実施をしている処理は実際には数分時間を要している様です。③GMO側で処理が終わると、数分後に完了通知のメールが来ます。nslookupコマンドで登録したレコードが確認できます。

重要な工程として、裏で同時にネームサーバの切り替え(DNSホスティング無し:ns1.onamae.com→DNSホスティング有り:01.dnsv.jp)が実施されているのですが、ここが失敗すると時間が掛かるポイントです。例えば今回の場合でいう365poc.infoのTXTレコード検索ですが、先に365poc.infoのDNSサーバがどこかが検索され、その情報が1日間キャッシュされます。つまり、切り替え前のns1.onamae.comに聞きに行ったことのあるサーバは、その後1日間は01.dnsv.jpに切り替わったことに気がつかずにns1.onamae.comにTXTレコードの値を検索に行き続けます。これは事前に設定でどうこうなる問題ではないので、この事態に陥ったらあきらめましょう。

もちろん、通常はOffice365で使うDNSで、初めて使うドメイン名のNSレコードの情報がキャッシュされていることはあり得ないので、正しく他の端末から検索が可能な状態になっていれば、失敗せずに行けるはずです。
 

C:> nslookup -type=ns example.com
C:> nslookup -type=txt example.com

④DNSが引けるようになったら、晴れて認証画面の方に戻り、確認ボタンをクリックすると、ドメイン名が認証されてOffice365で利用できるようになります。

さて、プランPではここで見慣れない処理の指示が表示されます
「ドメインのレジストラの設定でネームサーバの設定をMicrosoftの指定のDNSに向けて下さい」

えっ?だってそうしたら今まで入れていたWebサーバ用のAレコードとか、DNSサーバ用のNSレコードとかはどうするの!? いえいえ、心配有りません。Office365はそれら全ての機能を持っています。会社のオフィシャルホームページも移して来れますので、DNSサーバを切り替えるついでに、それ以外のホスティングとか全部解約してきて下さい。

…いえ、すいません、そんなことはありません。MicrosoftのDNSでも、ちゃんとホームページ用のAレコードなどは追加出来ますので、ご自身の環境向けにカスタマイズして下さい。⑤指示は無視してキャンセルし、管理メニューのドメインから独自ドメインのプロパティの表示を選び、DNSマネージャーを選択します。ちなみにこのメニューはプランPにしかありません。
  

⑥現在のレコードが表示されてます。最初はOffice365で利用するDNS情報のみ表示されておりますので、⑦ホームページなどを既に外部で持っている場合はそのホストのAレコード(wwwや@)を追加します。これで、メールの切り替えが完了したら、いつの間にか会社のホームページが見れなくなっていたなどの事象は解消できます。
 

DNSの切り替えを実施する場合、原則は移行先の新しいDNSサーバで古いサーバと同じ情報を投入してから切り替えを実施するのが定石です。なぜなら、レジストラ側で保持しているネームサーバの設定は、軒並み長めのTTLが設定されていることが多く、脅し文句では無く普通にインターネット上の情報が全て切り替わるまで1~数日かかります。ここはローカルのDNSサーバの設定では制御出来ない部分なので、移行期間は新旧どちらのサーバに見に来ても同じ動作になるように設定をします。

2011/7/19現在 digコマンドで調べたネームサーバのTTL(キャッシュ期間)
.com/.net : 2日
.org/.info/co.jp/or.jp/.me/.nu/.to : 1日
.biz : 2時間

まあ、普通のホストのレコードの変更や追加などとは違って、通常は切り替えることはほとんど実施しないので、発生頻度からすると変では無い事なのですが、この状態の中いきなり切り替えを勧めてくる(しかも、移行に必要なOffice365側の設定値はネームサーバを変えろという指示をキャンセルしてからでないと表示されない)Microsoftは凄いなぁ、と思いますけど。

また、ドメインを追加した直後は⑨Exchangeや⑩アンチスパム(FOPE)のドメインの追加処理が完了していない(最大1~2日程度かかるらしい)事があったり、ユーザのメールボックスの作成が完了してないことが考えられるので、先に準備やできる限りで試験を実施しておきましょう。

そして、ようやくネームサーバ切り替えの一歩手前という事で、旧サーバの方にも新サーバの設定を入れます。ちなみに、これによりMXレコードの切り替わりが発生しますので、この時点からメールはOffice365に届くようになります。設定はDNSマネージャーで表示できますので、それを入れます。ちなみに、Exchangeで必要なのが上3つ(最低限MXレコードだけは必要)、Lyncで必要なのが下2つ(どちらとも無くても手動でセットアップ可能)になります。

⑪今回は、お名前.comで新規に取ったドメインという前提なので、既存のドメイン情報にレコードを追加したいと思います。ただし、SRVレコードは作成が出来ない為、Exchange用のMX、CNAME、TXTレコードのみ追加します。確認が終わったら変更するボタンを押します。
 

さて、これでようやくネームサーバーを(ある程度)安全に切り替えることが出来そうです。さすがに私はこれをすっ飛ばしてとりあえず「ネームサーバー切り替えて下さい」と言える勇気はさすがに無いです。⑫ネームサーバ変更から、既存で設定されているサーバを削除してns1.bdm.microsoftonline.com、ns2.bdm.microsoftonline.comを設定します。担当者の名前や電話番号を入れる部分はGMOはwhois代行サービスもやっているので、適当に既存で設定されているGMOの値を入れます。
 

これで設定終了です。簡単にまとめると以下のような感じですかね。

①管理メニューから追加するドメイン名を入力し、認証に必要なTXTレコードを取得する。
②別ウィンドウでDNSホスティングサービス等のメニューに接続するなどして、①で取得したレコードを確認する。
③②で設定したTXTレコードや必要に応じて変更したNSレコードの変更が新規検索をした際に反映されている事を確認する。
④①の画面に戻り、認証を行う
⑤ネームサーバを切り替える指示が来るが、キャンセルする
⑥DNSマネージャーを開き、Office365利用に必要なDNSの情報を取得する
⑦DNSマネージャーから、既存のDNSサーバに設定されているレコードの情報をOffice365のDNSにも追加する
⑧既存DNSサーバのMXレコードのTTLを300秒等の小さい値に変えておく(メールの切り替えを実施する場合のみ)
⑨Exchange Onlineで各ユーザのメールボックスを作成する
⑩FOPE経由で追加するドメイン宛のメールが着信出来るかtelnetコマンドなどでSMTPコマンドを叩いてチェックする
⑪既存DNSサーバにOffice365利用に必要な情報を追加し、MXレコードをxxx.mail.eo.outlook.comに切り替える
⑫ドメインのレジストラから、ネームサーバをns1.bdm.microsoftonline.com、ns2.bdm.microsoftonline.comに変更する

また、参考までに軽く触った限りのプランPのドメイン周りの制約事項ですが、以下の感じです。これでも問題ないという事であれば、無料で使えるリソースですし、活用されるのも良いかもしれません。

  1. 追加できるレコードの種類はAレコードかCNAMEレコードのみ
  2. TTLは最短で1時間
  3. Office365で利用するドメインとしてサブドメインは登録自体が不可
  4. DNSサーバはMicrosoftが用意すると言っている割には最初の登録の際にユーザが設定可能なDNSサーバまたは他のDNSサービスが必要。

Office365にAD FSを利用して何とかシングルサインオンしてみる

Office365は、ADFSを利用すると、シングルサインオンにログインができます。

というのも、通常はログイン画面でログオンIDを手動で入力して、出てくるリンクをクリックするという手間が発生するからです。(ログオンIDは前回入力した値が保存できるので、毎回毎回入れなくても大丈夫ですが)

最初にポータル画面にアクセスすると、まず以下のような画面になります。Microsoft Online Service IDの欄に、AD FSで設定した普段利用しているActive Directoryのログイン名(user@domain形式)を入力します。

入力が終わると下のパスワード入力欄がグレーアウトし、新たに現れる「xxxxxにサインインする」というリンクをクリックすることにより、(4回くらいのリダイレクトを経て)Office365にログインされます。

これは、Office365のログインサイトは各ユーザ共通であり、ここのフォームでパスワードも入れて入力するアドレス(クラウドID)か、パスワードはOffice365側では持っておらずAD FSサーバにリダイレクトして認証処理を行うアドレスか(フェデレーションID)が最初の時点では判断が付かないからというのが原因です。

ここの@以下の値(realm)をポータル側でチェックして、フェデレーションドメインだった場合はリンクを出す処理をしています。

リンクをクリックした後のアクセスの流れですが、かなり端折って話をすると①Office365 ⇒ ②AD FS ⇒ ③Office365の順にアクセスをすることになります。が、前の記事にも書きましたが、ここで入力したメールアドレスは②の認証では実は利用されていません。

よって、①でログインIDを入力してサインインするをクリックするという工程は、実は省略しても良いのでは?と邪推してしまいます。という訳で早速実験してみましょう。「xxxxxにサインインする」のリンクをクリックして飛ぶurlを取得します。

https://sts.example.com/adfs/ls/cbcxt=out&vv=&username=hoge@example.com&mkt=&…

どうやら、入力したユーザ名や戻り先のサイトの情報を一緒に付けて送ってきているようです。urlエンコードしているみたいですが、%2526などのように二重でurlエンコードされている物も有りそうです。

とりあえずこれをデコードしつつ整理します。その後、1つ1つ省略してアクセスできるかどうかを試してみました。

結構省略できそうです。結果的に、以下のurlに社内のポータルサイトからリンクを張ってアクセスすることにより、シングルサインオン環境が実現できました。(無理無理感は有りますが…)

https://sts.example.com/adfs/ls/?wa=wsignin1.0&wtrealm=urn:federation:MicrosoftOnline&wctx=wreply%3Dhttps:%252F%252Fportal.microsoftonline.com

※AD FSサーバのアドレス(上記の例だとsts.example.com)がイントラネットサイトとして認識されている必要がありますので、必要に応じてIEのゾーンの設定をする必要があります。

※手元の環境だと、これを使ってログインした後にOWAを表示させると画面表示が崩れるという事象が発生することがありましたが、その場合は「Office デスクトップ アプリケーションのセットアップと構成」を実行することにより正常な状態に戻りました。

AD FS環境でログオンユーザ以外でログオン(非SSO)を行う

AD FS環境だと、ポータルではログインIDを入れるのみでパスワードは入力せず、そのままイントラネットのAD FSサーバにリダイレクトされ、そこで認証されてOffice365へのアクセスが行われます。

これはこれで便利な機能なのですが、運用上、他のアカウントでOffice365へのアクセスを実施する必要が出てくる場合が有ります。例えば、外部受付用の共有アカウントでの作業や、退職者のバックアップ作業などの場合です。

testuseroneというアカウントでWindowsにログインしていて、shared-userというアカウントでOffice365に接続しようとするシチュエーションを考えます。まず、ポータルで、普通にログインをしようとしてみます。

あれ…testuseroneのアカウントのままログオンされてしまいました。

どうやら、AD FS側ではOffice365ポータルで入力したユーザアカウントの値は特に検証せず、Active Directoryにログオン出来るかどうかのみを判断してOffice365側にチケットを発行しているようです。

普通に解決しようとするなら、AD FSのクレーム発行ルールを変更して…ということになるのだとは思うのですが、まだ勉強不足なので、今回は他のやり方を考えてみます。

  • まず、FirefoxでのOffice365へのシングルサインオン で紹介したとおり、Firefoxはデフォルトではログイン情報をWebサイトに飛ばしませんので、共用アカウントでのログオンにはFirefoxを利用してID/PASS入力で入る。
  • または、IEもゾーンが「イントラネットサイト」に無い限りログイン情報を飛ばさないので、これを起動前に明示的に他「例:信頼済みサイト」に変更してあげて、終了後必要に応じて戻す
Option Explicit
Dim WSHShell
Set WSHShell = CreateObject("WScript.Shell")
WSHShell.RegWrite "HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionInternet SettingsZoneMapDomainsexample.comstshttps", 2, "REG_DWORD"

これで、一応ID/PASSの入力画面がポップアップしてきて、指定のアカウントでログインができるようになります。

う~ん、でもあまり美しくない。上手いやり方は無いものだろうか…

Chrome on Win7のSSOをAD FS側の設定で実現する

FirefoxでのOffice365へのシングルサインオンの記事では、各クライアントサイドのセキュリティ設定の緩和によって、シングルサインオンの機能を実現しました。ただ、この手法は全クライアントにレジストリの変更を強いることになるので、あまりスマートな実装ではございません。

今回、サーバサイドの設定変更でシングルサインオンが出来ないか試してみたいと思います。

Continue reading

FirefoxでのOffice365へのシングルサインオン

 Office365の リリースノート にも記載がありますが、Windows7もしくは「認証に対する保護の強化」をインストールしたXP,Vistaにおいて、FirefoxやChromeでAD FS環境でのシングルサインオンを実施しようとするには少し設定変更が必要になります。(7/2追記修正)

試しにアクセスをしようとしてみると、

Continue reading

Office365 beta版との相違1

Office 365が商用リリースされましたね。6/29現在、日本語版の提供はまだですが、英語版の方はサービス詳細が提示されました。

Office 365 for Enterprise Service Descriptions

とりあえず軽く流し見した中で、サービス仕様の変更が有ったところを簡単に表記しますと、

Continue reading

MEDIAS WP N-06Cをリモートワイプする

今日発売のAndroid2.3搭載の防水スマートフォン、N-06Cを入手したので、早速Office365で利用出来るように設定して、リモートワイプしてみました(w

まずは、メールアドレスとパスワードを入れます。アカウントタイプは「Exchange」を選択します。
 

Continue reading

ADFS環境下のOffice365のDRについて

3/11の震災をきっかけにして、DR対策の一環としてOffice365を検討されている方も多いかと思います。確かにOffice365自体はアジア圏の2地域(シンガポールと香港)にサーバが有り、地域的には十分な冗長性が確保されているのではと思います。

ただ、アクセス制御などの目的でAD FSを入れる構成とした場合、Office365へのインターネットアクセスの他に、いくつか接続性を確保する必要が出てくるポイントがあります。

Continue reading

AD FS(AD FS Proxy)で利用するSSL証明書

AD FS Proxyの役割 でも書きましたが、現時点でOffice365を利用する場合、以下の条件の場合は第三者機関の発行するSSL証明書が必要になります。

  • 外部(インターネット)からOffice365を利用したい場合
  • MAPI/IMAP/POP3/ActiveSyncのメールクライアント(要はOWA以外)を利用したい場合

Continue reading

IDフェデレーション時のブラウザの設定

Microsoftでもようやく KB:2530713 で紹介されておりますが、現時点でOffice365のフェデレーション環境を利用するには、以下の通りゾーンの設定を各クライアントのブラウザに設定する必要があります。これをしない場合、ID/Passwordの入力を求めるポップアップが出たり、他のブラウザを開いているとOffice365からサインアウトできないなどの事象が発生することがあります。

Continue reading