マルチテナント ユーザー管理に関する一般的な考慮事項

この記事は、Microsoft Entra マルチテナント環境でユーザー ライフサイクル管理を構成、提供するためのガイダンスを提供するシリーズ記事の第 3 回目です。 シリーズ記事の次回以降は、下記のとおり、さらに詳しい情報について説明します。

• このシリーズ記事の第 1 回目の「マルチテナント ユーザー管理の概要」では、Microsoft Entra マルチテナント環境でユーザー ライフサイクル管理を構成、提供するためのガイダンスを提供しています。
• 「マルチテナント ユーザー管理のシナリオ」では、マルチテナント ユーザー管理機能を使用できる 3 つのシナリオ (エンド ユーザーによる実施、スクリプト化、自動化) について説明します。
• マルチテナント ユーザー管理の一般的なソリューション (シングル テナントでは要件を満たせない場合): テナント間での自動ユーザー ライフサイクル管理とリソース割り当て、テナント間でのオンプレミス アプリ共有、といった課題のガイダンスを説明します。

このガイダンスは、ユーザー ライフサイクル管理で整合性のとれた状態を実現するのに役立ちます。 ライフサイクル管理には、Microsoft Entra B2B コラボレーション (B2B) やテナント間同期を含む使用可能な Azure ツールを用いた、テナント間のユーザー プロビジョニング、ユーザー管理、ユーザー プロビジョニング解除が含まれます。

同期要件は、組織固有のニーズに応じて異なります。 組織の要件を満たすソリューションを設計する際には、この記事にある次の考慮事項が最適なオプションの特定に役立ちます。

• テナント間同期
• ディレクトリ オブジェクト
• Microsoft Entra 条件付きアクセス
• 追加のアクセス制御
• Office 365

テナント間同期

テナント間同期を使用すると、マルチテナント組織が直面するコラボレーションとアクセスの課題に対処できます。 次の表は、一般的な同期のユース ケースを示しています。 考慮事項が複数のコラボレーション パターンに関連する場合は、テナント間同期とカスタム開発の両方を使用してユース ケースを満たすことができます。

使用事例	テナント間同期	カスタム開発
ユーザー ライフサイクル管理
ファイル共有とアプリ アクセス
ソブリン クラウドとの間の同期のサポート
リソース テナントからの同期の制御
グループ オブジェクトの同期
同期マネージャーのリンク
属性レベルの権限ソース
Microsoft Entra による Microsoft Windows Server Active Directory への書き戻し

ディレクトリ オブジェクトに関する考慮事項

外部ユーザーの招待に使用する UPN と SMTP アドレス

Microsoft Entra B2B では、ユーザーの UserPrincipalName (UPN) と、招待を送信するためのプライマリ簡易メール転送プロトコル SMTP (メール) アドレスが一致することを想定しています。 ユーザーの UPN がプライマリ SMTP アドレスと同じ場合、B2B は想定どおりに動作します。 ただし、UPN が外部ユーザーのプライマリ SMTP アドレスと異なる場合、ユーザーが招待を受け入れたときに解決に失敗する場合があります。 ユーザーの実際の UPN がわからない場合、この問題は困難になる場合があります。 B2B の招待を送信するときには、UPN を確認して使用する必要があります。

この記事の「Microsoft Exchange Online」セクションで、外部ユーザーの既定のプライマリ SMTP を変更する方法について説明します。 この手法は、外部向けのすべてのメールと通知を、UPN ではなく実際のプライマリ SMTP アドレスに送信する場合に便利です。 メール フローで UPN がルーティング不可の場合は、この手法が必要になることがあります。

外部ユーザーの UserType の変換

コンソールを使用して外部ユーザー アカウントの招待を手動で作成する場合、ユーザーの種類がゲストに設定されたユーザー オブジェクトが作成されます。 他の手法で招待を作成すると、ユーザーの種類を外部ゲスト アカウント以外に設定できます。 たとえば、API を使用すると、アカウントを外部メンバー アカウントまたは外部ゲスト アカウントのどちらにするかを構成できます。

