ADFS 2.0 RU1で実装されたアクセス制御

Office365の正式リリースから3ヶ月強、10/12になってようやくADFS 2.0のRU1がリリースされました。いくつかOffice365向けの大きな機能追加がなされておりますが、今回はアクセス制御の機能強化について解説します。

これは、簡単に言うとリッチクライアント(Outlook2010等)でExchange Onlineにアクセスした際、今までは全てExchange OnlineのIP帯からのアクセスとしてADFS Proxyから見えていた物が、更にそのアクセス元のIPやプロトコルなどをHTTPヘッダとして付与して送信してくれるようになった為に付与できるようになった機能です。(平たく言うと敢えて漏れ串になったということ)

今回のRUをインストールし、設定することにより、以下の5つの属性が追加でクレームルールとして利用出来るようになり、主要なケースを元にしたアクセス制御が可能となります。

  • X-MS-Forwarded-Client-IP Exchange Onlineに接続されたIP
  • X-MS-Client-Application Exchange Onlineに接続したプロトコル
  • X-MS-Client-User-Agent Exchange Onlineに接続したクライアント
  • X-MS-Proxy Proxyサーバ経由でのアクセスか否か
  • X-MS-Endpoint-Absolute-Path ActiveフェデレーションかPassiveか

サンプルに載っている物を含め、いくつか動作検証を行った物を紹介します。ちなみに、通常のクレームルールに載っておりますが、簡単にクレーム発行ルールに基づき

  type=deny有り type=deny無し
issue type=permit有り アクセス拒否 アクセス許可
issue type=permit無し アクセス拒否 アクセス拒否

の様な制御マトリックスになります。それでは、いくつかのケースに基づきクレームルールを記載してみます。

①社外からOffice365へのアクセスをすべて拒否する
1.すべてのユーザにアクセスを許可

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

2.会社のFirewallのIP(123.123.123.123)からのアクセスを除き、ADFS Proxy経由のアクセスを拒否する

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value=~ "123.123.123.123"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

②Exchange ActiveSyncを除き、社外からOffice365へのアクセスをすべて拒否する

 1.すべてのユーザにアクセスを許可

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

2.ActiveSyncプロトコルまたは会社のFirewallのIP(123.123.123.123)からのアクセスの場合を除き、ADFS Proxy経由のアクセスを拒否する

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "123.123.123.123"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

③Exchange ActiveSyncならびにブラウザベースのAPを除き、社外からOffice365へのアクセスをすべて拒否する
1.すべてのユーザにアクセスを許可

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

2.ActiveSyncプロトコルまたはブラウザアクセス、もしくは会社のFirewallのIP(123.123.123.123)からのアクセスの場合を除き、ADFS Proxy経由のアクセスを拒否する

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-client-application", Value == "Microsoft.Exchange.ActiveSync"])
 && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "123.123.123.123"])
&& NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value == "/adfs/ls/"])
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");

明示されたADグループを除き、社外からOffice365へのアクセスをすべて拒否する

1.すべてのユーザにアクセスを許可

=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");

2.明示されたADグループ(S-1-1-12-1234567890-123456789-123456789-1234)のメンバーもしくは会社のFirewallのIP(123.123.123.123)からのアクセスの場合を除き、ADFS Proxy経由のアクセスを拒否する

exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-proxy"])
&& NOT exists([Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "S-1-1-12-1234567890-123456789-123456789-1234"])
 && NOT exists([Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-forwarded-client-ip", Value =~ "123.123.123.123"])=> issue(Type = "http://schemas.microsoft.com/authorization/claims/deny", Value = "true");
広告

ExchangeからOffice365移行の際の注意点

オンプレミスのExchange Serverを利用されていて、BCPなどからOffice365への導入を検討される方も多いかと思います。現時点でドキュメント等に載っていない移行を検討する上での留意点がありますので、紹介させて頂きます。

Exchangeをインストールすると、オンプレミスのActive Directoryのスキーマが拡張され、各ユーザのADオブジェクトにExchange関連の属性が設定されます。この中に、アカウントに紐付くメールボックスを指定するmsExchMailboxGuidという属性が有ります。(多分Exchange 2000から利用されていたと思います)

この属性に値が設定されているままでOffice365にディレクトリ同期を実施した場合、『移行ツール以外からメールボックスを有効にできなくなります

試しにダミーの値を入れて検証してみます。adfs serviceというメールボックスの無いアカウントにmsExchMailboxGuidを設定します。

ディレクトリ同期された後、メールボックスを有効化する為にExchange Onlineのサブスクリプションを付与しようとすると、以下のメッセージが表示されます。

この移行バッチ以外からメールボックスが有効化できないということは、以下のような影響があります。

  • メールボックスを「移行しないでMX切り替えのみ」という移行方法の選択肢が取れない
  • オンプレがExchange2000の場合は、移行ツールを動かす為に2003以上にUpgradeが必要
  • Exchange移行ではなくIMAP移行はできない(IMAPは移行ツール実行前にメールボックスを作る必要がある)

では、対策を少しだけ考えてみます。まずは、

①既にオンプレのExchangeを利用していない場合

A.これは単純です。当該属性(msExchMailboxGuid)をオンプレのAD上で削除してしまい、再度同期をすればOKです。

②オンプレのExchangeを移行前にはオフラインにできない場合

B.一番綺麗な方法は、移行(メールボックスを有効にしたいタイミング)時にディレクトリ同期専用のAD DSを一時的に立てて、そこで当該属性の情報をクリーニングしてから同期させることです。msExchMailboxGuidが邪魔なのは、あくまでメールボックスを有効にするタイミングのみです。メールボックスが作成された後は、同期されるオンプレの当該属性に何か値が入っていても特に問題なく動作します。

C.移行が長期に渡る場合や、余分なAD DSを立てられない様な場合ですが、ディレクトリ同期サーバのMAの設定を書き換えて対応する必要があります。

ということで、案Cを実現させる為の設定をなるべく単純な方法で書いてみたいと思います。

①まず、ディレクトリ同期サーバに入って、C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\UIShell\miisclient.exe を起動します。
②続いて、[Management Agents]-[TargetWebService]を選択し、[Properties]を開きます。
③[Configure Attribute Flow]を選択して、(Data Source Attribute)msExchMailboxGuid←(Metaverse Attribute)msExchMailboxGuidのExport(Direct,Allow Nulls)となっているルールを探します
④これをおもむろにDeleteします。

これで、Metaverseに格納されたmsExchMailboxGuidの属性をOffice365に同期するというデータフローが無くなります。ディレクトリ同期開始前であれば、これが終わってから同期を開始すれば大丈夫です。

ただ、一度でもディレクトリ同期をしてしまった後(msExchMailboxGuidが一度Office365側に同期されている)については、Metaverseのデータ自体が変更になっているわけでは無いので、再度フル同期をかけても当該属性のUpdate処理は走りません。

このため、Office365のディレクトリ同期で特定アカウントを非同期にするで紹介したやり方を使って、一度対象のアカウントのSource AD側をExplicit Disconnectorに設定し、同期することにより一時的にOffice365からアカウントを削除します。そして、それを再び解除(手動でProvisioningするか、通常のDisconectorにしてから再同期)してから同期を行い、Office365にアカウントを作成し直すことにより、msExchMailboxGuidがNullの状態で同期されるようになります。

というわけで、凄く面倒なので早くOffice365側の仕様を変更して欲しいですね…