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

Windows Server 2012 R2がリリースされて1年が経ちました。Windows Server 2008 R2などでAD FS環境を作られている方も多いかと思いますが、今日は、Windows Server 2012 R2のAD FS環境に乗り換えるメリットや注意点などを簡単にまとめてみたいと思います。

1. 最新のソフトウェアバージョンであるから
   • Office 365を利用する上で、それと連携する環境はたとえServer OSであっても随時バージョンアップし、新しい物に追従していく必要があります
   • Windows Server 2008 R2のAD FSは、現在はサポート範囲には入ってますが、既に新機能は提供されておらず、次期Server OSが公開されるといずれサポート外になってしまいます
2. デバイス認証(DRS)が利用できるから
   • 利用できるクライアント環境には制限があるものの、新機能であるWorkplace Joinを利用すると、Active Directoryに所属していないデバイスを登録し、デバイス認証によるログインを実施することができるようになります
   • デバイス認証の要否もAD FSのクレームルールとして記載できますので、より柔軟なアクセス制御が実施出来るようになります
3. 多要素認証が利用できるから
   • AD FS自体がアドインの多要素認証を意識した設計になりました
   • 従来は、AD FSの処理の外（PhoneFactorであれば、AD FS ProxyのIISのフォーム認証の部分）で追加認証を実施してましたが、AD FSの処理の内部で利用することにより、ある条件下のみでの多要素認証の要求など、柔軟な処理が実施できるようになります
4. AD FSサービス用のユーザーアカウントが不要だから
   • グループの管理されたサービスアカウント（gMSA）というサービス実行専用の特殊アカウントが利用できるようになりました。これにより、AD FSサービスの実行用に特別な管理者アカウントの管理は不要です
   • 管理権限を保有し、実効上パスワードの無期限化が必要、かつAD FS Proxy経由の無差別攻撃などでロックアウトし、AD FSがサービス停止する危険性など、従来の運用上のリスクから開放されます
5. パッシブフェデレーションでも接続情報を取得できるから
   • 従来、ブラウザからのアクセス（パッシブフェデレーション）ではアクセス元のIPやクライアント種別などの情報が取得できませんでしたが、これが取得できるようになったことで、より外部アクセスに関しての細かなアクセス制御が実施できるようになりました
6. 外部アクセスへのアカウントロックアウトの対応ができるから
   • Exchange OnlineのアクセスにAD FSを利用している場合、外部から攻撃を受けたり、パスワード変更後に設定未変更のスマートフォンなどの端末からのアクセスでオンプレミスのActive Directoryアカウントがロックアウトすることがありました
   • AD FS Proxy経由でのアクセスについてAD FSの処理でロックアウトを実施することができるようになりました。これでアタックをうけてもActive Directoryアカウントには影響を与えません
7. リバースProxy機能を持つWAPが利用できるから
   • Windows Server 2008 R2のAD FS Proxyは、AD FSへの要求をフォワードすることしかできませんでした
   • Windows Server 2012 R2はWeb Application Proxy(WAP)として新たに構成され、AD FS以外にもより汎用的に各種社内Webアプリケーションをインターネットに公開（もちろん、AD FSを利用して認証させることもできます）できるようになりました
8. サインイン画面がカスタマイズできるから
   • 標準機能としてサインイン画面に会社名やロゴを入れたり、問い合わせ先などのリンクを入れたりできるようになりました
9. 内部/外部の認証方式の方式をカスタマイズできるから
   • 従来はweb.configなどをいじって対応する必要のあった認証方式の変更がGUIから簡単に実施できるようになりました
   • 例えば、イントラからの認証をWindows認証からAD FS Proxyと同じフォーム認証に変更できます。イントラ内に複数のADフォレストが存在する環境や、PCのログインユーザーとOffice365へのログインユーザーの情報が異なる場合などに活用できそうです。
10. AlternateLoginIDが利用できるから
    • 従来、認証で利用する情報はUPNに固定されていました。このため、contoso.local をActive Directoryのドメインとして利用している場合などは各ユーザーのUPNを変更する必要がありました
    • AlternateLoginIDの設定の有効化により、ログイン要求が来てそのUPNが見つからなかった場合、指定したUPN以外の一意な項目（例えばmailなど）をキーとしてユーザーを検索し、そのユーザーへの認証要求として取り扱えるようになりました
11. カリスマトレーナーによるトレーニングがあるから
    • 新しい技術分野にも関わらず、クリエイルミネートさんの Office 365 ユーザー認証ベストプラクティス で短期間で体系的かつ実践的に知識を身につけることができます。
    • 講師は勿論、あの国井傑先生です。

良い事ばかり並べましたが、勿論新しいバージョンになったことで新たに考慮しなくてはならなくなったことや運用上の注意点なども出てきてます。この辺は後日またまとめてみたいと思います。

以前の投稿で、IE以外からADFSにシングルサインオンしようとした場合に、いくつか設定変更をしない部分があるということを紹介しました。

• FirefoxでのOffice365へのシングルサインオン
• Chrome on Win7のSSOをAD FS側の設定で実現する

Windows Server 2012 R2のADFSにおいても、デフォルトの状態だとIE以外からはシングルサインオンできません。イントラネットのポータルからIDを入力すると、ADFS Proxy経由でアクセスした際と同じフォーム認証の画面に飛んでしまいます。（以下、Chromeでの画面例）
 

今回は、IE以外のブラウザからも入れるようにする方法を紹介します。

以前は、拡張認証の対応用にIISの設定を変更しましたが、Windows Server 2012 R2のADFSではそもそもIISを利用してません。この為、対応のための設定変更はADFSで実行します。

主に設定に関係するのはSet-ADFSPropertiesの以下のパラメータです。（[ ]内はデフォルト値）