• ゲスト機能の制限の一部をなくすことができます。
• ゲスト アカウントを変換してユーザーの種類をメンバーにすることができます。

外部ゲスト ユーザーから外部メンバー ユーザー アカウントに変換する場合、Exchange Online による B2B アカウントの処理に問題が発生する可能性があります。 外部メンバー ユーザーとして招待したアカウントのメールを有効にすることはできません。 外部メンバー アカウントのメールを有効にするには、次の最適な方法を使用します。

• 組織間ユーザーを外部ゲスト ユーザー アカウントとして招待します。
• GAL でアカウントを示します。
• UserType を Member に設定します。

この方法を使用すると、アカウントは Exchange Online および Office 365 全体で MailUser オブジェクトとして表示されます。 また、タイミングの問題もあることに注意してください。 Microsoft Entra ユーザーの ShowInAddressList プロパティが Exchange Online PowerShell の HiddenFromAddressListsEnabled プロパティと整合している (互いに逆の値が設定されている) ことをチェックして、ユーザーが GAL に表示されることを確認します。 この記事の「Microsoft Exchange Online」セクションで、表示設定の変更について詳しく説明します。

メンバー ユーザーをゲスト ユーザーに変換できます。これは、内部ユーザーのアクセス許可をゲスト レベルのアクセス許可に制限する場合に役立ちます。 内部ゲスト ユーザーとは、組織の従業員ではないものの、そのユーザーと資格情報を管理するユーザーです。 この方法により、内部ゲスト ユーザーへのライセンス付与を回避できる場合があります。

外部ユーザーまたは外部メンバーの代わりにメール連絡先オブジェクトを使用する場合の問題

従来の GAL 同期を使用して、別のテナントのユーザーを表すことができます。 Microsoft Entra B2B Collaborationを使用するのではなく GAL 同期を行った場合、メール連絡先オブジェクトが作成されます。

• メール連絡先オブジェクトと、メールが有効な外部メンバーまたはゲスト ユーザーは、同じメール アドレスで同じテナントに同時に存在することはできません。
• 招待された外部ユーザーと同じメール アドレスを持つメール連絡先オブジェクトが存在する場合、外部ユーザーは作成されますが、メールは有効になりません。
• 同じメール アドレスを持つ、メールが有効な外部ユーザーが存在する場合、メール連絡先オブジェクトを作成しようとすると、作成時に例外がスローされます。

重要

メール連絡先を使用するには、アクティブ ディレクトリ サービス (AD DS) または Exchange Online PowerShell が必要です。 Microsoft Graph では、連絡先を管理するための API 呼び出しは提供されません。

次の表に、メール連絡先オブジェクトと外部ユーザーの状態の結果を示します。

既存の状態	プロビジョニング シナリオ	有効な結果
None	B2B メンバーを招待する	メールが有効でないメンバー ユーザー。 重要な注意をご覧ください。
なし	B2B ゲストを招待する	メールが有効な外部ユーザー。
メール連絡先オブジェクトが存在する	B2B メンバーを招待する	エラー。 プロキシ アドレスの競合。
メール連絡先オブジェクトが存在する	B2B ゲストを招待する	メール連絡先とメールが有効でない外部ユーザー。 重要な注意をご覧ください。
メールが有効な外部ゲスト ユーザー	メール連絡先オブジェクトを作成する	エラー
メールが有効な外部メンバー ユーザーが存在する	メール連絡先を作成する	Error

Microsoft では、(従来の GAL 同期ではなく) Microsoft Entra B2B コラボレーションを使用して、以下を作成することを推奨しています。

• GAL に表示できる外部ユーザー。
• 既定で GAL に表示されるが、メールは有効になっていない外部メンバー ユーザー。

メール連絡先オブジェクトを使用して GAL にユーザーを表示することもできます。 この方法では、メール連絡先はセキュリティ プリンシパルではないため、他のアクセス許可を付与せずに GAL を統合します。

