ディレクトリ同期の運用自動化

この記事は、Office 365 Advent Calendarに参加しています。

AD FSやディレクトリ同期を利用すると、オンプレミスのADとOffice365の間でシームレスな運用が可能になります。ただ、

  • 同期間隔が3時間
  • 同期後のサブスクリプションの割り当てが管理者が実行しなくてはならない

など、いくつか運用として管理者が対処を行わなければならない部分が存在します。

今回はディレクトリ同期で新規で作成されたユーザーに対してOffice365のプロビジョニング(サブスクリプションの割り当て)を自動で実施できるようにしたいと思います。特に社内でIdMなどを利用している場合などについては有用だと思います。

同期ユーザーの中でどのユーザーにライセンスを割り当てるかの判定は、各組織によって色々と実装方式は有ると思いますが、今回WAAD Premium のグループ管理機能と同じようにグループで判断したいと思います。

まずは、以下の内容のps1スクリプトファイルを作成して適当なフォルダに配置します。管理者のID、PassやSKU(Get-MsolAccountSkuコマンドで取得可能)、グループ名などは実際の環境に合わせて修正してください。今回はc:workscriptsautodirsync.ps1として保存します。

######################################################################
#
#    Office 365 Auto Provisioning Script for DirSync (autodirsync.ps1)
#       2013/12/11     https://blog.o365mvp.com/
#
######################################################################
$adminuser = "admin@contoso.onmicrosoft.com"     # TenantAdmin UserName
$adminpass = "P@ssw0rd"                          # TenantAdmin Passrord
$group = "Office365e3"                           # Target Group
$sku = "contoso:ENTERPRISEPACK"                  # Office365 SKU ID (cf.Get-MsolAccountSku)
$skuname = "E3"                                  # Office365 SKU name
$log = "c:workscriptsautodirsync.log"         # Log Filename

(Get-Date -Format "yyyy/MM/dd HH:mm:ss") + " Office 365 Auto Provisioning Script Start" | Out-File $log -Append

sleep 60                  # Wait for reflect DirSync information

Import-Module MSOnline
$password = ConvertTo-SecureString $adminpass -AsPlainText -Force
$LiveCred = New-Object System.Management.Automation.PSCredential $adminuser,$password
Connect-MsolService -Credential $LiveCred

$member = Get-MsolGroupMember -GroupObjectId (Get-MsolGroup -SearchString $group).ObjectId -All
$unlicensed = Get-MsolUser -UnlicensedUsersOnly
foreach ( $user in $unlicensed ){
    $result = $member | ? {$_.ObjectID -eq $user.ObjectID}
    if ($result) {
        (Get-Date -Format "yyyy/MM/dd HH:mm:ss") + " Add $skuname License to " + $user.UserPrincipalName | Out-File $log -Append
        Set-MsolUser -UserPrincipalName $user.UserPrincipalName -UsageLocation JP
        Set-MsolUserLicense -UserPrincipalName $user.UserPrincipalName -AddLicenses $sku
    }
}
(Get-Date -Format "yyyy/MM/dd HH:mm:ss") + " Office 365 Auto Provisioning Script Finished" | Out-File $log -Append

このスクリプトをディレクトリ同期が終了したタイミングで実行すれば良いので、今回はタスクのトリガーで実行したいと思います。バージョンにより異なりますが、サーバのイベントログを確認して、Directory Syncronizationサービスの4か114のExport完了のイベントログを特定します。
20131210_01 20131210_02

続いてはタスクスケジューラへの登録です。右の操作ペインから基本タスクの作成を選択してウィザードを起動します。
20131210_03

名前は適当に付けて、トリガーを「特定イベントのログへの記録時」にして、ソースやイベントIDは前の項目で特定したエクスポート完了時のイベントログを指定します。
20131210_04
20131210_05 20131210_06

実施するアクションはプログラムの開始にします。.ps1のスクリプトファイルをタスクから起動する場合は、プログラム/スクリプトの項目には c:windowssystem32WindowsPowerShellv1.0powershell.exe を、引数として -command [.ps1スクリプトのフルパス]を指定します。
 20131210_08 20131210_09 20131210_10

最後に、作成したタスクのプロパティを開いて、[ユーザーがログオンしているかどうかにかかわらず実行する]を選択して実行アカウントのパスワードを保存します。
20131210_11

これにより、デイレクトリ同期完了後、指定のグループ(上記ではOffice365e3)のメンバーでライセンスの割り当てられていないユーザーが存在した場合には自動的にライセンスが割り当てられるようになります。
20131210_12

実際の運用の中では、環境に応じてsleepの値を調整したりUsageLocationにJP以外が有ったり複数のサブスクリプションがある場合はその処理部分などを修正すれば良いかと思います。ライセンスの残数を見て閾値を下回ったら自動的にメールを飛ばすなども入れておくと楽になりますね。

ブラウザアクセス時のADFSによるIPアドレス制御

