Windows Server 2012 R2を使ってiOSだけがOffice365にアクセスできるようにする(3)

前回までのところで次の設定を行いました。

・Workplace Joinのための設定
・iPhoneをデバイス登録する設定
・Office365のシングルサインオンの設定

今回はこのシリーズの最後として、登録されたデバイスだけがOffice365にアクセスできるようにしたいと思います。

概説 クレームの確認

ADFSを利用して認証を行った場合、クレームと呼ばれるサインインしたユーザーやデバイスの属性情報が入ります。今までのADFSでは、サインインしたユーザーの情報だけがクレームとして登録されていたのですが、Windows Server 2012 R2のDRSを利用することで、デバイスの属性情報もクレームとして登録されるようになりました。

ちなみに、クレームとして利用可能な属性一覧はADFS管理ツールの[要求記述]から確認できます。

[要求記述]を見ると、デバイスのOSの種類を表す「deviceostype」やDRSで登録されたデバイスにだけ割り当てられる「deviceid」などがあります。これらを利用すれば、次のようなシナリオが可能になります。

・DRSで登録されたデバイスだけにOffice365のアクセスを許可
・iOSだけにOffice365のアクセスを許可
・特定の電話番号だけにOffice365のアクセスを許可

Step10 ADFSクレームルールの設定

ADFSでクレームに記述されている内容に基づいて、アクセス制御を行う場合、証明書利用者信頼にある[発行承認規則]を使います。Office365のシングルサインオンの設定が完了していると、自動的にOffice365の証明書利用者信頼が作られているので、ADFS管理ツールの[証明書利用者信頼]から[Microsoft Offce365 Identity Platform]を右クリックし、[要求規則の編集]をクリックします。

要求規則の編集画面から[発行承認規則]タブを開き、[すべてのユーザーにアクセスを許可]を削除します。

削除できたら、今度は[規則の追加]をクリックして、規則を追加します。
追加するときは[カスタム規則を使用して要求を送信]を選択します。

発行承認規則でカスタム規則を選択した場合、アクセス許可の設定にクレームルール言語と呼ばれる言語を使って記述しなければなりません。クレームルール言語はウィザードの中で直接記述します。

問題は、どのようなクレームルールを書けばよいか？ですよね。
クレームルールそのものの解説は機会を改めることにして、ここでは目的とするクレームルール言語を紹介したいと思います。

シナリオ1 DRSで登録されたデバイスだけにOffice365のアクセスを許可する場合

登録されたデバイスだけがOffice365へアクセスできるようになれば、不正アクセスの機会はぐっと減りますよね。クレームルールには次のように記述します。

exists([Type == ”http://schemas.microsoft.com/2012/01/devicecontext/claims/identifier”])
=> issue (Type = “http://schemas.microsoft.com/authorization/claims/permit”,value = “true”);

シナリオ2 iOSだけにOffice365のアクセスを許可する場合

シナリオ1から、さらに絞り込んで、今度はiOSデバイスだけがOffice365にアクセスできるようにしてしまいましょう。クレームルールには次のように記述します。

exists([Type == ”http://schemas.microsoft.com/2012/01/devicecontext/claims/ostype”, Value == “iOS”])
=> issue (Type = “http://schemas.microsoft.com/authorization/claims/permit”,value = “true”);

ちなみに、iOSのバージョンまで限定したい場合には

exists([Type == ”http://schemas.microsoft.com/2012/01/devicecontext/claims/osversion”, Value == “10B350”])
=> issue (Type = “http://schemas.microsoft.com/authorization/claims/permit”,value = “true”);

と設定すれば、iOS 6.1.4に限定できます。
(10B350とは、iOSのBuild番号であり、登録したデバイスのmsDS-DeviceOSVersion属性で確認できます)

シナリオ3 特定の電話番号だけにOffice365のアクセスを許可する場合

Exchange ActiveSyncのデバイスポリシー機能をトレーニングで扱うと、必ずご質問をいただいていたのが「電話番号をベースにして、アクセス可能なスマートフォンを限定できませんか？」

Exchange ActiveSyncでは不可能だったアクセス制御も、Workplace Join + ADFSの組み合わせなら夢がかないます。
この場合、Active Directoryユーザーとコンピューターで登録されたデバイスの属性に電話番号を追加してからADFSでクレームルールを記述します。私はdisplaynameという属性に電話番号を入れてみました。

そして、クレームルールには次のように記述します。
(09011112222の部分には実際の電話番号が入ります)

exists([Type == ”http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname”, Value == “09011112222”])
=> issue (Type = “http://schemas.microsoft.com/authorization/claims/permit”,value = “true”);

会社で携帯電話をまとめて購入し、電話番号が連番(例:090-1111-xxxx)でしたら、
正規表現を使って下4桁を任意の数字になるように構成するような方法が使えます。

exists([Type == ”http://schemas.microsoft.com/2012/01/devicecontext/claims/displayname”, Value =~ “^0901111[0-9]{4}$”])
=> issue (Type = “http://schemas.microsoft.com/authorization/claims/permit”,value = “true”);

では、最後にシナリオ1のクレームルールを実装し、
DRSで登録されていないiPhoneからOffice365にアクセスしてみましょう。
iPhoneのブラウザーからユーザー名を入力すると、画面がリダイレクトされ、、
アクセスが拒否されます。

一方、DRSで登録されているiPhoneからOffice365にアクセスする、前回の投稿の時と同じように
アクセスが可能です。

まとめ

Windows Server 2012 R2で提供するWorkplace Joinの中核の機能である、DRSはドメイン参加とも異なる、第3のデバイス管理形態を提供してくれます。これによって、色々なメリットがありますが、今回のシリーズではOffice365のシングルサインオンをカスタマイズするという形での活用方法を紹介しました。

今回の実装では、証明書の実装方法やクレームルールのつくり方など、一部テスト環境向きな設定などありましたが、本番運用に耐えられる環境づくりを実践してみたい方はADFSトレーニングを用意していますので、ご興味のある方はぜひご参加いただければと思います。