この推奨アプローチに従って、次を行います。

• ゲスト ユーザーを招待する。
• GAL でゲスト ユーザーを再表示する。
• サインインからブロックしてゲスト ユーザーを無効にする。

メール連絡先オブジェクトをユーザー オブジェクトに変換することはできません。 そのため、メール連絡先オブジェクトに関連付けられているプロパティ (グループ メンバーシップやその他のリソース アクセスなど) は転送できません 。 メール連絡先オブジェクトを使用したユーザーの表示には、次の問題があります。

• Office 365 グループ。 Office 365 グループでは、グループのメンバーになり、グループに関連付けられているコンテンツを操作することが許可されるユーザーの種類を管理するポリシーがサポートされています。 たとえば、グループでゲスト ユーザーの参加が許可されない場合があります。 これらのポリシーでメール連絡先オブジェクトを管理することはできません。
• Microsoft Entra セルフサービス グループ管理 (SSGM)。 メール連絡先オブジェクトには、SSGM 機能を使用するグループのメンバーになる資格はありません。 ユーザー オブジェクトではなく連絡先として表される受信者を含むグループを管理するには、追加のツールが必要になる場合があります。
• Microsoft Entra ID ガバナンス、アクセス レビュー。 アクセス レビュー機能を使用して、Office 365 グループのメンバーシップを確認し、証明できます。 アクセス レビューは、ユーザー オブジェクトに基づいています。 メール連絡先オブジェクトで表されるメンバーは、アクセス レビューの対象外です。
• Microsoft Entra ID ガバナンス、エンタイトルメント管理 (EM)。 EM を使用して、会社の EM ポータルで外部ユーザーに対してセルフサービス アクセス要求を有効にすると、要求時にユーザー オブジェクトが作成されます。 メール連絡先オブジェクトはサポートされていません。

Microsoft Entra 条件付きアクセスの考慮事項

ユーザーのホーム テナントでのユーザー、デバイス、またはネットワークの状態は、リソース テナントに伝達されません。 そのため、外部ユーザーは、次の制御を使用する条件付きアクセス ポリシーを満たさない可能性があります。

許可されている場合は、テナント間アクセス設定 (CTAS) を使用してこの動作をオーバーライドできます。この設定では、ホーム テナントからの多要素認証とデバイスのコンプライアンスが適用されます。

• 多要素認証が必要。 CTAS が構成されていない場合、外部ユーザーは (ホーム テナントで多要素認証が満たされた場合でも) リソース テナントの多要素認証を登録するか、これに応答する必要があります。 このシナリオでは、複数の多要素認証の課題が発生します。 多要素認証証明をリセットする必要がある場合、テナント間の複数の多要素認証証明登録を認識していない可能性があります。 認識がないと、ユーザーはホーム テナントとリソース テナントの一方または両方の管理者に連絡することが必要な場合があります。
• 準拠としてマーク済みであるデバイスが必要。 CTAS が構成されていない場合、デバイス ID はリソース テナントに登録されていないため、外部ユーザーはこの制御を必要とするリソースにアクセスできません。
• Microsoft Entra ハイブリッド参加済みデバイスが必要です。 CTAS が構成されていない場合、デバイス ID はリソース テナント (またはリソース テナントに接続されているオンプレミスの Active Directory) に登録されていません。 そのため、外部ユーザーは、この制御を必要とするリソースにアクセスできません。
• 承認済みのクライアント アプリまたはアプリ保護ポリシーが必要。 CTAS が構成されていない場合、デバイスの登録も必要であるため、外部ユーザーはリソース テナントの Intune モバイル アプリケーション管理 (MAM) ポリシーを適用できません。 この制御を使用するリソース テナントの条件付きアクセス ポリシーでは、ホーム テナントの MAM 保護でポリシーを満たすことができません。 すべての MAM ベースの条件付きアクセス ポリシーから外部ユーザーを除外してください。

さらに、次の条件付きアクセスの条件も使用できますが、予期しない結果が生じる可能性があるので注意してください。