本投稿はOffice 365 Advent Calendarに参加しています。
「Office 365チームサイト活用ガイド 2013年版」が絶賛発売中のOffice 365 MVPの中村さんからバトンを頂きました。

今回は、Office365のアクセス制御の実現方法について述べたいと思います。

AD FSを利用すると、Office365に対するアクセス制御を行うことが可能です。Microsoftのサイトでも具体的な構成例などがいくつか紹介されています。

クライアントの場所に基づいた Office 365 サービスに対するアクセスの制限

アクセス制御ができるパターンは色々とあるのですが、いくつか制約事項もあります。その中で一番大きいと思われる物が、「ブラウザからのアクセス制御時に、クライアントのIPアドレスで制御ができない」ということになります。勿論、AD FSのクレームルールではなく、IISやその前のFirewallなどで完全にブロックすることは可能ですが、例えば以下の様なIPとADの情報を合わせた条件付けが必要な設定は実装できません。

  • 本社からの内部アクセスの他、特定グループ(例えば出向者、在宅勤務者)のユーザーは特定IP(例えば出向先、自宅)からのブラウザアクセスを許可する

これは、アクセス制御に利用する送信元IPの情報が付与される場所に依存しています。
20131203_06

上図の通り、IPアドレスであるグローバルIP:Aは「X-MS-Forwarded-Client-IP」に格納されてAD FSに渡されてきますが、この情報はExchange Onlineにより付与されます。この為、クライアントからAD FS Proxyに直接アクセスをするOWAやSharePoint Onlineへのアクセスの際には付与されません。

これは仕様上仕方の無いことなので、今までは上記のような構成で外部アクセスを制御する場合は、SSL-VPNで一回社内ネットワークに接続させるなどしてAD FSサーバへの直接の接続性を確保する必要がありました。(VPNをクライアントPCで張ってからブラウザでシングルサインオンをするイメージ)

今回は、一部の皆さまの熱い要望(?)にお答えしてこの制限を回避してみたいと思います。

まず、この情報がどうやってAD FSに伝わってくるかですが、上記Microsoftのサイトに以下の記載があります

サードパーティのプロキシを使用している場合は、HTTP ヘッダーの x-ms-proxy を送信するようにプロキシを構成し、プロキシ ホストの完全修飾 DNS 名の値を含める必要があります。

この情報から推測すると、これらの情報はHTTPS通信のパケット中のHTTPヘッダに埋め込まれて送信されているのではないかと考えられます。つまり、AD FS Proxyの手前にリバースProxyなどHTTPSを終端できる物を挟んで、そこで情報を挿入してあげれば良いのでは?という推測ができます。

というわけで検証です。まずは手軽なARRでリバースProxyを立てます。詳細なやり方は他の方のblogで色々紹介されているので流れだけ。IISのインストールされたサーバ上でiis.netのサイトからWeb Platform Installer使って簡単にインストールできます。
20131203_01

適当なサイトを作成してAD FS Proxyで利用している物と同じSSL証明書をバインドします。URL書き換えからリバースProxy向けの規則を作成してAD FS Proxyに要求を転送するように設定。SSLオフロードの設定は外します。そして、リバースProxyの設定からカスタムヘッダの名称をX-MS-Forwarded-Client-IPに変更し、TCPポートを含めるのチェックを外します。
20131203_03

というわけで接続をしてみると、以下の様な情報が取得できます。(AD FSの監査ログを有効にして取得しています)
20131203_04

非常に地味ですが、x-ms-endpoint-absolute-pathが/adfs/ls/(つまり、Passiveフェデレーション)なのにx-ms-forwarded-client-ipに値が入っています!

また、ARRはIISに追加するモジュールなので例えばAD FS Proxy上にインストールして、グローバルIPからの接続をARRのサイトで受けて、それを127.0.0.1のDefault Web Site配下のAD FS Proxyに渡して処理するということも可能です。
20131203_05

この構成において、Webブラウザ以外からのアクセスはIISのサイトではなくAD FS Proxyのアプリケーションが処理しているので、ARRの処理を通りません。つまり、Exchange Onlineから付与されてきたX-MS-Forwarded-Client-IPの情報は保持されます(つまり、影響無し)。また、LyncクライアントやPowerShell、Office ProPlusなどMEXへのアクセスについてもARRでIP情報を付与できないので、これまで同様にIPベースの制御は残念ながらできない形です。

というわけで、今回はさわりの部分だけなので軽くヒント的な物になってしまいましたが、何かの参考になれば幸いです。ちなみに、もちろんこちらの記事の内容はMicrosoftによってサポートされている物ではありませんのでいつ仕様が変わって利用できなくなるか分かりません。あくまで今の時点で検証レベルではできましたよ、という話です。

次はVisual C# MVPの瀬尾さんです。

独自ドメインの利用(Dozens)

以前の投稿 にコメントを頂きました。DozensさんのDNSサービスでSRVレコードに対応したとのことで、早速利用してみましたので、ご紹介致します。

