Microsoft Entra External IDで外部ユーザーにMFA必須＋レガシー認証をブロックする方法【無料プラン対応】

Microsoft Entra External ID（旧Azure AD B2C系）の無料枠で、「外部ユーザーにはMFAを必須にしつつ、レガシー認証もブロックしたい」と考えたとき、Conditional Access（条件付きアクセス）の「クライアントアプリ」条件がグレーアウトして途方に暮れるケースが少なくありません。本記事では、この現象の正体と、無料層でも実現できる現実的な設計パターンを、管理者目線で丁寧に解説します。

Entra External IDで直面する典型的な課題

今回のテーマは次のような要件です。

対象：Microsoft Entra External ID（顧客向け／External ID for customers）の無料層
目的：外部ユーザー（顧客）にMFAを必須にしたい
あわせて：レガシー認証（基本認証）をブロックしたい

ところが、セキュリティの既定値（Security defaults）を無効化して CA を作ろうとすると、

条件の「クライアントアプリ」がグレーアウトして「Not available」になる
その結果、よく紹介されている「レガシー認証をブロックするCAポリシー」が作れない

というハマりポイントにぶつかります。

疑問	ざっくりした内容
1.	「クライアントアプリ」条件が使えないのは P1/P2 ライセンスがないから？
2.	無料層だと「MFA強制」と「レガシー認証ブロック」は両立できない？
3.	セキュリティの既定値を有効にしても、外部ユーザーにMFAがかからないのはなぜ？
4.	無料層で両方の目標を達成する「正しいやり方」は何？

結論から言うと、

MFAの強制は CA で実現可能
レガシー認証のブロックは CA ではなく「サービス側」で行う
セキュリティの既定値だけでは、External ID の外部ユーザーは十分に守れない

という整理になります。ここから順番に解説していきます。

前提整理：Entra External ID とライセンス・テナント種別

Entra External ID（顧客）とは何か

Microsoft Entra External ID は、顧客・市民・パートナーなど、自社従業員以外の外部ユーザー向けの ID 基盤です。いわゆる CIAM（Customer Identity and Access Management）用途で、サインアップ／ログインを任せるためのプラットフォームだと考えるとわかりやすいでしょう。

External ID には大きく分けて、

Workforce テナントの中で使う B2B（ゲスト）
External ID for Customers（顧客専用テナント）

の2パターンがあります。本記事で扱うのは後者、顧客専用テナント（External ID for Customers、無料枠）を前提とします。

無料層（Free tier）のイメージ

External ID の料金モデルは、従業員向けの「ユーザー課金」ではなく、月間アクティブユーザー（MAU）課金です。代表的な条件は以下の通りです。

項目	概要
無料枠	最大およそ 50,000 MAU まで無料
それ以降	超過したMAU数に応じて従量課金
機能	MFA や Conditional Access を含む、多くの機能が利用可能

従業員向け Entra ID（Workforce）では、CA を使うのに Premium P1 ライセンスが必要ですが、External ID for Customers ではMAU 課金の中に CA が含まれる構造になっており、「P1/P2が無いから CA が制限される」という話とは少し違う世界になっています。

セキュリティの既定値と CA の違い

Entra ID には、特に小規模環境向けにセキュリティの既定値（Security defaults）が用意されています。これは、ライセンス不要・設定簡単な代わりに、カスタマイズ性はほぼゼロという「おまかせモード」です。

項目	セキュリティの既定値	Conditional Access（CA）
ライセンス	不要	Workforce では P1 以上が必要／External ID は MAU 課金に含まれる
設定粒度	オン／オフのみ	ユーザー・グループ・アプリ・条件など細かく制御可能
対象ユーザー	主に社内ユーザーを想定	社内・ゲスト・External ID ユーザーを柔軟に指定可能
レガシー認証の制御	一部の既定設定のみ	通常は「クライアントアプリ」条件で細かく制御（ただし External ID には制約あり）

External ID の顧客シナリオでは、セキュリティの既定値ではカバーしきれないので、最終的にはCA ポリシー＋サービス側設定に寄せていくのが現実的です。

なぜ「クライアントアプリ」条件がグレーアウトするのか

原因はライセンスではなく「プラットフォーム制約」

Microsoft Q&A で公開されている情報によると、External ID の顧客テナントにおいて「クライアントアプリ（Client apps）」条件が使えない理由は、P1/P2 ライセンス不足ではなく、プラットフォームの仕様（制約）であると明言されています。

つまり、

たとえ P1/P2 相当の機能を持っていたとしても
External ID では、外部ユーザーを対象とした CA でクライアントアプリ条件を利用できない

という設計になっています。