• サインイン リスクとユーザー リスク。 ホーム テナントでのユーザーの動作によって、サインイン リスクとユーザー リスクの一部が決まります。 ホーム テナントには、データとリスク スコアが格納されます。 リソース テナント ポリシーによって外部ユーザーがブロックされている場合、リソース テナント管理者はアクセスを有効にできない可能性があります。 「Microsoft Entra ID 保護 と B2B ユーザー」では、Microsoft Entra ID 保護 が Microsoft Entra ユーザーの資格情報の侵害を検出する仕組みについて説明しています。
• 場所。 リソース テナントのネームド ロケーションの定義によって、ポリシーのスコープが決まります。 ホーム テナントで管理されている信頼できる場所は、ポリシーのスコープで評価されません。 組織がテナント間で信頼できる場所を共有する場合は、リソースと条件付きアクセス ポリシーを定義する各テナントで場所を定義します。

マルチテナント環境のセキュリティ保護

マルチテナント環境をセキュリティで保護するには、まず、各テナントがセキュリティのベスト プラクティスに準拠していることを確認します。 テナントのセキュリティ保護に関するガイダンスについては、セキュリティ チェックリスト と ベスト プラクティス を確認してください。 これらのベスト プラクティスに従っていることを確認し、密接に連携しているテナントと共にそれを確認します。

管理者アカウントを保護し、最小限の権限を確保する

• 管理者の強力な認証範囲にギャップがないか見つけて対処する
• ユーザーとアプリケーションの両方の最小限の権限の原則を使用してセキュリティを強化します。 Microsoft Entra ID のタスク別の最小限の権限のロールを確認します。
• Privileged Identity Management を有効にして、永続的な管理者アクセスを最小限に抑えます。

マルチテナント環境を監視する

• 監査ログ UI、API、または Azure Monitor 統合 (プロアクティブ アラートの場合) を使用して、テナント間アクセス ポリシーの変更を監視します。 監査イベントでは、カテゴリ "CrossTenantAccessSettings" と "CrossTenantIdentitySyncSettings" が使用されます。これらのカテゴリの監査イベントを監視することで、テナント内のテナント間アクセス ポリシーの変更を特定し、アクションを実行できます。 Azure Monitor でアラートを作成するときに、次のようなクエリを作成して、テナント間アクセス ポリシーの変更を特定できます。

AuditLogs
| where Category contains "CrossTenant"

• テナント間アクセス設定に追加された新しいパートナーを監視します。

AuditLogs
| where OperationName == "Add a partner to cross-tenant access setting"
| where parse_json(tostring(TargetResources[0].modifiedProperties))[0].displayName == "tenantId"
| extend initiating_user=parse_json(tostring(InitiatedBy.user)).userPrincipalName
| extend source_ip=parse_json(tostring(InitiatedBy.user)).ipAddress
| extend target_tenant=parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue
| project TimeGenerated, OperationName,initiating_user,source_ip, AADTenantId,target_tenant
| project-rename source_tenant= AADTenantId

• 同期を許可または禁止するテナント間アクセス ポリシーの変更を監視します。

AuditLogs
| where OperationName == "Update a partner cross-tenant identity sync setting"
| extend a = tostring(TargetResources)
| where a contains "true"
| where parse_json(tostring(TargetResources[0].modifiedProperties))[0].newValue contains "true"

• テナント間アクセス アクティビティ ダッシュボードを使用して、テナント内のアプリケーション アクセスを監視します。 監視により、テナント内のリソースにアクセスしているユーザーと、そのユーザーのアクセス元を確認できます。

動的メンバーシップ グループ

既存の条件付きアクセス ポリシーですべてのユーザーの動的メンバーシップ グループ条件が組織で使用されている場合、外部ユーザーはすべてのユーザーのスコープ内にあるため、このポリシーは外部ユーザーに影響します。

既定では拒否します

