くらめその情シス：EntraID 条件付きアクセスをMDMの条件でテストしてみる
この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
この記事は2025年10月に更新しています。
はじめに
どうも、情シスの徳道です。これまでくらめその情シスシリーズではEntraID（旧Azure AD）やIntuneを連続して取り上げてきました。
EntraIDによるリモートワーク時のユーザー認証やモバイルデバイスマネジメント、PCの自動セットアップなどのメリットと並び、EntraIDを利用することの内部統制で期待を寄せている仕組みがあります。
それが今回取り上げるEntraID 条件付きアクセス（以下、条件付きアクセスと記載）です。
せっかくユーザー認証やデバイスがリモート環境でも集中管理できるようになったわけですから、それをどう活かすか、ということになると思います。
やはり社内システムへの安全なアクセスをさせたい、と思うのはどこでも同じではないでしょうか。
昨今はゼロトラストネットワークアーキテクチャ(ZTNA)というキーワードが注目を浴びています。
囲われたネットワークではなくエンドポイントを評価する、というきめ細かく安全なアクセスを実現する方法の一つとして、今回はEntraIDとIntuneによるデバイス状態による条件付きアクセスがどのようになるか、実機でテストした結果を紹介したいと思います。
【ご注意ください】
条件付きアクセスを利用するためにはAzure EntraID Premium P1以上のライセンスが必要となります。
また、モバイルデバイスマネジメントの利用にはIntuneのライセンスが必要です。
これまでのEntraIDとIntuneの環境構築、ライセンスについてはこちらをご覧ください。
【AzureAD+Intuneを利用するために必要なライセンス】
テスト用のサービスプロバイダーを設定
条件付きアクセスでテストをするためには、アクセス先となるシングルサインオンのAzureのアプリが必要です。
気を付けないといけないのは現在利用しているかもしれないアプリを条件付きアクセスに設定しないようにすることですね。
（ユーザーに大迷惑をかけちゃいます。。。）
ステージング環境を持っていればいいのですが、そこまでしなくともテスト用のWebアプリを登録してしまえばいいわけです。
今回はこちらのSSOテスト用サービスプロバイダー（SP）のサイトを利用してみました（無料で利用可能です）
【SAML Test Service Provider】
https://sptest.iamshowcase.com/
なおこのセクションではこちらのサイトを参考にさせていただきました。厚く御礼申し上げます。
https://idmlab.eidentity.jp/2018/02/samlidpsp.html
SPのメタデータを取得する
今回は条件付きアクセスでアクセスができる/できない の確認ができればいいわけですね。
今回はSAML Test Service ProviderのURLにアクセスしたらAzureADで認証される、という想定で設定を行いました。
SAML Test Service Providerにアクセスしたら、上側にある「Instructions」のドロップダウンリストから「IDP Initiated SSO」をクリックします。
「DOWNLOAD METADATA」のボタンをクリックします。
XMLのメタデータが表示されますので、「entityID」と「AssertionConsumerService BindingのLocation」を探して値をメモしておきます。
下図の赤ラインの値です。
EntraIDにSPのアプリを登録する
ここからEntraIDでの操作です。SAML Test Service Provider のWebアプリを登録します。
「条件付きアクセス管理者ロール」と「アプリケーション管理者ロール」を付与されたユーザーでのログインが必要です。
Microsoft Entra ID でのロールベースのアクセス制御の概要
Azureのホームで「エンタープライズアプリケーション」を検索して開きます。
エンタープライズ アプリケーション | すべてのアプリケーション
「新しいアプリケーション」をクリックします。
「独自のアプリケーションの作成」をクリックします。
適当にテストアプリ名を付けて作成します。ここでは「SP-SSO-TEST」にしました。
アプリが作成されると各種設定の画面になりますので、メニューの「シングルサインオン」→「SAML」を開きます。
ステップ１ 基本的なSAML構成 を編集して、識別子と応答URLに先ほどSAML Test Service Providerから取得した情報を設定します。
SAML構成を保存すると、SAML署名証明書が作成されますので、「フェデレーション メタデータXML」をファイルでダウンロードしましょう。
実際のアプリケーションでは証明書やURLを用いるケースもあります。
また、先にアクセステストをさせるAzureADユーザーもこのアプリに割り当てておきます。
SPにフェデレーションメタデータを設定する
SAML Test Service Providerに操作を戻します。
先ほどAzureADからダウンロードしたXMLファイルを「Setting up SP initiated SSO」の下にある 「CHOOSE FILE」に設定し、「SUBMIT FILE」をクリックします。
するとポップアップウィンドウが開き、URLが表示されます。これがSAML Test Service ProviderにAzureADからSSOをするURLです。
コピーしておきましょう。
余談ですが、同じフェデレーションメタデータを指定する限り、同じURLが発行されますので、誤って閉じてしまった場合はもう一度XMLファイルをSUBMITすれば大丈夫です。
SSOをテストする
では生成されたURLにアクセスしてみましょう。
最初にAzureADのログイン画面に遷移しました。ここでは先ほどアプリに割り当てたAzureADのユーザーIDでログインします。
EntraIDのユーザーでログインできました！ユーザー名が表示され、画面の下にはSAMLのログインで取得された情報が表示されています。
これで条件付きアクセスをテストする準備ができました。
条件付きアクセスを設定する
条件
要件付きアクセスに設定するは以下としました。
【SAML Test Service Providerが以下の条件で表示されること】
- Windows、Macのブラウザ
- Intuneのデバイスポリシーに「準拠」しているマシンでのアクセス
- １、２以外の条件ではアクセスできないこと
-
- アクセス許可されたEntraIDユーザーではない
- デバイスがIntuneに参加していない
- デバイスがIntuneのデバイスポリシーに準拠していない
条件付きアクセスのポリシー作成
EntraIDに「条件付きアクセス管理者ロール」を付与されたユーザーでのログインしましょう。
ホームから「EntraID 条件付きアクセス」を開きます。
「新しいポリシー」をクリックして作成していきます。
【ユーザーとグループの割り当て】
まずは条件付きアクセスの名前を付けましょう。今回はアプリと同じ名前にしていますが、もちろん任意です。
最初にEntraIDのユーザーか、グループを割り当てます。
アプリのアクセス許可を与えたユーザー、またはグループと一致させておくことが基本形になると思います。
社内基幹システムなどであればすべてのユーザーにしておくこともよいでしょう。
【アプリの割り当て】
この条件付きアクセスにアプリを割り当てます。
複数のアプリを割り当てることができるので、同一条件であれば一つにしておくと管理が楽になると思います。
【条件の割り当て】
続いて、この設定のキモであるアクセスを許可するための条件を設定します。
デバイスプラットフォーム
デバイスプラットフォームではOSやデバイスの種類を明示的に指定します。
スマホアクセスを許可しないなど、利用する組織のポリシーに従って選択すればよいと思います。
今回はテスト要件に従ってWindowsとMacだけにしました。
クライアントアプリ
クライアントアプリはブラウザ想定です。先進認証クライアントはチェックをつけておきます。
レガシー認証クライアントはどんなものがあるのか私はちょっと想像できませんでしたが、ひとまず外しておきます。
2025年10月現在では、このほかに
・ユーザーのリスク
・サインインのリスク
・インサイダーリスク
・場所（グローバルネットワークの国や地域を指定）
・デバイスのフィルター
・認証フロー
などの設定がありますが、これらはより高度かつきめ細かい指定のために利用します。
今回は使用しないので、「未構成」のままでもOKです。
アクセス制御-許可
次にアクセス制御の設定となります。
ここでは「許可」の制御だけにしておきます。今回のテストではページが開ければOKなので、セッションの設定はしていません（クラスメソッド社内アプリではこの部分をサインインの頻度で設定しています）。
許可項目の「多要素認証を要求する」「デバイス準拠しているとしてマーク済みである必要があります」の2つにチェックをします。
ここで「多要素認証を要求する」を設定することで、すでにAzureにログイン済みのユーザーであっても、改めて多要素認証を義務付けることができ、一層セキュアにアプリアクセスをさせることができます。
【参考：Azureの多要素認証設定についてはこちらも併せてごらんください】
弊社の環境ではMicrosoft Entra Hybridを利用していないこと、ブラウザでのアクセスになるので、下の3点はチェックを入れません。 「承認されたクライアントアプリが～」はマイクロソフト製のアプリ等、でのアクセスに限定する場合なので、 Webアプリの追加の場合はチェックを入れないようにしましょう。
また、注意が表示されていますが、Azure管理コンソールに条件付きアクセスを設定するときは操作をしている方のデバイスがポリシーに合致しているか確認しましょう。
もし、操作している方のマシンがポリシーに準拠していないと管理画面にアクセスできなくなってしまいますので。。。
最後の設定です。ここまで設定をすると、最下部に以下の表示が現れます。
「オン」を選択して「作成」をすると、ポリシーが有効になります。
テストしてみる
では、早速要件に従ってテストしてみましょう。
以下の画面はEntraID上で、私のユーザーに割り当てられているデバイスの一覧です。
こちらと、別のEntraIDユーザーでSP-SSO-TESTの条件付きアクセスに設定していないユーザーをテストしてみます。
WindowsでChromeを使う場合は拡張アプリが必要
ここで準備が一つ。WindowsでChromeを利用して条件付きアクセスで制御されたアプリにアクセスする場合は、拡張アプリのインストールが必要です。
Chromeウェブストアから「Microsoft Single Sign-on」を探して追加をしてください（Mac版ChromeやEdge/Safariでは不要です）。
許可されたユーザー、ポリシーに準拠したデバイス
まず、私の個人ユーザーIDと、私の個人に割り当てられたWindowsPCから作成したSAML Test Service ProviderのURLにアクセスします。
おっと、多要素認証のコードを求められます。意図した動作ですね。
はい、問題なくアクセスできます。
同じく、私の個人ユーザーIDと、私の個人に割り当てられたMacからもアクセスしてみます。
もちろん、こちらも問題なくアクセスできました（Macの画面とわかるようにウィンドウでキャプチャ）。
許可されたユーザー、ポリシーに準拠していない/Intuneに参加していないデバイス
では次のテスト。
ユーザーは許可されており、Intuneに参加しているけれど、ディスク暗号化ができずポリシーに準拠していない WindowsPCからのアクセス。Intuneに参加ていないデバイスからも同様です。
ログイン～多要素認証までは許可されたデバイスと同じですが、以下の表示になってアクセスできませんでした。
意図通りの動作です。
許可されていないユーザー
では、そもそもユーザーが許可されていない場合も確認しておきます。マシンはIntuneに参加して準拠されたデバイスです。
こちらはそもそもがユーザーに権限がない、というエラーになります。これはデバイスの準拠以前なので、どのデバイスで試しても同じでした。
以上でテスト要件は全部〇でした！
- Windows、Macのブラウザ：〇
- Intuneのデバイスポリシーに「準拠」しているマシンでのアクセス：〇
- １、２以外の条件ではアクセスできないこと
-
- アクセス許可されたEntraIDユーザーではない：〇
- デバイスがIntuneに参加していない：〇
- デバイスがIntuneのデバイスポリシーに準拠していない：〇
さいごに
リモートワークの定着が進んでいる昨今では社内システムへのアクセスにより神経を尖らせているシステム担当者の方もいると思います。
Idpにシングルサインオンを任せ、かつデバイスが正しいこと（会社で貸与、管理できているものでのログイン）を検出、制御できる仕組みがあるとインターネット経由での接続もさらにセキュアになると思います。
今回の検証をもとに社内システムに活用していければいいなと考えています。
実現の暁にはまた運用や切り替えのノウハウをご紹介できれば、と思います。
最後までお読みいただき、ありがとうございました！
