信頼するとなりのテナントの準拠済みデバイス/MFAを許可する！【テナント間アクセス】【アクセス制御】

5月15日 にGAされた Microsoft Entra ID External ID の テナント間アクセス設定により、自テナントのデバイスのみならず、信頼する他テナントのMFAやデバイス状態に応じてアクセス許可/ブロックするということが可能になりました！

M&A などを契機に複数テナントを並行利用している組織や、ゲスト アクセスの認証強化やフロー改善を模索している組織などに刺さる機能と思います！

The device is always greener on the other tenant; となりのテナントのデバイスは青い (準拠済み) ... ということで、本記事では検証内容をもとに本機能の構成例をまとめます。

本記事のカバー範囲は以下です：

• テナント間アクセスの認証フロー
• 動作例：未登録デバイス、準拠済みデバイス、非準拠デバイス、MFA
• 構成例：ホームテナント、リソーステナント
• ご参考：Workbook を使ってテナント間アクセス現状を可視化できるらしい

長めの記事となっていますので、PC ブラウザ勢の方は qiita 標準機能の目次ご活用ください！

テナント間アクセスの認証フロー

早速気になる認証フローですが、すでに素敵フロー図が公開情報にありました。
私が拙い画力を発動させるよりも分かりやすいので、素直に転載します。

• 参考： Authentication flow for external Microsoft Entra users
  

• Home tenant (ホーム テナント)：ユーザーが所属するテナント。公開情報上では仮に「Fabrikam」というテナント名がついている。

• Resource tenant (リソース テナント)：リソースがホストされ、ユーザーがゲスト招待されている先のテナント。公開情報上では仮に「Contoso」というテナント名がついている。