• アプリケーションにユーザー割り当てを要求します。 アプリケーションで [ユーザーの割り当てが必要ですか] プロパティが [いいえ] に設定されている場合、外部ユーザーはアプリケーションにアクセスできます。 アプリケーション管理者は、特にアプリケーションに機密情報が含まれている場合、アクセス制御の影響を理解する必要があります。 「Microsoft Entra アプリを Microsoft Entra テナントの一連のユーザーに制限する」では、テナントの正常に認証されたすべてのユーザーが、テナントに登録されているアプリケーションをどうすれば使用できるかについて説明しています。 この設定は既定でオンになっています。

多層防御

条件付きアクセス。

• アクセス制御ポリシー を定義して、リソースへのアクセスを制御します。
• 外部ユーザーに留意して、条件付きアクセス ポリシーを設計します。
• 外部ユーザー専用のポリシーを作成します。
• 外部アカウント用に専用の条件付きアクセス ポリシーを作成します。 既存の条件付きアクセス ポリシーですべてのユーザーの動的メンバーシップ グループ条件が組織で使用されている場合、外部ユーザーはすべてのユーザーのスコープ内にあるため、このポリシーは外部ユーザーに影響します。

制限付き管理ユニット

セキュリティ グループを使用してテナント間同期の対象となるユーザーを制御する場合は、セキュリティ グループを変更できるユーザーを制限します。 テナント間同期ジョブに割り当てられているセキュリティ グループの所有者の数を最小限に抑え、そのグループを制限付き管理ユニットに含めます。 この場合、テナント間でグループ メンバーを追加または削除したり、アカウントをプロビジョニングしたりできるユーザーの数が制限されます。

アクセス制御に関するその他の考慮事項

利用条件

Microsoft Entra の使用条件により、組織でエンド ユーザーに情報を提示するために使うことができる簡単な方法が提供されます。 使用条件を使って、リソースにアクセスする前に使用条件に同意するよう外部ユーザーに要求できます。

Microsoft Entra ID P1 または P2 機能でのゲスト ユーザーのライセンスに関する考慮事項

Microsoft Entra 外部 ID の価格は、月間アクティブ ユーザー (MAU) に基づきます。 アクティブ ユーザーの数は、1 か月間に認証アクティビティを使用した一意のユーザーの数です。 「Microsoft Entra 外部 IDの課金モデル」では、MAU に基づく価格について説明します。

Office 365 に関する考慮事項

次の情報は、この記事のシナリオのコンテキストで Office 365 に対処しています。 詳細情報は、「Microsoft 365 テナント間コラボレーション」で確認できます。 この記事では、ファイルと会話の一元的な場所の使用、予定表の共有、IM の使用、オーディオ/ビデオ通話によるコミュニケーション、リソースとアプリケーションへのアクセスの保護などのオプションについて説明しています。

Microsoft Exchange Online

Exchange Online により、外部ユーザー向けの特定の機能が制限されます。 外部ゲスト ユーザーではなく外部メンバー ユーザーを作成すると、この制限を減らすことができます。 外部ユーザーのサポートには、次の制限があります。

• 外部ユーザーに Exchange Online ライセンスを割り当てることができます。 ただし、Exchange Online のトークンを発行することはできません。 したがって、リソースにはアクセスできません。
  • 外部ユーザーは、リソース テナント内の共有された、またはデリゲートされた Exchange Online メールボックスを使用できません。
  • 共有メールボックスに外部ユーザーを割り当てることはできますが、外部ユーザーは共有メールボックスにアクセスできません。
• 外部ユーザーを GAL に含めるには、再表示する必要があります。 既定では、非表示になっています。
  • 非表示の外部ユーザーは、招待時に作成されます。 この作成は、ユーザーが招待を引き換えたかどうかとは無関係です。 そのため、すべての外部ユーザーが再表示された場合、一覧には招待を引き換えていない外部ユーザーのユーザー オブジェクトが含まれます。 シナリオによっては、オブジェクトを一覧に含める必要がある場合と、ない場合があります。
  • 外部ユーザーは、Exchange Online PowerShell を使って再表示できます。 Set-MailUser PowerShell コマンドレットを実行して、HiddenFromAddressListsEnabled プロパティの値を $false に設定できます。

