前回までのところで次の設定を行いました。
・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トレーニングを用意していますので、ご興味のある方はぜひご参加いただければと思います。
コメント
国井様、はじめまして。
とてもためになる解説を公開して頂いて本当にありがとうございます。
私は、ADFSの勉強をしているものです。
ワークプレイス参加だけでなくドメイン参加もアクセス可能にするには、どのようなクレーム記述になるか教えて頂けませんか。identiferがワークプレイス参加の端末という意味になるのでしょうか。
ご回答をいただけると幸いです。
よろしくお願いいたします。
朝倉さん、はじめまして。
ご愛読いただき、ありがとうございます。
ワークプレイス参加は、ドメイン参加しているデバイスの代わりにドメインにデバイス登録する機能なので、ドメイン参加していると残念ながら(現時点では)利用できません。
とても便利な機能なので、ドメイン参加の有無に関わらずにデバイス制御機能である、ワークプレイス参加利用できると良いのですがね。。
国井さん
こんにちは、いつも貴重な情報のご提供をいただきありがとうございます。
私、ADFSを会社に導入するべく、クレームルールの調査、検証を行っております。
現在はオンプレミスADとAzure ADをAADConnectを使って、IDを同期することで、オンプレADのアカウントを使ってOffice365へのアクセスを行っております。
現在はいつでも、どこでも、どんなデバイス(PCやiPhone) からもアクセスができ、
便利な反面、セキュリティの強化が必要と会社からは言われております。
そこで、adfsとWAPを導入し、以下のような制限をかけたいと思っております。
(原則として、PCからO365へ接続するにはVPN接続を行い、社内LANからアクセスさせます)
1.社内からOffice365へ接続する際のIPアドレスの制限
2.社外のiPhoneからyammer、Skype、Onedriveへのアクセスを許可
1.については、x-ms-proxyを使用して、会社の使用しているグローバルIPを指定することで、解決できると思っております。(実際にできております。)
しかし、2のように個別のアプリケーションを制御する場合は、どのような記述をすれば、制御ができるのでしょうか。
調べられた限りでは、クライアントが使用している”プロトコル”や”ブラウザベース”という大枠を制御できるというクレームルールはありそうですが、アプリケーションを個別に制御という記述の方法が見つかりません。
そもそも、個別のアプリケーション単位でクレームルールを書くことはできないのでしょうか。不勉強で大変恐縮ですが、可能な範囲でご教示いただけますと幸いです。
長文、失礼いたしました。
どうぞ宜しくお願い致します。
中村さん、こんにちは。
ご愛読いただき、ありがとうございます。
ご連絡いただきましたクレームルールですが、私の知る限りアプリケーションを識別する方法はないです。代わりに、アプリケーションによって使用するADFSのエンドポイントが異なるので、x-ms-endpoint-absolute-pathクレームルールを利用して、アクセスさせたい(させたくない)アプリケーションで使用するエンドポイントを指定すると良いと思います。
例えば、ブラウザーアクセスの場合であれば/adfs/ls/というエンドポイントを使用するので、アプリケーションで使用するエンドポイントを確認し、それに合わせてクレームルールを書くような方法があります。
ざっくりとした説明で恐縮ですが、参考になれば幸いです。
国井さん
お忙しいところ、ご返信いただきありがとうございます。
個々のアプリケーションごとに、制御するルールはなさそうなのですね。x-ms-endpoint-absolute-pathについては調査をいたします。
また、非常に初歩的なことなのですが、クレームルールの適用順序は、指定した順序に評価され、それぞれの内容が適用されると認識しております。
例えばですが、ユーザーがOutlookでメール送受信をしている状況で、
1.Office365へのアクセスは社内からのアクセスに限定
(x-ms-proxyとx-ms-forwarded-client-ipでIPアドレス制限)
2.iPhoneについては、社外からのアクセスをさせたい
という場合、以下のようにクレームルールを記載していますが、社外のiPhoneからO365へアクセスができません。
順序1.すべてのユーザーにアクセス許可
順序2.iOSを許可
順序3.社内のIPからのみO365へアクセス許可
これは、順序3.で社内のIPからのみアクセス許可のルールがあるからだと思っています。
ADFSのクレームルールで、iOSだけは社外からもアクセス、そのほかは社内IPからのみアクセスさせるというような書き方はできるものなのでしょうか。
返信で質問をしてしまい、大変恐れ入りますが、
ご返信いただけますと幸いです。
どうぞ宜しくお願い致します。
中村さん、こんにちは。
クレームルールを使ったiOSによるアクセス制御ですが、
本稿を執筆した時と現在ではクレームルールによる制御方法が変わってしまっているようで、私のところでもクレームルールを使ったiOSによるアクセス制御はできなくなっています。何かわかりましたら、またご紹介をさせていただきます。
国井さん、こんにちは。
お忙しいところ、貴重な情報の共有をいただき、ありがとうございます。
iOSの制御の件、かしこまりました。
新たな情報がありましたら、ご共有いただけますと幸いです。
どうぞ宜しくお願い致します。