• ExtendedProtectionTokenCheck [Allow]
• WIASupportedUserAgents [MSAuthHost/1.0/In-Domain,MSIE 6.0,MSIE 7.0,MSIE 8.0,MSIE 9.0,MSIE 10.0,Trident/7.0,MSIPC,Windows Rights Management Client]

ExtendedProtectionTokenCheckは、拡張認証に対応している場合は利用を許可すると言う物ですが、昔調べた際はIE以外は対応しているブラウザが無かった為にWindows7では対応をしなくてはいけなかった物ですが、今回調べた限りではサードパーティのブラウザ側でも対応が進んでいるのか、特に設定変更の必要はありませんでした。

次に、WIASupportedUserAgentsのパラメータです。Windows Server 2012 R2のADFSは、このパラメータを見てシングルサインオンさせるかフォームベース認証にするかを判断しています。これを、ChromeやFirefox用にMozilla/5.0を設定してみます。ご利用の環境に合わせて “Safari/6.0”, “Safari/7.0” なども追加して頂ければ、と思います。

$old=(Get-AdfsProperties).WIASupportedUserAgents
$new=$old+"Mozilla/5.0"
Set-ADFSProperties -WIASupportedUserAgents $new

Chromeは、IEの設定をそのまま見て動作してくれますので、特に何も無くシングルサインオンできるようになりました。
 

ただし、Firefoxの場合は以下の様にID、PASSの入力画面がポップアップします。

これは、以前の投稿でも紹介した通りADFSのFQDNをIEでの「イントラネット」に設定しないといけないのと同じ理屈でセキュリティ上の問題からです。

about:configで設定画面に入った後、network.automatic-ntlm-auth.trusted-urisの項目にADFSのFQDNを設定すれば以下の様にシングルサインオンできるようになります。

注意点としては、ブラウザのバージョンアップによりUserAgentの値が変わった場合はシングルサインオンができなくなりますので、こちらの管理を運用の中でしていく必要があります。

Office 365でADFSを利用するとActive Directoryのグループをベースとしたアクセス制御を実装することができます。

Microsoftのサイトなどに設定例などがいくつか記載されておりますが、今回、主に大規模な組織でこのルールを運用する場合、こちらのサンプルをそのまま利用すると一部書式の問題でセキュリティリスクに繋がると考えられる物があるためこちらで共有します。

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

書式のサンプルは以下の通りです。グループ名ではなくSIDを利用するというのはActive Directoryなどでの管理と同じで、グループの名称を変更しても不変な値をベースとして制御しています。

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "Group SID value of allowed AD group"])

例えば、以下のSG1というセキュリティグループでアクセス拒否の制御をする場合は、

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-5-21-589771422-1504810464-123969929-1223"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

などとします。

ところが、ここで1点問題と考えられるのが、上記赤字で書いた部分の書式です。==は「等しい」ですが、=~は「含む」です。また、SIDはGUIDなどとは違い可変長で、末尾の数字はグループが作成される度にインクリメントされてどんどん数字が増えていきます。

つまり、グループの数がどんどん増えて行った場合、いずれはSIDが一桁上がって制御すべきグループのSIDを「含む」グループが作成される可能性があるということです。

これにより、特定グループのメンバーを拒否しようとしたら別のグループのメンバーが意図せず拒否されてしまったり、特定グループのみアクセス許可していたサービスが意図せず許可されてしまうということが起こる可能性があります。

もっとも、ユーザーが作成するグループのSIDは基本的に4桁（1100番台？）から作成されるので、これが問題になるのは5桁のSIDが作成されるような10000以上のグループがある大きな組織になりますが。

exists([Type == ”http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-589771422-1504810464-123969929-1223"])
 => issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

とすることにより、意図した挙動とすることができます。

この記事は、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完了のイベントログを特定します。

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

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

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

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

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

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

本投稿は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アドレスであるグローバル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使って簡単にインストールできます。

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

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

非常に地味ですが、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に渡して処理するということも可能です。

この構成において、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の瀬尾さんです。

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

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

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

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

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

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

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

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

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の画面で表示される「フェデレーションサービスの表示名」を設定できるようになりました

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

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

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

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

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

続いて、Active Directoryフェデレーションサービス構成ウィザードを実行します。Domain Adminsの権限を持つアカウントを指定して、SSL証明書の指定、サービス名の指定ならびにサービスアカウントの指定（新規作成も可能）をウィザード中で実施します。

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

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

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

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

最後に、Windows PowerShell用Windows Azure Active Directoryモジュールをセットアップします。

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

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

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

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

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

Office 365 Directory Sync Quota Automated Increase to 300,000 Users にて、ディレクトリ同期のオブジェクト上限の引き上げについての発表がありましたので紹介します。

この値は、ディレクトリ同期ツールを導入する際に、Office365に同期できるオブジェクトの制限値（※注）になります。

ユーザー・グループ・連絡先の合計の上限が当初2万だった物が、全テナント5万に引き上げられましたが、今回これが【最初は5万オブジェクトだが、初回の独自ドメイン追加時に30万に変更される】という仕様に変更になりました。

注）過去の記事で調べた限りでは、同期するオブジェクトの上限では無くOffice365側で作成したオブジェクトの数も含む値でした

大学などで利用する場合や、中堅～大企業な環境で利用する場合もこれでほとんどの場合問題ないようになりそうですね。なお、既存のテナントの場合は5万オブジェクトのままであり、また、独自ドメインを利用しない場合などは従来通りSRを上げての対応となるようです。

ちなみに、このSRを上げるには結構面倒な申請が必要です。本当にそれだけのオブジェクト数を必要としているのかを書類に記入して、場合によってはADでのコマンドの実行結果などをエビデンスに添付して申請します。