一方、Workforce テナントにおける B2B ゲストユーザーなどでは、クライアントアプリ条件を使ってレガシー認証プロトコルをブロックするシナリオが公式ドキュメントでも紹介されています。

この違いが、External ID で「クライアントアプリ」がグレーアウトする根本原因です。

よくある誤解と正しい理解

誤解	実際
「無料だから Client apps が使えない」	× ライセンスではなくExternal ID プラットフォームの仕様
「P1/P2 を買えば解決する」	× 顧客テナントの External ID 用 CA では、依然としてクライアントアプリ条件が使えない
「CA でレガシー認証をブロックする手順がそのまま使える」	× その手順は多くが Workforce テナント前提。External ID ではサービス側でレガシー無効化が基本

したがって、External ID では「レガシー認証だけを狙い撃ちしてブロックする CA ポリシー」を作ることはできません。この前提を押さえておかないと、延々と UI と格闘することになります。

外部ユーザーへの MFA 強制は CA で実現できる

外部ユーザーを対象にした CA ポリシーの考え方

Microsoft のドキュメントでは、外部（ゲスト）ユーザーに対しても、従業員と同様に Conditional Access ポリシーで MFA やデバイス要件を課すパターンがサポートされていることが示されています。

External ID for Customers の場合も、

対象ユーザーに External ID の顧客ユーザーを指定
対象アプリとして自社の Web / ネイティブアプリを指定
アクセス制御で「MFA を要求」または「認証強度（Authentication strength）」を指定

という形で、外部ユーザーのログインに MFA を必須化できます。

無料層での基本ポリシー例

External ID の無料層で、まず押さえておきたい代表的な CA ポリシー例を表にまとめます。

ポリシー名	対象ユーザー	対象アプリ	制御内容	ポイント
External-Require-MFA	External ID の全顧客ユーザー	顧客向け Web / SPA / ネイティブアプリ	アクセス許可 → MFA を要求（または認証強度：Multi-factor）	最重要。通常は除外を最小限にし、ブレークグラス管理者のみ除外
External-HighRisk-Block	外部ユーザー（必要に応じて一部のみ）	重要度の高いアプリ	サインインリスクが高の場合はアクセスをブロック	Entra ID Protection を併用できる場合の強化策
External-Locations-Block	外部ユーザー	全アプリ	特定の国・地域/IPからのアクセスをブロック	典型的な地理的制限。なりすましやボット対策に有効

重要なのは、ここではあえて「クライアントアプリ」条件を一切使わずに設計することです。

クロステナントの MFA を信頼して二重認証を避ける

相手組織の従業員が自社の External ID アプリを利用するケースでは、クロステナントアクセス設定で「相手テナントの MFA を信頼する」設定を有効にしておくと、MFA の二重プロンプトを避けられます。

相手テナントで既に MFA 済みであれば、そのクレームを信頼して追加の MFA は不要
MFA を信頼しない設定にすると、自社テナント側で再度 MFA を要求

顧客体験を損なわずにセキュリティを維持するため、B2B 連携が多い環境では、この「MFA の信頼設定」を検討する価値があります。

レガシー認証ブロックは「サービス側」で行う

External ID では CA によるレガシー認証ブロックは困難

先ほど触れたように、External ID ではクライアントアプリ条件が利用できないため、

IMAP / POP / SMTP AUTH / Exchange ActiveSync などのレガシープロトコル
Basic 認証クライアント、古い Office クライアント

だけを狙って CA でブロックする、というやり方は採れません。Microsoft Q&A でも、External ID ではクライアントアプリによるフィルタリングができないため、レガシー認証の無効化は Exchange Online 等のサービス側で行うべきとされています。

サービス側でレガシー認証を止める代表的な方法

ケース	やること	具体例
Microsoft 365 メール等も External ID と併用している	Exchange Online の認証ポリシーでレガシープロトコルを無効化	POP / IMAP / SMTP AUTH / EAS 基本認証をすべて無効必要であればサービスアカウント用に限定的なポリシーを作成
自社 Web / API のみを External ID で保護している	アプリ側でBasic 認証や古い OAuth グラント（ROPC など）を許可しない	OIDC / OAuth 2.0 の対話認証＋MFA を前提にするクライアント資格情報（client credentials）など機械同士の認証も、証明書ベース or シークレット＋IP 制限などで保護
レガシークライアントをどうしても残したい	限定的な例外とし、別テナントや専用アカウントに隔離する	可能な限り早くモダン認証対応クライアントに更新期間限定の暫定措置としてリスクを明確化

ポイントは、External ID の世界では「そもそもレガシー認証を許すサービスやアプリを設計に含めない」のが王道だということです。レガシーを許す必要が生じた時点で、セキュリティと利便性のトレードオフを改めて評価すべきフェーズに来ていると言えます。

