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

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

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

https://techcommunity.microsoft.com/t5/microsoft-entra-blog/announcing-general-availability-of-microsoft-entra-external-id/ba-p/3974961

https://jpazureid.github.io/blog/azure-active-directory/announcing-general-availability-of-microsoft-entra-external-id/

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

:::note
本記事のカバー範囲は以下です：
- **テナント間アクセスの認証フロー**
- **動作例**：未登録デバイス、準拠済みデバイス、非準拠デバイス、MFA
- **構成例**：ホームテナント、リソーステナント
- **ご参考**：Workbook を使ってテナント間アクセス現状を可視化できるらしい
:::

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

# テナント間アクセスの認証フロー
早速気になる認証フローですが、すでに**素敵フロー図が公開情報にありました**。
私が拙い画力を発動させるよりも分かりやすいので、素直に転載します。
- **参考：** [Authentication flow for external Microsoft Entra users](https://learn.microsoft.com/en-us/entra/external-id/authentication-conditional-access#authentication-flow-for-external-microsoft-entra-users)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/c58ade9a-6dc7-08f4-137d-c6c94ac0c5c4.png "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 チャレンジ**を発行する。<font color = 'green'>Fabrikam で MFA 要求が満たされた場合、ユーザーは Contoso のリソースへのアクセスを**許可**される。</font> <font color = 'red'>要求を満たさない場合、アクセスは**ブロック**される。</font>   |
|5-b   |CA ポリシーがデバイス要件を要求 - チャレンジ  |デバイス要件があるが**満たされない場合**、Entra ID はユーザーの**ホーム テナントでデバイス チャレンジ**を発行する。<font color = 'green'>Fabrikam で デバイス要件が満たされている場合、ユーザーは Contoso のリソースへのアクセスを**許可**される。</font> <font color = 'red'>要件を満たさない場合、アクセスは**ブロック**される。</font>   |
|6-a   |CA ポリシーが MFA を要求 (信頼設定が無い場合)  |**【信頼設定が構成されていない場合】**　MFA が必要な場合、B2B コラボレーション ユーザーは MFA を要求される (**リソース テナントで MFA を満たす**必要がある)。 **B2B 直接接続ユーザーのアクセスはブロック**される。 |
|6-b   |CA ポリシーがデバイス要件を要求 (信頼設定が無い場合)    |**【信頼設定が構成されていない場合】** デバイスの要件があるが**評価できない**場合、B2B コラボレーションと B2B 直接接続の両方の**ユーザーのアクセスがブロックされる**。   |

:::note
上表の「説明」列の記載は、公開情報をもとに一部分かりやすいよう編集しました。
- **参考にした公開情報：** [Authentication flow for external Microsoft Entra users](https://learn.microsoft.com/en-us/entra/external-id/authentication-conditional-access#authentication-flow-for-external-microsoft-entra-users)
:::

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

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

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

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

## Case 1: ユーザーがホーム テナント未登録デバイスより、リソース テナントにアクセスする
- **結果： <font color="red">アクセス ブロック</font>**

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

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

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

### Case 1 ユーザー側画面
リソース テナントからのゲスト招待リンクを踏んで Teams へのサインインを試行します。
![case 1 - teams invitation.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/84c0fdc3-6da4-9cb7-abcb-cb968e4c48eb.png)

サインインはできましたが、リソースへのアクセスがブロックされました。
![スクリーンショット2024-06-05-153027 - コピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/10c1669d-18bf-8494-f195-04e4567aab53.png)
> **申し訳ございません。まだここにはアクセスできません**
この組織の保護されているリソースに外部ユーザーとしてアクセスしようとしているため、この操作を完了できません。管理者に連絡して、保護されたリソースにアクセスできるようにしてください。

ちなみに英語の場合は以下の文言になります。
![case 1 - unmanaged device (block) - コピー.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/db17ec79-27ef-5ac3-fb1b-1ebf135bebce.png)
>**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 サインイン ログ
**リソース テナント側**でゲスト ユーザーのサインイン ログを確認することができます。
![case 1 - unmanaged device - log1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/ab78bcb8-bec9-4e2d-63a1-13263954dfb9.png)
リソース テナント側で受信アクセス設定が**実際に構成されている/されていないにかかわらず**、このケースのサインインログにはエラー原因としてこの文言がありました。(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** も載っているため、受信アクセス制限の構成に心配がある場合は**これらをクルーとしてトラブルシュートできそう**です。

![case 1 - unmanaged device - log2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/6b49ea95-25eb-7c82-6009-42c681e81e90.png)
![case 1 - unmanaged device - log3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/fddca677-3fdd-0aeb-b124-79b0e70079ee.png)

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

## Case 2: ユーザーがホーム テナント登録済みデバイス (準拠済み) より、リソース テナントにアクセスする
- **結果： <font color="green">アクセス許可</font>**

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

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

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

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

### Case 2 ユーザー側画面
Teams Web Client (ブラウザ上のTeams) の画面です。**ゲスト招待された MSSVC Dev テナントにサインイン**できています。
![case 2 - compliant device.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/9e2a13a6-feb6-a6d1-08ef-8a261a8544fd.png)
投稿もできました。
![case 2 - compliant device 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/9df50996-c732-eb48-17ad-bb62378b8a1f.png)

### Case 2 サインイン ログ
リソース テナント側でゲスト ユーザーのサインインログを確認すると、デバイスが **「マネージド」かつ「準拠している：はい」と認識されている** ことが分かります。
(ただし、ゲストのホーム テナントのデバイスIDは取得できない模様。)
![case 2 - compliant device - log1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/b3883819-c063-54a9-a85c-f46ef6643314.png)
![case 2 - compliant device - log.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/7ece0278-0776-4427-4995-b79aaad26700.png)

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

## Case 3: ユーザーがホーム テナント登録済みデバイス (非準拠) より、リソース テナントにアクセスする
- **結果： <font color="red">アクセス ブロック</font>**

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

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

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

### Case 3 ユーザー側画面
すでにリソースにサインインしている状態で、アクセス元の**デバイスの準拠状態**を「準拠している」から **「準拠していない」に推移** させたところ、ユーザー側ではゲスト招待された先のリソース テナントに**再度サインインを求める「! (黄色い三角アイコン)」が表示**されました。
![case 3 - noncompliant device (block) 1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/a7eb862d-765c-7573-c27f-4d4c90890d19.png)
「! (黄色い三角アイコン)」をクリックしたところ、サインインはできているものの**デバイスのコンプライアンス要件によりアクセスがブロック**されました。
![case 3 - noncompliant device (block) 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/0d2ae7a7-9348-2724-67c6-e33f136b08db.png)
>**デバイスは組織のコンプライアンス要件に準拠している必要があります**
このデバイスは、組織のコンプライアンス要件を満たしていません。組織のデバイス管理ポータルに移動して、このデバイスが非準拠とマークされている理由を確認してください。

### Case 3 サインイン ログ
リソース テナント側でゲスト ユーザーのサインインログを確認すると、デバイスが **「マネージド」だが「準拠している：いいえ (準拠していない)」と認識されている** ことが分かります。
![case 3 - noncompliant device - log1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/ffdefbeb-6e9d-b740-6b36-3c0fd3646088.png)
エラーの理由欄にも、「**条件付きアクセスポリシーにて準拠済みデバイスが求められている**が、**デバイスが準拠していない**」ことが説明されています。
>Device is not in required device state: {state}. **Conditional Access policy requires a compliant device, and the device is not compliant.**

![case 3 - noncompliant device - log2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/ed7ecd8b-4bb4-0e63-9fa4-21111d1c519b.png)

![case 3 - noncompliant device - log4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/f0014144-ee21-f4c8-b428-2e4e05c37a36.png)

![case 3 - noncompliant device - log5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/569e8216-2f5f-7bac-4297-551b8def779a.png)

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

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

## Case 4: ユーザーが MFA を実施し、リソース テナントにアクセスする
- **結果： <font color="green">アクセス許可</font>**

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

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

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

### Case 4 ユーザー側画面
せっかくなので新Teams クライアントで動作確認しました。
ユーザーは、Teams アプリを起動して **「別のアカウントを追加」** をクリックします。
![case 4 - MFA 1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/0d5f85e5-e7da-1de7-9763-042422b78121.png)
認証ウィンドウが開くので、ホーム テナントのユーザー ID を入力します。
![case 4 - MFA 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/cb23899c-61c5-520b-c328-c065c03faa89.png)
多要素認証を求められるので、**ホーム テナントのユーザー ID と紐づけ**たモバイルの Authenticator アプリで認証します。
![case 4 - MFA 3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/1a38d9d0-a63a-58a6-7910-d7686b019bf1.png)
アクセスできました。(最近の Teams は別窓で別テナントの画面を出してくれるようです。)
![case 4 - MFA 4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/1ad5eb71-c4da-7f88-fcd7-2716442211c6.png)
以降 Teams アプリを開くと、自テナント (ホーム テナント) とゲスト招待されたリソース テナントの切り替えができるようになります。
![case 4 - MFA 5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/47a571cb-38c8-91cc-268b-d712864c64ff.png)
リソース テナントを開いた様子 ↓
![case 4 - MFA 6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/a79b48cb-9481-7ccb-5f3f-4cc3e626035b.png)

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

ホーム テナント側に MFA セッション トークンが残っている場合は、リソース テナントアクセスに際し ノー プロンプトでシームレスにアクセスすることができるそうです。
(**参考**：[Collaborate more securely with new cross-tenant access settings](https://techcommunity.microsoft.com/t5/microsoft-entra-blog/collaborate-more-securely-with-new-cross-tenant-access-settings/ba-p/2147077))

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

### Case 4 サインイン ログ
リソース テナント側でゲスト ユーザーのサインインログを確認すると、**MFA 要求が満たされた**ことにより**アクセス許可**されていることが分かります。
![case 4 - MFA - log1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/c7cc0a96-3aec-b851-f21e-c817856e8c3d.png)
![case 4 - MFA - log2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/9a9c3754-721d-0760-e9e4-b85562fc3415.png)
![case 4 - MFA - log3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/b86b53c4-e275-1c7e-f152-6272b96a7566.png)

受信信頼設定が構成されている場合、**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](https://learn.microsoft.com/en-us/entra/identity/authentication/concept-mfa-licensing#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)   | テナント間アクセス設定により受信できるようになった情報を反映して、**ゲストに適用されるアクセスポリシーを更新**します。   |

:::note
なお、今回テナント間アクセス設定を利用する前提として、受信アクセスの信頼を構成する**リソース テナント上に Entra ID P1 ライセンス**が必要です。
その他構築作業に必要な最小権限も以下公開情報に記載があります：
- **参考**：[Overview: Cross-tenant access with Microsoft Entra External ID - Important considerations](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-overview#important-considerations)
:::

# ホーム テナント構成 
## 0. Company Branding
今回 2つのテナントを利用するため、分かりやすいよう**サインイン画面の背景色**を設定しました。
ホーム テナント側は以下の設定にしています。
- **ページの背景色：** #6785c1
![mssvclab - CompanyBranding.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/3fdd5017-69df-3323-1958-f47a30078b37.png)
![#6785c1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/15261fa0-068a-6b16-cb4c-3b3d9b7fab76.png "#6785c1")

## 1. ユーザー
このユーザーを使います。
![mssvclab - user.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/da68b9f8-c5c8-4d19-29cd-524b318219db.png)

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

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

![mssvclab - device.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/e6360b9d-a7a0-b6fb-fbdf-814366e15ea5.png)

![mssvclab - device 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/cc0d5a01-addf-5400-1330-7fbc406c266c.png)

## 3. 多要素認証方法
多要素認証は、ユーザーの**ホーム テナント側**で Microsoft Authenticator アプリを登録しました。
![mssvclab - my-signins.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/d2753f35-6cdd-34ad-88e1-e700fcabdb5a.png)

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

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

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

### 組織の設定 (テナント既定値)
- **参考**：[Configure cross-tenant access settings for B2B collaboration - Add an organization](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration#add-an-organization)
![mssvclab - ExID 1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/a1feb57a-3445-895f-d5a5-1a8503ef7a1b.png)

### 既定の設定 (テナント既定値)
- **参考**：[Configure cross-tenant access settings for B2B collaboration - Configure default settings](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration#configure-default-settings)
![mssvclab - ExID 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/d832d2e9-dc9f-bc8e-1532-5d5876da374a.png)

### Microsoft クラウド設定 (テナント既定値)
- **参考**：[Configure Microsoft cloud settings for B2B collaboration](https://learn.microsoft.com/en-us/entra/external-id/cross-cloud-settings)
![mssvclab - ExID 3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/34e62bb8-a898-76d2-9efc-dc229cf09dc1.png)

# リソース テナント構成 
## 0. Company Branding
検証でテナントを 2つ使うため、区別のために**サインイン画面の背景色**を設定しました。
リソース テナント側は以下の設定にしています。
- **ページの背景色：** #e866d9
![mssvcdev - CompanyBranding.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/994e4a89-44ff-6bc8-4e85-5acee09fb91a.png)
![#e866d9.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/37fd1cea-6cb4-0aa2-290b-0d070e4bd290.png "#e866d9")

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

![mssvcdev - Teams 1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/2d5dee19-8d5c-c68d-7691-8a278e74e197.png)
![mssvcdev - Teams 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/9d04f95a-7a4b-0803-da7a-523595181178.png)
![mssvcdev - Teams 3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/e78c2684-1394-be25-be48-946fed1ff24e.png)
![mssvcdev - Teams 4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/c7f6b9c4-37b0-6ab0-c7c9-17a2b03d8620.png)
![mssvcdev - Teams 5.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/d3a30b5c-35eb-a4c1-57cc-af04133c27c9.png)

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

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

### 組織の設定
- **参考**：[Configure cross-tenant access settings for B2B collaboration - Add an organization](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration#add-an-organization)

ホーム テナントのドメイン名またはテナント ID を入力し、組織を追加します。
![mssvcdev - ExID 1-1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/a8458177-e00d-8039-59c7-912921eb13e5.png)
受信アクセスは既定値を継承せず、この組織に対する設定を構成します。
![mssvcdev - ExID 1-2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/273fbd59-e8b1-f3df-95e4-8acbe5fa4435.png)
「信頼の設定」タブにて、設定をカスタマイズします。
![mssvcdev - ExID 1-3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/becb4eeb-fb95-f467-2a23-63cdf1024c91.png)
構成完了
![mssvcdev - ExID 1-4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/6c94f26a-3183-9d97-89f8-547ed677f3da.png)


### 既定の設定 (テナント既定値)
- **参考**：[Configure cross-tenant access settings for B2B collaboration - Configure default settings](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-settings-b2b-collaboration#configure-default-settings)
![mssvcdev - ExID 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/c8d179aa-e136-1f56-ffbc-c665efdb034a.png)


### Microsoft クラウド設定 (テナント既定値)
- **参考**：[Configure Microsoft cloud settings for B2B collaboration](https://learn.microsoft.com/en-us/entra/external-id/cross-cloud-settings)
![mssvcdev - ExID 3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/2a5d741e-077b-4e77-2280-b93b410ea7eb.png)


## 3. 多要素認証登録ポリシー
- **参考**：[How To: Configure the multifactor authentication registration policy](https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-mfa-policy)

多要素認証登録ポリシーは、Identity Protection の機能であり、Entra ID P2 ライセンスで利用可能です。(Entra ID Free や P1 では提供されていない。)
(**参考**：[What is Identity Protection? - License requirements](https://learn.microsoft.com/en-us/entra/id-protection/overview-identity-protection#license-requirements))

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

> We recommend excluding external users from the [Identity Protection MFA registration policy](https://learn.microsoft.com/en-us/entra/id-protection/howto-identity-protection-configure-mfa-policy), if you are going to [trust MFA for external users](https://learn.microsoft.com/en-us/entra/external-id/authentication-conditional-access#mfa-for-azure-ad-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](https://learn.microsoft.com/en-us/entra/external-id/cross-tenant-access-overview#organizational-settings)* より

![MFAreg-policy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/d156c635-4565-9a9d-b660-61f4253e941b.png)


## 4. 条件付きアクセス ポリシー
- **参考**：[Conditional Access for external users](https://learn.microsoft.com/en-us/entra/external-id/authentication-conditional-access#conditional-access-for-external-users)
 
今回リソース テナントとして使ったテナントは、直前までセキュリティの既定値群が有効な状態で条件付きアクセスポリシーが存在していませんでした。
検証に際し、企業環境で**よく使われていそうなポリシーをテンプレートから実装**しました。(テンプレートから作成後、一部設定変更)

![mssvcdev - CApolicy.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/2517355b-98b8-8e92-3e72-79f4a5d06ee4.png)

- **利用したテンプレート：**
  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** については、テナント間アクセス検証にあたり、テンプレートから作成後さらに**値を更新**しました。

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

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

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

### #4 Require multifactor authentication for guest access 編集
- **BEFORE**
  - テンプレートから作成したままの状態・・・対象外 (除外ユーザー) = 作業アカウント
![mssvcdev - CApolicy #4 update 1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/037156ea-a454-20a4-5e1e-908a335f2513.png)
- **AFTER**
**受信アクセス設定を構成した組織**は、ゲスト ユーザーのホーム テナントに登録されたデバイスの準拠状態に応じてアクセスを許可する方針とし、**MFA の対象外**にします。
![mssvcdev - CApolicy #4 update 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/96961825-c7cd-50b1-567f-f25f09a3846e.png)
![mssvcdev - CApolicy #4 update 3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/d7208c25-c8ca-2b4a-80b8-4ca7b0b12453.png)

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

### #5 Require approved client apps or app protection policies 編集
- **BEFORE**
  - テンプレートから作成したままの状態・・・対象外 (除外ユーザー) = 作業アカウント
![mssvcdev - CApolicy #5 update 1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/2a32576a-253e-b425-f4a1-74a846affc25.png)

- **AFTER**
  - 対象外 = すべての種類の「ゲストまたは外部ユーザー」
![mssvcdev - CApolicy #5 update 2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/551091ef-9020-4201-8cba-88114549767f.png)

**アプリ保護ポリシー**は 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](https://learn.microsoft.com/en-us/entra/external-id/authentication-conditional-access#comparing-external-id-conditional-access-policies))

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


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

:::note
先日 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](https://www.microsoft.com/en-in/microsoft-365/roadmap?filters=Microsoft%20Intune&searchterms=109560)*

:::

### #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 を削除

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

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

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

# ご参考：Workbook を使ってテナント間アクセス現状を可視化できるらしい
今回検証にあたりテナント側に設定を実装してみて、リソース テナント側の受信アクセス設定と条件付きアクセス (CA) ポリシー設定が設計の肝であると感じました。

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

各組織の**状況を可視化する**方法として、Entra ID と Log Analytics を統合 (接続) すると、**"[Cross-tenant access workbook](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/workbook-cross-tenant-access-activity)" というレポート機能**が使えるようになるそうです。

当検証環境では 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.
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3659465/279f7ef3-cd69-f6db-51eb-7bc473ac2058.png)
>
>*[Cross-tenant access workbook](https://learn.microsoft.com/en-us/entra/identity/monitoring-health/workbook-cross-tenant-access-activity) より*

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

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

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

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

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

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

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

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