次に例を示します。

Set-MailUser [ExternalUserUPN] -HiddenFromAddressListsEnabled:\$false\

ここで、ExternalUserUPN は計算された UserPrincipalName です。

次に例を示します。

Set-MailUser externaluser1_contoso.com#EXT#@fabricam.onmicrosoft.com\ -HiddenFromAddressListsEnabled:\$false

外部ユーザーは、Microsoft 365 管理センターで、非表示ではなくなる可能性があります。

• Exchange 固有のプロパティ (PrimarySmtpAddress、ExternalEmailAddress、EmailAddresses、MailTip など) の更新は、Exchange Online PowerShell でのみ設定できます。 Exchange Online 管理センターでは、グラフィカル ユーザー インターフェイス (GUI) を使って属性を変更することはできません。

例に示すように、メール固有のプロパティに Set-MailUser PowerShell コマンドレットを使用できます。 Set-User PowerShell コマンドレットで変更できるユーザー プロパティもあります。 ほとんどのプロパティは Microsoft Graph API で変更できます。

Set-MailUser の最も便利な機能の 1 つは、EmailAddresses プロパティを操作できることです。 この複数値属性には、外部ユーザーの複数のプロキシ アドレス (SMTP、X500、セッション開始プロトコル (SIP) など) が含まれる場合があります。 外部ユーザーには既定で、UserPrincipalName (UPN) に関連付けられたプライマリ SMTP アドレスがスタンプされます。 プライマリ SMTP の変更または SMTP アドレスの追加を行う場合は、このプロパティを設定できます。 Exchange 管理センターは使用できません。Exchange Online PowerShell を使用する必要があります。 「Exchange Online 内のメールボックスのメール アドレスを追加または削除する」では、EmailAddresses などの複数値プロパティを変更するさまざまな方法について説明しています。

Microsoft 365 の Microsoft SharePoint

Microsoft 365 の SharePoint Online には、Microsoft Entra テナントでユーザー (内部または外部) の種類がメンバーになっているかゲストになっているかに応じて、独自のサービス固有のアクセス許可があります。 「Microsoft 365 の外部共有と Microsoft Entra B2B Collaboration」では、SharePoint および OneDrive との統合を有効にして、組織の外部のユーザーとファイル、フォルダー、リスト アイテム、ドキュメント ライブラリ、サイトを共有する方法について説明しています。 Microsoft 365 は、認証と管理に Azure B2B を使用しているときにこれを行います。

Microsoft 365 の SharePoint で外部共有を有効にすると、Microsoft 365 のSharePoint のユーザー ピッカーでゲスト ユーザーを検索する機能は既定では オフ になります。 この設定のため、Exchange Online の GAL から非表示にされているゲスト ユーザーを検出することはできません。 ゲスト ユーザーを表示するには 2 つの方法があります (相互に排他的ではありません)。

• ゲスト ユーザーを検索する機能を有効にする方法は次のとおりです。
  • テナントとサイト コレクション レベルで ShowPeoplePickerSuggestionsForGuestUsers 設定を変更します。
  • Set-SPOTenant および Set-SPOSite の Microsoft 365 の SharePoint PowerShell コマンドレットを使用して機能を設定します。
• Exchange Online の GAL に表示されるゲスト ユーザーは、Microsoft 365 の SharePoint のユーザー ピッカーにも表示されます。 アカウントは、ShowPeoplePickerSuggestionsForGuestUsers の設定に関係なく表示されます。

Microsoft Teams

Microsoft Teams には、ユーザーの種類に基づいてアクセスを制限する機能があります。 ユーザーの種類を変更すると、コンテンツへのアクセスと使用できる機能に影響する可能性があります。 Microsoft Teams では、ホーム テナントの外部で Teams を使用するときに、ユーザーは Teams クライアントのテナント切り替えメカニズムを使用してコンテキストを変更する必要があります。