セキュリティの既定値と外部ユーザーの微妙な関係

なぜセキュリティの既定値で外部ユーザーに MFA がかからないのか

Microsoft Q&A の External ID に関する回答では、セキュリティの既定値は主に社内ユーザー向けに設計されており、外部ユーザーにはそのままでは適用されないことが指摘されています。

簡単にまとめると：

セキュリティの既定値は「MFA や基本的な保護を簡単に有効化する」ための仕組み
ただし、External ID の顧客シナリオでは、外部ユーザーに対して期待どおりの MFA 強制にならないことがある
外部ユーザーを確実に保護したい場合は、外部ユーザー向けの CA ポリシーを明示的に作る必要がある

セキュリティの既定値は便利な一方で、「どこまでを誰にどう効かせているのか」がブラックボックスになりやすく、External ID のような特殊シナリオでは、挙動がイメージしづらいのが難点です。

External ID では「セキュリティの既定値 or CA」ではなく「CA 一択」

Microsoft の公式ドキュメントでも、セキュリティの既定値と CA は併用せず、どちらか一方を選ぶべきとされています。CA に切り替える場合は、セキュリティの既定値を無効化したうえで、必要な CA ポリシーを構成することが推奨されています。

External ID では、

外部ユーザー向けに細かく MFA やアクセス制御を設計したい
テナント全体の挙動を明示的にコントロールしたい

という要件がほぼ必ず出てくるため、実務的には「セキュリティの既定値はオフ＋CA で統一」という運用が現実解になります。

無料層で「MFA必須」と「レガシー遮断」を両立する設計パターン

全体アーキテクチャのイメージ

ここまでの内容を、1枚の図にまとめると次のような考え方になります。

認証の入口：Entra External ID（顧客テナント）
MFA 強制：External ID テナントの CA ポリシーで実施
レガシー認証の遮断：各サービス／アプリ側でレガシープロトコルを無効化
内部管理者の保護：Workforce テナントまたは別管理用テナントの CA でレガシーブロック＋MFA

ステップ別の実践手順

ステップ1：セキュリティの既定値を無効化

Entra 管理センター → Entra ID → プロパティ →「セキュリティの既定値の管理」から無効化
この時点で、外部ユーザー保護は CA とサービス側設定で行う方針に切り替える

同時に、ブレークグラス用の管理者アカウント（MFA 非依存でログイン可能な緊急アカウント）を 1〜2 個用意し、CA ポリシーから除外しておくのが安全運用の基本です。

ステップ2：外部ユーザー向け CA ポリシー（MFA 必須）を作成

External ID の顧客ユーザーをターゲットにした CA を作成します。

ユーザーとグループ
- 対象：External ID の顧客ユーザー全体、またはそれをまとめたグループ
- 除外：ブレークグラス管理者アカウントなど最小限
対象クラウドアプリ
- 自社の顧客向けアプリ（Enterprise アプリ／アプリ登録）を選択
- 不要に「すべてのクラウドアプリ」にしない（管理ポータルへの影響を避けるため）
条件
- 「クライアントアプリ」条件は設定不可（External ID の仕様）
- 必要に応じて、位置情報やデバイス、リスクなどを追加
アクセス制御 → 付与
- 「アクセスを許可」＋「多要素認証を要求」にチェック
- より厳密にする場合は「認証強度：Multi-factor または Passwordless など」を指定
モード
- 初期は「レポート専用」にしてログを確認
- 問題が無ければ「オン」に切り替え

このポリシーにより、External ID の外部ユーザーには常に MFA を要求できるようになります。

ステップ3：サービス側でのレガシー認証無効化

続いて、実際にレガシー認証を提供している可能性のあるサービスを棚卸しし、それぞれでレガシーを止めていきます。

Exchange Online を利用している場合
- PowerShell で認証ポリシーを作成し、POP/IMAP/SMTP AUTH/EAS などの基本認証を無効化
- 組織内の全アカウント、または対象のみに認証ポリシーを適用
独自 Web アプリ／API
- アプリケーションコードから Basic 認証ハンドラを削除
- MSAL ライブラリなどを用いて OAuth2 / OIDC に統一
- 「パスワードを投げるだけ」のような古い通信は設計段階から禁止

ステップ4：内部アカウント（管理者）の守り方

問題になりやすいのが「External ID テナントを誰が管理しているか」です。

従業員用の Workforce テナントが別にあり、そこで管理者がログインしている → Workforce 側で通常どおり CA を構成し、クライアントアプリ条件でレガシー認証をブロック＋MFA 必須にします。
External ID テナント内にしか管理者が存在しない → その管理者に対しても、MFA を必須にする CAを適用しつつ、利用しているサービス側でレガシー認証をオフにすることで防御層を確保します。

