【Entra ID】条件付きアクセスが想定外に適用される時の対象ユーザーと除外条件確認

Entra ID(旧Azure AD)の条件付きアクセスは、組織のセキュリティを強化する強力な機能ですが、設定を誤ると想定外のユーザーにポリシーが適用され、業務に支障をきたすことがあります。特に「すべてのユーザー」を対象にしたポリシーや、除外グループの指定を間違えると、本来アクセスを許可すべきユーザーがブロックされるケースが発生します。本記事では、条件付きアクセスが想定外に適用される原因を具体的に分析し、対象ユーザーと除外条件の確認手順を詳しく解説します。

条件付きアクセスが想定外に適用される主な原因

条件付きアクセスポリシーが想定通りに動作しない背景には、いくつかの典型的な原因があります。これらを理解することで、問題の早期発見と修正が可能になります。

ユーザーとグループの指定ミス

最も多い原因は、ポリシーの対象範囲を「すべてのユーザー」に設定しているにもかかわらず、除外グループを正しく指定していないことです。例えば、特定の部署だけを対象にするつもりで「すべてのユーザー」を選び、除外にその部署以外のグループを追加した場合、意図しないユーザーが含まれることがあります。また、グループのメンバーシップが動的に変更される場合、想定外のユーザーが対象になるリスクがあります。

条件設定の誤解

「条件」タブで設定する「サインインリスク」「デバイスプラットフォーム」「場所」などの条件が、意図したスコープと異なる場合があります。特に「場所」条件で「すべての信頼できる場所」を選択すると、組織外からのアクセスがブロックされる一方で、内部ネットワークからも制限がかかることがあります。

複数ポリシーの優先順位と影響

条件付きアクセスは複数のポリシーが同時に評価され、すべてのポリシーを満たす必要があります。そのため、あるポリシーで許可されていても、別のポリシーでブロックされる場合があります。ポリシーの優先順位(番号)は影響しませんが、最適用のルールとして「すべてのポリシーを満たす必要がある」という点を理解しておくことが重要です。

対象ユーザーと除外条件を確認する手順

ここでは、条件付きアクセスポリシーの設定を確認し、想定外の適用がないかをチェックする手順を説明します。以下の手順は、Entra IDの管理者権限を持つアカウントでAzure portalにアクセスして実施します。

1. 管理者アカウントで Azure portal にサインインします。
2. 検索バーで「Entra ID」と入力し、サービスを選択します。
3. 左側のメニューから「保護」→「条件付きアクセス」をクリックします。
4. ポリシーの一覧から、確認したいポリシーを選択します。
5. 「割り当て」セクションの「ユーザーとグループ」を開き、「含める」と「除外する」の両方を確認します。特に「すべてのユーザー」が含まれている場合、除外グループに適切なユーザーが入っているか確認してください。
6. 「条件」タブを開き、各条件(サインインリスク、デバイスプラットフォーム、場所、クライアントアプリなど)が期待通りに設定されているか確認します。
7. ポリシーの「状態」が「オン」「オフ」「レポート専用」のいずれであるかを確認します。想定外の適用を防ぐには、まずレポート専用モードで影響をテストすることを推奨します。

以上の手順で設定内容を把握した後、実際のサインインログでどのポリシーが適用されたかを確認すると、より正確な診断が可能です。

想定外適用を防ぐための確認ポイント

日頃の運用で気をつけるべきポイントを3つ挙げます。

「すべてのユーザー」設定の注意点

「すべてのユーザー」を対象にすると、ゲストユーザーやサービスプリンシパルも含まれる場合があります。条件付きアクセスはユーザーサインインに適用されるため、ゲストユーザーがアクセスできなくなるトラブルが発生します。そのため、対象を特定のグループに限定するか、除外グループを必ず設定してください。

除外グループの適切な管理

除外グループには、緊急時にポリシーの影響を受けないユーザー(例:管理者アカウント)を追加します。ただし、グループのメンバーシップが定期的に見直されないと、退職したユーザーが残ったままになるリスクがあります。グループの所有権や監査ログを活用して、定期的に確認することが重要です。

緊急アクセスアカウントの除外

条件付きアクセスポリシーによりロックアウトされるのを防ぐため、少なくとも2つの緊急アクセスアカウント(クラウド専用のグローバル管理者など)をすべてのポリシーから除外することを強く推奨します。これにより、ポリシー誤設定時でも管理アクセスを確保できます。

よくある失敗パターンとその対策

実際の事例をもとに、失敗パターンとその対策を表にまとめました。

失敗パターン	原因	対策
全ユーザーが多要素認証を求められないはずが、一部のユーザーだけ求められる	除外グループに該当ユーザーが含まれていない、または別のポリシーが適用されている	除外グループのメンバーシップを確認し、サインインログで適用ポリシーを特定する
管理者がロックアウトされた	緊急アクセスアカウントが除外されていなかった	すぐに別の管理者に依頼してポリシーをオフにする。恒久対策として緊急アクセスアカウントを全ポリシーから除外
ゲストユーザーがアクセスできない	「すべてのユーザー」にゲストが含まれているが、除外設定がない	「すべてのユーザー」ではなく「すべてのメンバーユーザー」を選択するか、ゲストユーザー専用の条件付きアクセスを別途設定する

管理者に確認すべき情報

もし自分でポリシー設定を変更できない場合は、管理者に以下の情報を伝えることで迅速な解決が期待できます。

• 問題の発生時刻と該当ユーザー: いつ、どのユーザーがどのリソースにアクセスできなかったのか。
• サインインログの確認依頼: Azure portalの「サインインログ」から、該当ユーザーのサインインを検索し、「条件付きアクセス」タブで適用されたポリシーを確認してもらう。
• レポート専用モードの利用: ポリシーを変更する前に、レポート専用モードで影響をシミュレーションしてもらう。
• ポリシー設定のエクスポート: 現行の設定をスクリーンショットやJSONで共有してもらい、どのポリシーが問題かを共同で分析する。

よくある質問(FAQ)

Q1: 条件付きアクセスのポリシーは優先順位がありますか?
A: いいえ、条件付きアクセスは優先順位(番号)で適用順序が決まるわけではありません。すべての有効なポリシーが評価され、アクセス許可にはすべてのポリシーを満たす必要があります。そのため、ポリシー間で競合が発生することはありませんが、条件が重なると予期しない結果になることがあります。

Q2: レポート専用モードとは何ですか?
A: レポート専用モードは、ポリシーを実際に適用せずに、サインインの際に「もしこのポリシーが有効だったらどうなるか」をログに記録する機能です。新しいポリシーを有効にする前に、このモードでテストすることで、想定外の影響を事前に把握できます。

Q3: 緊急アクセスアカウントはどのように作成すればよいですか?
A: 通常のユーザーとは別に、クラウド専用のグローバル管理者アカウントを2つ作成し、条件付きアクセスから除外します。これらのアカウントは強力なパスワードと多要素認証で保護し、通常の業務では使用しないでください。

まとめ

条件付きアクセスが想定外に適用される問題は、多くの場合、ユーザーとグループの設定ミスや除外条件の見落としが原因です。本記事で紹介した確認手順を実施し、サインインログとポリシー設定を突き合わせることで、問題の特定が可能になります。また、緊急アクセスアカウントの除外やレポート専用モードの活用は、重大なトラブルを未然に防ぐ有効な手段です。設定変更を行う前には必ず管理者に相談し、影響範囲を十分に検討してください。

👥

Teams/Outlookトラブル完全解決データベース サインイン、接続エラー、メール送受信の不具合など、特有のトラブル解決策を網羅。困った時の逆引きに活用してください。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。