#	イベント概要	説明
1	サインイン	Fabrikam のユーザーが、Contoso のリソースへのサインインを開始
2	CA ポリシー、テナント間アクセス設定の評価	サインイン中に、Microsoft Entra セキュリティ トークン サービス (STS) によって Contoso の条件付きアクセス ポリシーが評価される。 また、テナント間アクセス設定 (Fabrikam の送信設定と Contoso の受信設定) を評価することで、Fabrikam ユーザーがアクセスを許可されているか確認する。
3	リソース テナント 受信信頼設定の評価	Entra ID は Contoso の受信信頼設定を検査し、Contoso が Fabrikam からの MFA とデバイス情報 (準拠済み、ハイブリッド参加済み) を信頼しているか確認する。 (信頼設定が構成されていない場合は、#6 に進む。)
4-a	CA ポリシーが MFA を要求	Contoso が Fabrikam からの MFA を信頼している場合、Entra ID はユーザーの認証セッションを検査し、ユーザーが MFA を完了したことを確認する。
4-b	CA ポリシーがデバイス要件を要求 - 評価	Contoso が Fabrikam からのデバイス情報を信頼している場合、Entra ID はユーザーの認証セッションを検査し、デバイス情報(状態)を確認する。
5-a	CA ポリシーが MFA を要求 - チャレンジ	MFA が必須であるが完了していない場合、Entra ID はユーザーのホーム テナントで MFA チャレンジを発行する。Fabrikam で MFA 要求が満たされた場合、ユーザーは Contoso のリソースへのアクセスを許可される。 要求を満たさない場合、アクセスはブロックされる。
5-b	CA ポリシーがデバイス要件を要求 - チャレンジ	デバイス要件があるが満たされない場合、Entra ID はユーザーのホーム テナントでデバイス チャレンジを発行する。Fabrikam で デバイス要件が満たされている場合、ユーザーは Contoso のリソースへのアクセスを許可される。 要件を満たさない場合、アクセスはブロックされる。
6-a	CA ポリシーが MFA を要求 (信頼設定が無い場合)	【信頼設定が構成されていない場合】　MFA が必要な場合、B2B コラボレーション ユーザーは MFA を要求される (リソース テナントで MFA を満たす必要がある)。 B2B 直接接続ユーザーのアクセスはブロックされる。
6-b	CA ポリシーがデバイス要件を要求 (信頼設定が無い場合)	【信頼設定が構成されていない場合】 デバイスの要件があるが評価できない場合、B2B コラボレーションと B2B 直接接続の両方のユーザーのアクセスがブロックされる。

上表の「説明」列の記載は、公開情報をもとに一部分かりやすいよう編集しました。

• 参考にした公開情報： Authentication flow for external Microsoft Entra users

動作例

当検証環境にて、一般的にありそうな以下動作を確認することができました。

#	シナリオ	結果
1	ユーザーがホーム テナント未登録デバイスより、リソース テナントにアクセスする	アクセス ブロック
2	ユーザーがホーム テナント登録済みデバイス (準拠済み) より、リソース テナントにアクセスする	アクセス許可
3	ユーザーがホーム テナント登録済みデバイス (非準拠) より、リソース テナントにアクセスする	アクセス ブロック
4	ユーザーが MFA を実施し、リソース テナントにアクセスする	アクセス許可

なお、先ほどの認証フロー上でいうホーム テナントとリソース テナントは以下の表示名にしています。

• ホーム テナント： MSSVC Lab
• リソース テナント： MSSVC Dev

以降、各シナリオについてまとめます。

Case 1: ユーザーがホーム テナント未登録デバイスより、リソース テナントにアクセスする

• 結果： アクセス ブロック

以下表の条件で実施しました：

テナント	オブジェクト/機能	構成
ホーム テナント	ユーザー	リソース テナントにゲスト招待されている
ホーム テナント	デバイス	ユーザーのホーム テナント、リソース テナント、いずれにも登録されていない (未登録の野良デバイス)
リソース テナント	リソース	Teams プライベート チーム
リソース テナント	テナント間アクセス設定	ユーザーの所属するホーム テナントから受信するデバイス情報を信頼する
リソース テナント	条件付きアクセス ポリシー	ゲストユーザー含むすべてのユーザーに対し、すべてのクラウドアプリへのアクセスに、準拠済みデバイス または Hybrid joined デバイスが使われている場合、アクセスを許可する

ホーム テナントは野良デバイスの準拠状態を取得できないため、リソース テナントにアクセス試行時許可条件を満たさずにアクセスがブロックされます。

Case 1 ユーザー側画面

リソース テナントからのゲスト招待リンクを踏んで Teams へのサインインを試行します。

サインインはできましたが、リソースへのアクセスがブロックされました。

申し訳ございません。まだここにはアクセスできません
この組織の保護されているリソースに外部ユーザーとしてアクセスしようとしているため、この操作を完了できません。管理者に連絡して、保護されたリソースにアクセスできるようにしてください。

ちなみに英語の場合は以下の文言になります。

Sorry, you can't get to this yet
You can't complete this action because you're trying to access protected resources as an external user in this organization. Please contact the admin to allow you to access the protected resources

Case 1 サインイン ログ

リソース テナント側でゲスト ユーザーのサインイン ログを確認することができます。

リソース テナント側で受信アクセス設定が実際に構成されている/されていないにかかわらず、このケースのサインインログにはエラー原因としてこの文言がありました。(2024年5月検証時点)

AcceptCompliantDevice setting isn't configured for this organization. The admin needs to configure this setting to allow external users access to protected resources.

同じログ画面から、B2B コラボレーション ユーザーであることや、ユーザーのホーム テナントID も載っているため、受信アクセス制限の構成に心配がある場合はこれらをクルーとしてトラブルシュートできそうです。

今回はデバイスが unmanaged 状態のため準拠済みデバイス許可条件をクリアできず、アクセスがブロックされています。

Case 2: ユーザーがホーム テナント登録済みデバイス (準拠済み) より、リソース テナントにアクセスする

• 結果： アクセス許可

Case 1 から、アクセス試行時に利用するデバイスを変えて動作を確認しました。
今回はユーザーのホーム テナントに登録済みかつ準拠済みのデバイスです。

以下表の条件で実施しました：

テナント	オブジェクト/機能	構成
ホーム テナント	ユーザー	リソース テナントにゲスト招待されている
ホーム テナント	デバイス	ユーザーのホーム テナントに登録済みかつ準拠している
リソース テナント	リソース	Teams プライベート チーム
リソース テナント	テナント間アクセス設定	ユーザーの所属するホーム テナントから受信するデバイス情報を信頼する
リソース テナント	条件付きアクセス ポリシー	ゲストユーザー含むすべてのユーザーに対し、すべてのクラウドアプリへのアクセスに、準拠済みデバイス または Hybrid joined デバイスが使われている場合、アクセスを許可する

ホーム テナントからデバイスの準拠情報が連携され、準拠済みであることから、リソース テナントにてアクセスが許可されます。

Case 2 ユーザー側画面

Teams Web Client (ブラウザ上のTeams) の画面です。ゲスト招待された MSSVC Dev テナントにサインインできています。

投稿もできました。

Case 2 サインイン ログ

リソース テナント側でゲスト ユーザーのサインインログを確認すると、デバイスが 「マネージド」かつ「準拠している：はい」と認識されている ことが分かります。
(ただし、ゲストのホーム テナントのデバイスIDは取得できない模様。)

今回はデバイスがユーザーのホーム テナントに登録済み かつ 準拠済み のため、リソース テナントのCAポリシー許可条件をクリアし、リソースにアクセスすることができました。

Case 3: ユーザーがホーム テナント登録済みデバイス (非準拠) より、リソース テナントにアクセスする

• 結果： アクセス ブロック

アクセス試行時に利用するデバイスが非準拠の場合の動作を確認しました。
(ユーザーのホーム テナントに登録済みかつ非準拠のデバイスを利用)

以下表の条件で実施しました：

テナント	オブジェクト/機能	構成
ホーム テナント	ユーザー	リソース テナントにゲスト招待されている
ホーム テナント	デバイス	ユーザーのホーム テナントに登録済みだが、準拠していない
リソース テナント	リソース	Teams プライベート チーム
リソース テナント	テナント間アクセス設定	ユーザーの所属するホーム テナントから受信するデバイス情報を信頼する
リソース テナント	条件付きアクセス ポリシー	ゲストユーザー含むすべてのユーザーに対し、すべてのクラウドアプリへのアクセスに、準拠済みデバイス または Hybrid joined デバイスが使われている場合、アクセスを許可する

Case 3 ユーザー側画面

すでにリソースにサインインしている状態で、アクセス元のデバイスの準拠状態を「準拠している」から 「準拠していない」に推移 させたところ、ユーザー側ではゲスト招待された先のリソース テナントに再度サインインを求める「! (黄色い三角アイコン)」が表示されました。

「! (黄色い三角アイコン)」をクリックしたところ、サインインはできているもののデバイスのコンプライアンス要件によりアクセスがブロックされました。

デバイスは組織のコンプライアンス要件に準拠している必要があります
このデバイスは、組織のコンプライアンス要件を満たしていません。組織のデバイス管理ポータルに移動して、このデバイスが非準拠とマークされている理由を確認してください。

Case 3 サインイン ログ

リソース テナント側でゲスト ユーザーのサインインログを確認すると、デバイスが 「マネージド」だが「準拠している：いいえ (準拠していない)」と認識されている ことが分かります。

エラーの理由欄にも、「条件付きアクセスポリシーにて準拠済みデバイスが求められているが、デバイスが準拠していない」ことが説明されています。

Device is not in required device state: {state}. Conditional Access policy requires a compliant device, and the device is not compliant.

以上、デバイスがユーザーのホーム テナントに登録済みであっても非準拠の場合、リソース テナントのCAポリシー許可条件をクリアできず、リソースへのアクセスがブロックされる ことを確認できました。

デバイスの準拠/非準拠判定は、デバイスが登録された先のホーム テナントの Intune が、ホーム テナントのコンプライアンス ポリシーにもとづいて判断しています。

Case 4: ユーザーが MFA を実施し、リソース テナントにアクセスする

• 結果： アクセス許可

Case 1~3 ではデバイスの状態にもとづくアクセス制御を確認したので、Case 4 では多要素認証にもとづくアクセス制御も確認してみました。

以下表の条件で実施しました：

テナント	オブジェクト/機能	構成
ホーム テナント	ユーザー	リソース テナントにゲスト招待されている
リソース テナント	リソース	Teams プライベート チーム
リソース テナント	テナント間アクセス設定	ユーザーの所属するホーム テナントから受信する MFA を信頼する
リソース テナント	条件付きアクセス ポリシー	ゲストユーザーに対し、すべてのクラウドアプリへのアクセスに、MFAが満たされる場合、アクセスを許可する

Case 4 ユーザー側画面

せっかくなので新Teams クライアントで動作確認しました。
ユーザーは、Teams アプリを起動して 「別のアカウントを追加」 をクリックします。

認証ウィンドウが開くので、ホーム テナントのユーザー ID を入力します。

多要素認証を求められるので、ホーム テナントのユーザー ID と紐づけたモバイルの Authenticator アプリで認証します。

アクセスできました。(最近の Teams は別窓で別テナントの画面を出してくれるようです。)

以降 Teams アプリを開くと、自テナント (ホーム テナント) とゲスト招待されたリソース テナントの切り替えができるようになります。

リソース テナントを開いた様子 ↓

今回はホーム テナント側で MFA セッション トークンが残っていなかったため、MFA がプロンプトされる挙動となりました。

ホーム テナント側に MFA セッション トークンが残っている場合は、リソース テナントアクセスに際し ノー プロンプトでシームレスにアクセスすることができるそうです。
(参考：Collaborate more securely with new cross-tenant access settings)

あっちのテナントでもこっちのテナントでも MFA を求められる... という挙動が長く不評だったそうで、テナント間アクセスがこの解決策になります。

Case 4 サインイン ログ

リソース テナント側でゲスト ユーザーのサインインログを確認すると、MFA 要求が満たされたことによりアクセス許可されていることが分かります。

受信信頼設定が構成されている場合、MFA はホーム テナント側で処理され、リソース テナントに結果が連携されます。
(受信信頼設定：リソース テナントの受信設定で多要素認証情報を信頼するよう構成しておく必要あり。)

External ID GA 以前もゲストアクセスに MFA を求めて認証強化することはよくあるセキュリティ対策だったと思います。
External ID を活用すると、MFA を求めるセキュリティ対策はそのままに、ユーザーはホーム テナントの MFA を利用できるためリソース テナントでさらに MFA 登録・認証 する必要なく、生産性が向上するメリットがあると思いました。

構成例

今回、上記動作を確認するため 2つのテナントを用意しました。
それぞれ、ユーザーが所属するホーム テナントと、リソースをホストするリソース テナントに見立てて構成しています。

概要

ホーム テナント

ユーザーが所属するテナントです。

• 表示名： MSSVC Lab

#	準備物	構成	補足
1	ユーザーアカウント	セキュリティを考えると掲載できないため、 Jane と仮称します。	ホーム テナントの Entra ユーザーを、リソース テナントにゲスト招待して使います。
2	デバイス	未登録デバイス、Entra registerred Windows (compliant/noncompliant)、Entra joine Windows (compliant)、Entra registered iPad (compliant) で検証しました。	ホーム テナントから支給された or BYOD 想定のデバイスを使います。
3	多要素認証方法	Microsoft Authenticator	リソース テナントのテナント間アクセス設定にて他テナントの多要素認証を信頼する場合、ユーザーはホーム テナントに登録した認証方法で多要素認証できます。
4	テナント間アクセス設定	テナント既定値	ホームにあたるテナントのテナント間アクセス設定は既定値で大丈夫です。既定値から変更が加えられゲスト招待をブロックしている場合などは、穴あけが必要です。

今回検証では既存テナントの既存ユーザー＋既存デバイスを使いました。
このテナントのライセンス要件は、MFA 利用と Intune 利用に足るものがあれば OK です。
なお当検証環境はDeveloper subscription のため Entra ID P1 と Intune P1 がついています。
(参考： Features and licenses for Microsoft Entra multifactor authentication - Feature comparison based on licenses)

リソース テナント

ゲスト招待されたユーザーがアクセスする先となる、リソースが存在するテナントです。

• 表示名： MSSVC Dev

#	準備物	構成	補足
1	Teams チーム	協業者アカウント (Jane) をプロジェクトのチームにゲスト招待	これの準備は任意です。今回は適当なリソースの例として、Teamsでプライベートチャネルを作成し、外部のユーザーをゲスト招待しました。
2	テナント間アクセス設定	受信アクセスの設定にて次を信頼：多要素認証、準拠済みデバイス、Hybrid joined デバイス	他テナントから受信する多要素認証やデバイス情報を信頼するよう構成します。(特定のテナントに対して設定、または既定の設定を更新してすべてのテナントに対して設定可能です)
3	多要素認証登録ポリシー (Entra ID P2)	ゲスト ユーザーには多要素登録を求めない	受信アクセスに他テナントの MFA を信頼する場合、登録ポリシーからゲスト ユーザーを除外することが推奨されています。
4	条件付きアクセス ポリシー	リソースへのアクセスに対する許可条件として次を構成：デバイス状態 (Case 1~3), MFA (Case 4)	テナント間アクセス設定により受信できるようになった情報を反映して、ゲストに適用されるアクセスポリシーを更新します。

なお、今回テナント間アクセス設定を利用する前提として、受信アクセスの信頼を構成するリソース テナント上に Entra ID P1 ライセンスが必要です。
その他構築作業に必要な最小権限も以下公開情報に記載があります：

• 参考：Overview: Cross-tenant access with Microsoft Entra External ID - Important considerations

ホーム テナント構成

0. Company Branding

今回 2つのテナントを利用するため、分かりやすいようサインイン画面の背景色を設定しました。
ホーム テナント側は以下の設定にしています。

• ページの背景色： #6785c1
  
  

1. ユーザー

このユーザーを使います。

2. デバイス

今回は以下の 4種類の登録状態のデバイスを用意しました。
ただし、リソース テナントの条件付きアクセス ポリシー (CA ポリシー) の構成上、プラットフォームおよびEntra register / join は区別しないため、2., 3., 4. は同じ挙動となりました。

1. 未登録デバイス:
   ホーム テナント管理外にあるデバイス。準拠状態を取得できない。
2. Entra registerred Windows：
   2a. Entra registerred Windows (準拠済み)
   2b. Entra registerred Windows (準拠していない)
   準拠/非準拠それぞれの場合で挙動を見るため、Intuneにて準拠状態をコントロールしてテストを実施。(非準拠にしたい場合は、デバイスがクリアできない要件をコンプライアンスポリシーに設定する)
3. Entra joine Windows (準拠済み)
   複数台で挙動確認できるよう用意。今回リソース テナントの CA ポリシーにてデバイス フィルターを使っていない (Entra register/join を区別できない) ため、2. のデバイスと同じ挙動となった。
4. Entra registered iPad (準拠済み)
   モバイルで挙動確認できるよう用意。今回リソース テナントの CA ポリシーにてゲストの端末はどのプラットフォームでも同じフローとしているため、2. のデバイスと同じ挙動となった。

3. 多要素認証方法

多要素認証は、ユーザーのホーム テナント側で Microsoft Authenticator アプリを登録しました。

4. テナント間アクセス設定

ホームにあたるテナントのテナント間アクセス設定は既定値で大丈夫です。

既定値から変更が加えられゲスト招待をブロックしている場合などは、穴あけが必要です。

以下、検証時のホーム テナントの設定値 (= テナント既定値) です。

組織の設定 (テナント既定値)

• 参考：Configure cross-tenant access settings for B2B collaboration - Add an organization
  

既定の設定 (テナント既定値)

• 参考：Configure cross-tenant access settings for B2B collaboration - Configure default settings
  

Microsoft クラウド設定 (テナント既定値)

• 参考：Configure Microsoft cloud settings for B2B collaboration
  

リソース テナント構成

0. Company Branding

検証でテナントを 2つ使うため、区別のためにサインイン画面の背景色を設定しました。
リソース テナント側は以下の設定にしています。

• ページの背景色： #e866d9
  
  

1. Teams チーム

適当なリソースとして、Teams 上にプライベート チームを作成し、外部ユーザーを招待しました。

2. テナント間アクセス設定

他テナントから受信する多要素認証やデバイス情報を信頼するよう、受信アクセスを設定します。
今回検証では、信頼したい他テナントが特定できるので、スモール スタートすることにし、「既定の設定」自体は変更せず「組織の設定」を上にかぶせる方法を採用しました。

なお、「既定の設定」と「Microsoft クラウドの設定」はテナント既定値のまま使っています。

組織の設定

• 参考：Configure cross-tenant access settings for B2B collaboration - Add an organization

ホーム テナントのドメイン名またはテナント ID を入力し、組織を追加します。

受信アクセスは既定値を継承せず、この組織に対する設定を構成します。

「信頼の設定」タブにて、設定をカスタマイズします。

構成完了

既定の設定 (テナント既定値)

• 参考：Configure cross-tenant access settings for B2B collaboration - Configure default settings
  

Microsoft クラウド設定 (テナント既定値)

• 参考：Configure Microsoft cloud settings for B2B collaboration
  

3. 多要素認証登録ポリシー

• 参考：How To: Configure the multifactor authentication registration policy

多要素認証登録ポリシーは、Identity Protection の機能であり、Entra ID P2 ライセンスで利用可能です。(Entra ID Free や P1 では提供されていない。)
(参考：What is Identity Protection? - License requirements)

私が持っている P2 テナントではテナント既定状態で多要素認証登録ポリシーが無効の状態でしたが、もしこれが有効の場合、かつ 受信アクセス設定で他テナントのMFAを信頼する構成とする場合、正常動作のため多要素認証登録ポリシーの対象からゲスト ユーザーを除外することが推奨されています。

We recommend excluding external users from the Identity Protection MFA registration policy, if you are going to trust MFA for external users. When both policies are present, external users won’t be able to satisfy the requirements for access.

―― Overview: Cross-tenant access with Microsoft Entra External ID より

4. 条件付きアクセス ポリシー

• 参考：Conditional Access for external users

今回リソース テナントとして使ったテナントは、直前までセキュリティの既定値群が有効な状態で条件付きアクセスポリシーが存在していませんでした。
検証に際し、企業環境でよく使われていそうなポリシーをテンプレートから実装しました。(テンプレートから作成後、一部設定変更)

• 利用したテンプレート：
  1. Block access for unknown or unsupported device platform
     (不明なまたはサポートされていないデバイス プラットフォームのアクセスをブロックする)
  2. Block legacy authentication
     (レガシ認証をブロックする)
  3. Require multifactor authentication for admins
     (管理者に多要素認証を要求する)
  4. Require multifactor authentication for guest access ★
     (ゲスト アクセスに多要素認証を要求する)
  5. Require approved client apps or app protection policies ★
     (承認されたクライアント アプリまたはアプリ保護ポリシーが必要)
  6. Require compliant or hybrid Azure AD joined device or multifactor authentication for all users
     (準拠していること、Hybrid Azure AD Join を使用したデバイス、または多要素認証をすべてのユーザーに要求する)

上記 #4, 5, 6 については、テナント間アクセス検証にあたり、テンプレートから作成後さらに値を更新しました。

テンプレートから作成する CA ポリシーは、対象ユーザーが「すべてのユーザー」で除外ユーザーが作業アカウントのため、ゲスト ユーザー含むリソース テナント上のすべてのユーザーが対象になります。

ゲスト ユーザーに対するアクセスポリシー、特に受信アクセス設定を構成した組織をホームにするゲストユーザーに対するアクセスポリシーを分岐させたい場合、編集が必要になります。

当テナントでは、デバイス状態を条件にアクセス制御を実施する (記事冒頭の動作例でいう Case 1~3 を実証する) ため、ゲストユーザーにMFAを求める #4 の CA ポリシーと、すべてのユーザーにアプリ保護ポリシーを求める #5 の CA ポリシーを編集しました。
また、#6 のを編集してデバイス条件を求めるポリシーにしています。

#4 Require multifactor authentication for guest access 編集

• BEFORE
  • テンプレートから作成したままの状態・・・対象外 (除外ユーザー) = 作業アカウント
    
• AFTER
  受信アクセス設定を構成した組織は、ゲスト ユーザーのホーム テナントに登録されたデバイスの準拠状態に応じてアクセスを許可する方針とし、MFA の対象外にします。
  
  

なお、「ゲストのホーム テナントのデバイス準拠判定は信じないが、MFA は信じる」という方針の場合は、本#4 ポリシーは編集せず、#6 のデバイス条件を求める CA ポリシーの対象外としてすべてのゲスト ユーザーを設定します。(下 #5 参考)

#5 Require approved client apps or app protection policies 編集

• BEFORE

  • テンプレートから作成したままの状態・・・対象外 (除外ユーザー) = 作業アカウント
    

• AFTER

  • 対象外 = すべての種類の「ゲストまたは外部ユーザー」
    

アプリ保護ポリシーは 2024年 6月現在 1テナントでのみ利用可能であり、リソース テナントから保護を適用することができません。
(OutlookやTeamsなど複数プロファイルサポートするアプリでも、現状複数のテナントからアプリ保護ポリシーを適用することはサポートしておらず、技術上実現できない)

受信アクセス設定上も「アプリ保護」情報を共有する項目が存在せず、外部ユーザーに対するアプリベースの許可条件 (Grant controls - Require approved client app / Require app protection policy) は B2B コラボレーション ユーザー/ B2B 直接接続ユーザーいずれもサポート外となっています。
(参考：Authentication and Conditional Access for External ID - Comparing External ID Conditional Access policies)

このため、ゲスト ユーザーに対するアプリ保護ポリシー要求は実施しない方針とします。
対象外として、すべての種類の「ゲストまたは外部ユーザー」を選択し、保存しました。

これにより、iPad 上の Teams アプリ (リソース テナントの保護が適用されていないアプリ) からもゲストユーザーがアクセスできるようになりました。

先日 M365roadmap に Intune の "Multiple Managed Accounts" が追加されましたが、これがリリースされると 「ひとつの端末で複数テナントのアプリ保護が適用できるようになるのでは？」 という噂があります。
もし噂通りの機能であれば、将来的 (2025年以降) にゲストユーザーに対してアプリ保護ポリシーありきで設計できるようになる可能性がありそうです。
楽しみですね！

Microsoft Intune: Multiple managed accounts

• Rollout Start: January 2025

Allows people to use a single device with multiple company accounts to access company information through specific managed applications.

• Feature ID: 109560
• Added to roadmap: 2/10/2023
• Last modified: 5/15/2024
• Product(s): Microsoft Intune
• Cloud instance(s): Worldwide (Standard Multi-Tenant)
• Platform(s): iOS
• Release phase(s): General Availability

Microsoft 365 roadmap

#6. Require compliant or hybrid Azure AD joined device or multifactor authentication for all users 編集

• BEFORE
  • テンプレートから作成したままの状態・・・許可条件：準拠デバイス or hybrid joined デバイス or MFA
• AFTER
  • 許可条件：準拠デバイス or hybrid joined デバイス
    許可条件から MFA を削除

ゲスト含め、一般ユーザーはデバイス条件を必須にしています。

Case 4 の検証は、このポリシーはそのままに、#4 のポリシーの対象に該当テナントも入れて MFA とデバイスのどちらのポリシーも適用される AND 条件状態で実施しました。

テナント側の設定は以上です。

ご参考：Workbook を使ってテナント間アクセス現状を可視化できるらしい

今回検証にあたりテナント側に設定を実装してみて、リソース テナント側の受信アクセス設定と条件付きアクセス (CA) ポリシー設定が設計の肝であると感じました。

AS-IS / TO-BE の認証フローはもちろん、テナント間アクセスの状況は組織によって様々なはずで、テナント間アクセス導入にあたり 設定の見直しは各組織の状況を加味して実施する必要がある と思いました。

各組織の状況を可視化する方法として、Entra ID と Log Analytics を統合 (接続) すると、"Cross-tenant access workbook" というレポート機能が使えるようになるそうです。

当検証環境では Log Analytics 用意できないので公開情報の写真を借りて下に掲載しますが、テナント間アクセスの現状として 受信/送信 双方向の他テナント ID を見れたり、認証エラーがあれば原因をグラフで見れたりするようです。

The External Tenant list shows all the tenants that have had inbound or outbound activity with your tenant. When you select an external tenant in the table, the sections after the table display information about outbound and inbound activity for that tenant.

Cross-tenant access workbook より

本番環境の手入れで一番怖いのが意図せぬブロックで業務を阻害してしまうことなので、Workbook を使って現状把握した上で作戦を練り、さらに CAポリシー改修が必要ならレポート専用から展開すると最悪の事態は避けられそうです！

さいごに

通常、ゲスト招待されたテナントのリソースへのアクセスに MFA が必要な場合、リソース テナント側で作成されたゲストアカウントに紐づけて Authenticator の登録・認証が必要です。

その点、Enternal ID のテナント間アクセス構成があるとホーム テナント側のMFAクレームがリソース テナントでも使えるので、リソース テナント側でMFAの登録・認証が不要となり、便利だと感じました。

ゲスト ユーザーのホーム テナントのコンプライアンスポリシーを信頼できるなら、デバイス条件 を使うこともでき、これでもシームレスなアクセスを実現できます。

とはいえ、デバイス状態を信頼する場合、それは他テナントのコンプライアンスポリシーを信頼するということであり、他テナントのコンプライアンス水準が自テナント (リソース テナント) のコンプライアンス/セキュリティ水準に準ずるものなのか (他テナントの準拠デバイスを信頼することがセキュリティホールにならないか) 考慮する必要があるかと思いました。

この点、本当にとなりのテナントのデバイスが青い (あのテナントのコンプライアンス設計は素晴らしい！) 場合に実施すべき、と言えそうです。

テナント毎の考慮点はあります (そのために workbook もある) が、全体として、他のテナントと信頼を構成してシームレスな認証を実現できる点、なかなか life changing な機能だと思います。

快適認証ライフ目指していきましょう☆