Microsoft Teams のテナント切り替えメカニズムでは、ホームテナント以外の Teams で作業を行う場合、ユーザーが Teams クライアントのコンテキストを手動で切り替えることが必要になる場合があります。

Teams フェデレーションを使用すると、別のまったく外部のドメインの Teams ユーザーが、内部のユーザーとの検索、通話、チャット、会議の設定をできるようにすることが可能です。 「Microsoft ID を使用して外部会議を管理し、人や組織とチャットする」では、組織内のユーザーが、ID プロバイダーとして Microsoft を使用している組織外のユーザーとチャットや会議を行えるようにする方法について説明しています。

Teams でのゲスト ユーザーのライセンスに関する考慮事項

Office 365 ワークロードで Azure B2B を使用する場合、ゲスト ユーザー (内部または外部) のエクスペリエンスがメンバー ユーザーの場合と異なる例も重要な考慮事項に含まれます。

• Microsoft グループ。「Office 365 グループへのゲストの追加」では、Microsoft 365 グループのゲスト アクセスを使用して、グループの会話、ファイル、予定表の招待状、グループのノートブックへのアクセス権を組織外の人に付与し、自分やチームが外部の人と共同作業できるようにする方法について説明しています。
• Microsoft Teams。「Teams のチーム所有者、メンバー、およびゲスト機能」では、Microsoft Teams でのゲスト アカウントのエクスペリエンスについて説明しています。 外部メンバー ユーザーを使用することで、Teams の完全に忠実なエクスペリエンスを有効にできます。
  • 商用クラウド内の複数のテナントの場合、ホーム テナントでのライセンスを持つユーザーは、同じ法人内の別のテナントのリソースにアクセスできます。 アクセス権は外部メンバーの設定を使用して、追加のライセンス料金なしで付与することができます。 この設定は、Teams および Groups での SharePoint および OneDrive に適用されます。
  • 他の Microsoft クラウド内の複数のテナントおよび異なるクラウド内の複数のテナントでは、B2B メンバー ライセンス チェックはまだ使用できません。 Teams での B2B メンバーの使用には、B2B メンバーごとに追加のライセンスが必要です。 この要件は、Power BI などの他のワークロードにも影響する場合があります。
  • 同じ法人に属していないテナントに対する B2B メンバーの使用には、追加のライセンス要件が適用されます。
• Identity Governance 機能。 エンタイトルメント管理とアクセス レビューでは、外部ユーザーに他のライセンスが必要になる場合があります。
• その他の製品。 Dynamics 顧客関係管理 (CRM) などの製品では、ユーザーが存在するテナントごとにライセンスが必要になる場合があります。

次のステップ

• 「マルチテナント ユーザー管理の概要」は、Microsoft Entra マルチテナント環境でユーザー ライフサイクル管理の構成と提供を行うためのガイダンスを提供するこのシリーズ記事の第 1 回目です。
• 「マルチテナント ユーザー管理のシナリオ」では、マルチテナント ユーザー管理機能を使用できる 3 つのシナリオ (エンド ユーザーによる実施、スクリプト化、自動化) について説明します。
• 「マルチテナント型のユーザー管理の一般的なソリューション」 (シングル テナントでは要件を満たせない場合) では、テナント間の自動ユーザー ライフサイクル管理とリソースの割り当てに加え、テナント間のオンプレミス アプリの共有に関する課題のガイダンスを説明します。
• 「米国防衛産業基盤向け Microsoft コラボレーション フレームワーク」では、マルチテナント組織 (MTO) に対応する ID の候補参照アーキテクチャについて説明しています。 このシナリオは、Microsoft 365 US Government (GCC High) と Azure Government を使用して米国ソブリン クラウドにデプロイされている MTO に特に当てはまります。 また、商用クラウドまたは米国ソブリン クラウドに所属する組織を含む、厳しく規制された環境での外部コラボレーションにも対処します。