Windows Server 2012 R2によるADFS構築

MVPの国井さんから無言のプレッシャーを頂いたので、以前の投稿「Windows Server 2012によるADFS構築」のWindows Server 2012 R2をきちんと紹介したいと思います。

Workplace Joinをはじめ、Windows Server 2012 R2のADFSではいくつかの新機能が実装されていますが、インストールの手順としては大きく変更は有りませんが、大まかに言うと下の4点です。

  1. SSL証明書は事前にインポートしなくても良くなりました
  2. ADFSのサービスアカウントは事前に作成しなくても良くなりました
  3. サービスアカウント作成に必要なKDSルートキーの作成が前提条件になります
  4. ADFSの画面で表示される「フェデレーションサービスの表示名」を設定できるようになりました

環境としては前回と同じく以下の通りです。
20130928_01

事前準備として、KDSルートキーを作成します。(即時で利用可能なよう、DCが複製を待つためウェイト時間の10時間を引いた10時間前の時刻を指定して作成します。)

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

※事前に作成しなかった場合、サービス構成ウィザード中で以下のエラーが出ます。
20130928_02

最初に、ADFSサービスの役割をインストールします。後で必要になるので、機能の追加で.NET Framework 3.5 Featuresも選択しておくと良いでしょう。
20130923-014705 20130923-014711 20130923-014714 20130923-014722 20130923-014734 20130923-014741 20130923-014745 20130923-014750 20130923-015114

続いて、Active Directoryフェデレーションサービス構成ウィザードを実行します。Domain Adminsの権限を持つアカウントを指定して、SSL証明書の指定、サービス名の指定ならびにサービスアカウントの指定(新規作成も可能)をウィザード中で実施します。
20130923-015613 20130923-015808 20130923-015813 20130923-015901 20130923-020254 20130923-020300 20130923-020309 20130923-020328 20130923-020355 20130923-020632

これが完了すると、AD側にADFSのサービスアカウントが作成されます。(SamAccountNameには上記で入力した物の末尾に$が付くようです)
20130930_01

前回はここで先にADFSを設定しましたが、一度サインインアシスタントをアンインストールするという手順が入り少し面倒なので、今回は先にディレクトリ同期のセットアップを終わらせてしまいたいと思います。

ディレクトリ同期ツールのインストールは、基本的に何のパラメータも無く実行できます。終了後にそのまま構成ウィザードの実行に移ります。
20130923-022139 20130923-022147 20130923-022151 20130923-023830 20130923-023834

構成ウィザードでは、Office365の全体管理者アカウントとActive DirectoryフォレストのEnterprise Adminsのアカウントの情報を入力します。ADFS用なのでパスワード同期はオフにしておくことにします。
20130923-023843 20130923-023902 20130923-023939 20130923-023944 20130923-024011 20130923-024047 20130923-024051 20130923-024056

最後に、Windows PowerShell用Windows Azure Active Directoryモジュールをセットアップします。
20130923-024111 20130923-024118 20130923-024122 20130923-024126 20130923-024133

インストールしたPowerShellモジュールを開き、Connect-MsolServiceでOffice365に接続した後にConvert-MsolDomainToFederatedでADFSを有効化します。
20130331_46

これでWindows Server 2012 R2によるADFS環境の構築が完了しました。ログアウト時に一瞬ADFSサービス名の入ったログアウト画面が表示されるなどの細かい点以外は特に今までと変わらずシングルサインオンすることが可能です。
20130924-000503 20130924-000443 20130924-000451 20130924-000459

広告

ADFS環境でOWAからログアウトできない

新しいOffice365になって、ADFSまわりで微妙に挙動が変わった部分があるのでそちらを紹介させて頂きます。

内容は、OWAのバニティURLからログインした場合にOWAからログアウトできないという物です。具体的にどういうことかというと、ADFSの場合は、通常

【ログイン】
20130924-000503 20130924-000443 20130924-000451

【ログアウト】
20130924-000455 20130924-000459 20130924-000503

こんな感じで画面が推移してそれぞれシングルサインオン、サインアウトして最初のサインインの画面に戻るというフローになります。(ちなみにサインアウト画面が出るのはWindows Server 2012 R2のADFSの場合のみです) 各アプリケーションのサインアウト画面からは、アプリケーション毎に少し違っていて、SharePoint Onlineからの場合はサインアウト後専用の画面で止まります。

OWA
20130924-002356 20130924-000459 20130924-000503

SharePoint Online
20130924-002018 20130924-000459 20130924-002027

ただし、新しいOffice365へのアップグレード後、「OWAに直接バニティURLを利用して入った場合、OWAからサインアウトできない」という事象が発生しました。このバニティURLというのは、例えば https://outlook.com/owa/contoso.com のようなURLで、ポータルのサインイン画面でのID入力を飛ばしてOWAに入れるURLです。これを利用していた環境でサインアウトをしようとすると、

20130924-000700 20130924-000459

一旦はサインアウトされるのですが、なぜか再度数回リダイレクトを繰り返した後に元の画面に戻ってきてしまいます。
20130924-000710 20130924-000712