可能であれば、管理者用アカウントは Workforce テナント側に集約し、External ID テナントにはゲストとして参加させる方が、管理モデルとしてはシンプルです。

ステップ5：サインインログによる検証とチューニング

CA を本格適用する前後で、サインインログの確認は必須です。

Entra 管理センター → サインインログから
- 認証の種類（モダン／レガシー）
- クライアントアプリ（ログ上の分類としては表示される）
- 失敗したサインインの理由（MFA 未完了、ポリシーブロックなど）
レポート専用モードの CA を一時的に有効にし、想定外のブロックが発生していないか確認
問題がなければ本番モードに切り替え、定期的なログレビューを運用に組み込む

運用ベストプラクティスとよくある落とし穴

落とし穴1：MFA 非対応クライアントを「なんとなく」許してしまう

顧客側の事情で「古いメールクライアントしか使えない」「MFA に対応していないシステムがある」といった声が上がることがありますが、External ID の設計思想からすると、これはアプリ側をモダン認証対応に寄せるべきシグナルです。

レガシー認証を一部許容すると、その部分が攻撃の踏み台になりやすい
例外を増やすと、CA の設計と運用が急速に複雑化する

どうしても必要なケースでは、

別テナントや専用ネットワークに隔離する
アクセス元 IP を極端に絞る
期間限定の暫定措置とし、廃止期限を決める

といった「リスクを囲い込んだ」運用を検討しましょう。

落とし穴2：除外設定が増えすぎて形骸化する

CA を運用していると、「この顧客はMFAを嫌がるから…」「このシステムだけは…」と除外を増やしがちです。しかし、除外が増えすぎると、

どこまで守れているのかが管理者にも分からない
インシデント時に「なぜこのアカウントだけ保護されていなかったのか」を説明しづらい

といった問題を引き起こします。原則として、

恒久的な除外はブレークグラスアカウントのみ
その他は「一時的な除外」として期限を設ける

という方針をチーム内で共有しておくと、将来のトラブルを減らせます。

落とし穴3：ユーザーコミュニケーションを軽視する

MFA の強制やレガシー認証の遮断は、顧客側の操作感に直結します。技術的な設定だけでなく、

MFA 登録手順書や FAQ の提供
切り替えスケジュールの事前告知
トラブル時のサポート窓口（メール／チャット）の明示

といった「非技術的な準備」をセットで行うことが、結果的に管理者の負荷軽減につながります。

この記事のポイントまとめ

最後に、冒頭の4つの疑問に対応する形で、要点をまとめます。

1. 「クライアントアプリ」条件が使えないのは P1/P2 のせい？

いいえ。ライセンスではなく External ID プラットフォームの仕様です。
External ID for Customers の CA では、外部ユーザーに対してクライアントアプリ条件を適用できません。

2. 無料層だと「MFA 必須」と「レガシー認証ブロック」は両立できない？

両立は可能です。
MFA：External ID テナントの CA ポリシーで外部ユーザーに対して必須化
レガシー認証ブロック：Exchange Online 等のサービス側設定でレガシープロトコルを無効化

3. セキュリティの既定値が有効でも、なぜ外部ユーザーに MFA がかからない？

セキュリティの既定値は、主に社内ユーザー向けに設計された簡易保護機能です。
External ID の外部ユーザーに対しては、期待通りに MFA を強制できないケースがあるため、外部ユーザー向け CA を明示的に設計する必要があります。

4. 無料層で両目標を達成する「正しいやり方」は？

本記事で紹介したように、以下の組み合わせが現実的かつ推奨しやすいパターンです。

目的	実現手段	設定場所
外部ユーザーに MFA を必須化	外部ユーザーを対象にした CA ポリシーで「MFA を要求」または「認証強度」を指定	Entra External ID テナント（CA）
レガシー認証のブロック	IMAP/POP/SMTP AUTH/EAS の無効化、Basic 認証の禁止、ROPC 不使用	Exchange Online 等の M365 サービス／自社アプリ側
内部管理者の保護	Workforce テナントの CA でクライアントアプリ条件を用いてレガシーブロック＋MFA	社内用 Entra ID（Workforce テナント）

このように、「MFA は CA で」「レガシー認証ブロックはサービス側で」という役割分担を徹底すれば、External ID の無料層でも、外部ユーザーに対する MFA 強制とレガシー認証の遮断を両立することができます。

External ID の仕様に振り回されるのではなく、「何をどこで守るのか」を整理しながら設計していくことで、無料枠の範囲でも十分に実用的でセキュアな環境を構築できるはずです。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft Entra External IDで外部ユーザーにMFA必須＋レガシー認証をブロックする方法【無料プラン対応】

Entra External IDで直面する典型的な課題