結果として言いますと、問題無くSRVレコードも含めてOffice365の独自ドメインを無償でホスティングすることができました。

まずは、Dozensにサインインして、[Add a domain]からドメインを追加します。画面の右側にDNSサーバーの情報が表示されていますので、独自ドメインのネームサーバ情報をDozensのネームサーバーに変更します。ここではお名前.comでホストしているドメインを1つ変更してみます。
スクリーンショット (3) スクリーンショット (4) スクリーンショット (5)

スクリーンショット (6) スクリーンショット (7)

続いて、Office365の管理ポータルからドメインを追加し、確認用のレコードをDozensで作成します。その後、[完了しました。今すぐ確認して下さい。]をクリックするとドメインの確認が完了します。
スクリーンショット (8) スクリーンショット (9) スクリーンショット (10) スクリーンショット (11) スクリーンショット (12) スクリーンショット (13) スクリーンショット (14)

ドメインの確認が終了したら、次にユーザーの追加の有無の選択と用途を入力します。ここでは、ユーザー追加はせずに、ExchangeとLyncを用途として選択します。
スクリーンショット (15) スクリーンショット (16) スクリーンショット (17) スクリーンショット (18) スクリーンショット (19)

表示された内容をDozensに登録します。この前に、Dozensはレコード数に応じた課金体系になりますので、ドメインの所有確認で利用したTXTレコードは今後利用する事は無く、削除しても動作には問題無いので削除しておきます。
スクリーンショット (20)

レコードの追加は先ほどTXTレコードでも実施しましたが、Webから簡単に実施できます。TTLについては1時間とOffice365で表示されますが、無償版の場合は7200秒(2時間)の固定となっておりますが、特に平常時の動作としては問題無く利用できます。

1点、SRVレコードのみ記載方法が特殊になります。Priorityの欄はWebで表示されている優先度をそのまま入力しますが、Record Nameの欄に[サービス] [プトロコル]を、Contentの欄に[重さ] [ポート] [ターゲット]の順にスペースを入れて入力します。また、FQDNの末尾の.は自動で補完してくれます。
スクリーンショット (21)  スクリーンショット (22)20131120_02 スクリーンショット (24) スクリーンショット (27) スクリーンショット (28) スクリーンショット (29) スクリーンショット (30) スクリーンショット (31)

以上の工程で、Office365で独自ドメインが利用できるようになりました。
スクリーンショット (32) スクリーンショット (33)

DCへのディレクトリ同期ツールのインストール

ディレクトリ同期ツールの新しいバージョンがリリースされました。今回の更新での一番の目玉は、「DirSync can be installed on a Domain Controller.」そう、ドメインコントローラ上にディレクトリ同期ツールを入れることがサポートされたことです。

早速インストールしてみたいと思います。Windows Server 2012 R2の環境に入れていきます。まず、最新のディレクトリ同期ツールをダウンロードします。
20131105-235445

早速実行してみると、.NET Frameworkの3.5と4が必要だと怒られてしまいます。とりあえずPowerShellでCoreだけ入れておきます。
20131105-235528 - コピー 20131106-000141

Add-WindowsFeature NET-Framework-Core,NET-Framework-45-Core

あとは普通に実行すればOK。一番最後だけ、そのまま構成ウィザードの実行に移らずにチェックを外して終了します。
20131106-000219 20131106-000227 20131106-000240 20131106-003134 20131106-003141

ここで、一度ログオフして再度ログインします。これにより、インストールウィザードにてドメイン上に作成されたFIMSyncAdminsのメンバーシップ情報が反映されます。
20131106-003157

再度ログインし、デスクトップ上にあるディレクトリ同期ツールの構成ウィザードを実行します。Office365テナントの全体管理者の情報とドメインのEnterpriseAdminsの情報を入力します。これだけで完了です。
20131106-003251 20131106-003305 20131106-003337 20131106-003344 20131106-003349 20131106-003426 20131106-003430

ちなみに、ドメインコントローラー上でインストールをすることにより、従来はローカル上に出来ていたFIMSyncAdminsやSQLServer2005xxxxを初めとするディレクトリ同期の管理者グループや、AAD_xxxxxxというディレクトリ同期などがドメイン上に作成されるようになります。これらは特にフィルタされていないので、そのままOffice365に同期される形になります。
20131106-004442

 

MVPアワード受賞しました

マイクロソフトMVP(Microsoft Most Valuable Professional)を受賞しました。
分野はOffce365で、昨年に引き続きの再受賞になります。

これも普段よりblogを読んで頂いております皆様の多大な応援のおかげと感謝しております。
これからも日々進化するOffice365の情報をタイムリーに発信していきたいと考えておりますのでよろしくお願い致します。

現在、2014年1月期のMVPアワードのエントリーが以下で行われています。
10月10日までの受付になっておりますので、興味のある方は是非どうぞ。
http://www.microsoft.com/ja-jp/communities/mvp/selfregistration.aspx

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+ディレクトリ同期の使い分けについて発表させて頂きました。

無題

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