以前一度だけあった事象は、「SharePoint Onlineで*.sharepoint.comを信頼済みサイトに入れていない場合にリダイレクト処理の関係でサインアウトが上手くいかない」というのは有りましたが、今回はちゃんと設定してあります。う~ん、謎な挙動です。

とりあえずFiddlerでポータルから入った場合とバニティURLから入った場合の挙動をトレースしてみます。
20130924-003935

一箇所怪しいところを見つけました。

ポータルから:    https://sts.w15jp.info/adfs/ls/?nossl=1&wreply=https://login.microsoftonline.com/login.srf%3Flc%3D1041%26ct%3D1379942681%26rver%3D6.1.6206.0%26id%3D260563%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Foutlook.com:443%252Fowa%252F%253Fexch%253D1&wa=wsignout1.0
バニティURLから: https://sts.w15jp.info/adfs/ls/?nossl=1&wreply=https://login.microsoftonline.com/login.srf%3Flc%3D1041%26ct%3D1379924091%26rver%3D6.1.6206.0%26id%3D260563%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Fpod51054.outlook.com:443%252Fowa%252F%253Fexch%253D1&wa=wsignout1.0

ポータルから入った場合はサインアウトした後に戻るURLの更にリダイレクト先がoutlook.comになっているのに対して、バニティURLから入った場合はそのメールボックスが収容されているpod51054.outlook.comになっています。

この差が最終的にリダイレクトされた後にポータルに飛ぶか、再度SSOの画面に飛ぶかの判定に繋がっているようです。(ちなみにバージョンアップ前のOffice365の場合はsixprd0210.outlook.comなどの実際にMBXサーバがあるところのFQDNでした。この場合もサインアウト後の戻り先はポータル) 最初は無理矢理web.configに

<RewriterConfig>
   <Rules>
      <RewriterRule>
         <LookFor>~/adfs/ls/?nossl=1&wreply=https://login.microsoftonline.com/login.srf%3Flc%3D(\d{4})%26ct%3D(\d{10})%26rver%3D6.1.(\d{4}).(\d)%26id%3D(\d{6})%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Fpod51054.outlook.com:443%252Fowa%252F%253Fexch%253D1&wa=wsignout1.0</LookFor>
         <SendTo>~/adfs/ls/?nossl=1&wreply=https://login.microsoftonline.com/login.srf%3Flc%3D(\d{4})%26ct%3D(\d{10})%26rver%3D6.1.(\d{4}).(\d)%26id%3D(\d{6})%26wa%3Dwsignoutcleanup1.0%26nossl%3D1%26wreply%3Dhttps:%252F%252Foutlook.com:443%252Fowa%252F%253Fexch%253D1&wa=wsignout1.0</SendTo>
      </RewriterRule>
   </Rules>
</RewriterConfig>

とかのrewriteルールを無理矢理書いて対応しようかと考えたのですが、そもそもWindows Server 2012 R2からはADFSがIISを利用していないのでweb.configが利用できません。

SRで上げても再度ログインしてしまうのは新バージョンからの仕様と言われてしまったので手詰まりかと思ったのですが、ある時ふとOutlookのプロファイルを見たところ、バニティURLが https://outlook.office365.com/owa/contoso.com に変わっていることに気がつきました。(今まではpod510xx.outlook.com/owa/contoso.com)

というわけで、この新しいバニティURLからサインインして、サインアウトを試してみると…おぉ、できました! よく見ると、サインイン後のOWAのURLもpod51054.outlook.comではなくoutlook.office365.comになっています。

20130924-010348 20130924-010428

20130924-010433 20130924-000459 20130924-000503

という訳で、アップグレードに伴って古いバニティURLを利用されている方でサインアウトの問題がでている方は、 https://outlook.office365.com/owa/contoso.com に変更してみて解消するかどうかお試し頂く事をお勧めさせて頂きます。

アップグレード無事完了!

本日予定されていたアップグレードはトラブルも無く無事完了しました!

20130917_01

さて、これで色々また実環境で試せます。

そういえば、気づかなかったのですがプランPでのSharePointがhttpsに変更されましたかね?今まではhttpだったので、ファイル等を転送するのもちょっと躊躇われるところが有ったのですが、これで安心ですね♪

ようやくサービスアップグレード

以前、一回予定されたアップグレードがキャンセルされてから何の音沙汰も無かった私の個人用のSmall Businessのテナントですが、ようやく明日にアップグレードされるようです。

20130917

プランPでトランスポートルールもFOPEルールも無いシンプルなテナントなので失敗することは無い…かな?

Office365勉強会#6に登壇しました

既に先月の話になってしまいましたが、目代さんの主催されているOffice365勉強会の第6回目に登壇させて頂きました。

当日利用したスライドは こちら で公開をさせて頂いておりますが、Office365が出てからの2年間で出てきた新機能や仕様変更の内容をベースに従来から言われていた「ADの有無」「企業の規模」ではない切り口から①クラウドID ②クラウドID+ディレクトリ同期 ③フェデレーションID+ディレクトリ同期の使い分けについて発表させて頂きました。

無題

私としては、クラウド側が随時進化していっているので利用者側のこういったノウハウも随時変化していくものだと考えております。また機会があれば紹介をさせて頂きたいと思います。