マルチテナント ユーザー管理のシナリオ
この記事は、Microsoft Entra マルチテナント環境でユーザー ライフサイクル管理を構成、提供するためのガイダンスを提供するシリーズ記事の第 2 回目です。 シリーズ記事の次回以降は、下記のとおり、さらに詳しい情報について説明します。
- このシリーズ記事の第 1 回目の「マルチテナント ユーザー管理の概要」では、Microsoft Entra マルチテナント環境でユーザー ライフサイクル管理を構成、提供するためのガイダンスを提供しています。
- 「マルチテナント ユーザー管理の一般的な考慮事項」では、テナント間同期、ディレクトリ オブジェクト、Microsoft Entra 条件付きアクセス、追加のアクセス制御、Office 365 に関する考慮事項のガイダンスを提供しています。
- 「マルチテナント ユーザー管理の一般的なソリューション」 (シングル テナントでは要件を満たせない場合) では、テナント間の自動ユーザー ライフサイクル管理とリソースの割り当てに加え、テナント間のオンプレミス アプリの共有に関する課題のガイダンスを説明します。
このガイダンスは、ユーザー ライフサイクル管理で整合性のとれた状態を実現するのに役立ちます。 ライフサイクル管理には、Microsoft Entra B2B コラボレーション (B2B) やテナント間同期を含む使用可能な Azure ツールを用いた、テナント間のユーザー プロビジョニング、ユーザー管理、ユーザー プロビジョニング解除が含まれます。
この記事では、マルチテナント ユーザー管理機能を使用できる 3 つのシナリオについて説明します。
- エンドユーザー開始
- スクリプト化
- 自動
エンドユーザー開始シナリオ
エンドユーザー開始シナリオでは、リソース テナント管理者は、テナント内のユーザーに特定の機能を委任します。 エンド ユーザーには、テナント、アプリ、リソースに外部ユーザーを招待する権限が管理者から与えられます。 ホーム テナントからユーザーを招待することも、個別にサインアップすることもできます。
たとえば、あるグローバル プロフェッショナル サービス企業が、プロジェクトで下請業者と共同作業を行います。 下請業者 (外部ユーザー) は、元請け企業のアプリケーションやドキュメントにアクセスする必要があります。 企業の管理者は、下請業者を招待したり、下請業者のリソース アクセス用にセルフ サービスを構成したりする機能をエンド ユーザーに委任できます。
アカウントのプロビジョニング
次に示すのは、テナント リソースにアクセスするためにエンド ユーザーを招待するときに最も広く使用されている方法です。
- アプリケーションベースの招待。Microsoft アプリケーション (Teams や SharePoint など) で、外部ユーザーの招待を有効にできます。 Microsoft Entra B2B および関連するアプリケーションの両方で、B2B の招待設定を構成します。
- MyApps。ユーザーは、MyApps を使用して外部ユーザーをアプリケーションに招待して割り当てることができます。 ユーザー アカウントには、アプリケーションのセルフサービス サインアップの承認者のアクセス許可が必要です。 グループ所有者は、外部ユーザーを自分のグループに招待できます。
- エンタイトルメント管理。管理者またはリソース所有者は、リソース、許可する外部組織、外部ユーザーの有効期限、アクセス ポリシーを含むアクセス パッケージを作成できます。 アクセス パッケージを発行して、外部ユーザーがリソース アクセスのセルフサービス サインアップを実行できるようにします。
- Azure portal。ゲスト招待元ロールが割り当てられたエンド ユーザーは、Azure portal にサインインし、Microsoft Entra ID の [ユーザー] メニューから外部ユーザーを招待できます。
- プログラム (PowerShell、Graph API)。ゲスト招待元ロールが割り当てられたエンド ユーザーは、PowerShell または Graph API を使用して外部ユーザーを招待できます。
招待の引き換え
リソースにアクセスするためのアカウントをプロビジョニングすると、招待されたユーザーのメール アドレスに招待メールが送信されます。
招待されたユーザーは招待を受け取ったら、メールに含まれている引き換え URL のリンク先を参照できます。 その際、招待されたユーザーは招待を承認または拒否し、必要に応じて外部ユーザー アカウントを作成できます。
次のいずれかのシナリオに該当する場合、招待されたユーザーは、Just-In-Time (JIT) 引き換えと呼ばれる、リソースへの直接アクセスを試みることもできます。
- 招待されたユーザーが既に Microsoft Entra ID または Microsoft アカウントを持っている。または
- 管理者が電子メール ワンタイム パスコードを有効にした。
JIT 引き換え中、次の考慮事項が適用される場合があります。
- 管理者が同意プロンプトを抑制していない場合、ユーザーはリソースにアクセスする前に同意する必要があります。
- 許可リストまたはブロックリストを使用して、特定の組織に属する外部ユーザーの招待を許可または拒否できます。
詳細については、「Microsoft Entra B2B コラボレーションの招待の利用」を参照してください。
ワンタイム パスコード認証の有効化
アドホック B2B を許可するシナリオでは、電子メール ワンタイム パスコード認証を有効にします。 この機能は、次のような他の方法で認証できないときに外部ユーザーを認証します。
- Microsoft Entra ID。
- Microsoft アカウント。
- Gmail アカウント (Google フェデレーションを使用)。
- 直接フェデレーションを介した Security Assertion Markup Language (SAML)/WS-Fed IDP からのアカウント。
ワンタイム パスコード認証では、Microsoft アカウントを作成する必要はありません。 外部ユーザーは、招待を引き換えるか共有リソースにアクセスするときにメール アドレスで一時コードを受け取ります。 次に、そのコードを入力してサインインを続行します。
アカウントの管理
エンド ユーザー開始シナリオでは、リソース テナント管理者はリソース テナント内で外部ユーザー アカウントを管理します (ホーム テナントの更新値に基づいて更新しません)。 受信した表示属性には、メール アドレスと表示名だけが含まれます。
外部ユーザー オブジェクトに対してさらに多くの属性を構成することで、さまざまなシナリオ (エンタイトルメント シナリオなど) を可能にできます。 アドレス帳に連絡先の詳細を入力することを含めることができます。 たとえば、次の属性を考えてみましょう。
- HiddenFromAddressListsEnabled [ShowInAddressList]
- FirstName [GivenName]
- LastName [SurName]
- Title
- 部門
- TelephoneNumber
これらの属性を設定して、外部ユーザーをグローバル アドレス一覧 (GAL) やユーザー検索 (SharePoint のユーザー ピッカーなど) に追加できます。 他のシナリオでは、異なる属性 (アクセス パッケージ、動的グループ メンバーシップ、SAML クレームに対するエンタイトルメントとアクセス許可の設定など) が必要になる場合があります。
既定で、GAL では招待された外部ユーザーは非表示になります。 統合 GAL に含めるには、外部ユーザーの属性を非表示にしないように設定します。 「マルチテナント ユーザー管理に関する一般的な考慮事項」の Microsoft Exchange Online に関するセクションでは、外部ゲスト ユーザーではなく外部メンバー ユーザーを作成することによって制限を軽減する方法について説明しています。
アカウントのプロビジョニング解除
エンド ユーザー開始シナリオでは、アクセスに関する決定が分散化されます。これにより、外部ユーザーとその関連するアクセス権を削除するタイミングを決定するという課題が生じる可能性があります。 エンタイトルメント管理とアクセス レビューを使用すると、既存の外部ユーザーとそのリソース アクセス権をレビューおよび削除できます。
エンタイトルメント管理の範囲外でユーザーを招待する場合は、そのアクセス権をレビューして管理するためのプロセスを別途作成する必要があります。 たとえば、Microsoft 365 の SharePoint 経由で外部ユーザーを直接招待する場合は、エンタイトルメント管理プロセスには含まれません。
スクリプト シナリオ
スクリプト シナリオでは、リソース テナント管理者が、スクリプト化されたプル プロセスをデプロイすることで、検出と外部ユーザーのプロビジョニングを自動化します。
たとえば、ある会社が競合企業を買収したとします。 それぞれの企業には、Microsoft Entra テナントが 1 つ存在します。 ユーザーが招待や引き換えの手順を実行することなく、次の 1 日目のシナリオを機能させる必要があります。 すべてのユーザーが次のことを実行できる必要があります。
- プロビジョニングされているすべてのリソースにシングル サインオンを使用する。
- 統合 GAL でお互いやリソースを見つける。
- お互いの存在を確認し、チャットを開始する。
- 動的メンバーシップ グループに基づいてアプリケーションにアクセスする。
このシナリオでは、それぞれの組織のテナントは、既存の従業員にとってはホーム テナントであり、もう一方の組織の従業員にとってはリソース テナントとなります。
アカウントのプロビジョニング
テナント管理者は、デルタ クエリを使用し、検出と ID のプロビジョニングを自動化するスクリプト化されたプル プロセスをデプロイして、リソースのアクセスをサポートできます。 このプロセスでは、ホーム テナントで新しいユーザーが確認されます。 次のマルチテナント トポロジ図に示すように、新しいユーザーは、B2B Graph API を使用して、リソース テナントの外部ユーザーとしてプロビジョニングされます。
- テナント管理者は、各テナントの読み取りを許可するために資格情報と同意を事前に設定します。
- テナント管理者は、列挙と、対象ユーザーのリソース テナントへのプルを自動化します。
- 同意済みのアクセス許可で Microsoft Graph API を使用し、招待 API によってユーザーを読み取ってプロビジョニングします。
- 初回プロビジョニングでソース属性を読み取り、それらをターゲット ユーザー オブジェクトに適用できます。
アカウントの管理
リソース組織は、リソース テナント内のユーザーのメタデータ属性を更新することで、共有シナリオをサポートするためにプロファイル データを拡張できます。 ただし常時同期が必要な場合は、同期ソリューションを選んだ方が得策でしょう。
アカウントのプロビジョニング解除
外部ユーザーのプロビジョニングを解除する必要があるときは、デルタ クエリからシグナルを受信できます。 既存の外部ユーザーとそのリソース アクセス権をレビューして削除する手段は、エンタイトルメント管理とアクセス レビューで実現できます。
エンタイトルメント管理の範囲外のユーザーを招待する場合は、外部ユーザーのアクセス権をレビューして管理するためのプロセスを別途作成します。 たとえば、Microsoft 365 の SharePoint 経由で直接外部ユーザーを招待する場合は、エンタイトルメント管理プロセスには含まれません。
自動化シナリオ
テナント間での同期共有は、この記事で説明するパターンの中で最も複雑です。 このパターンを使用すると、エンドユーザー開始やスクリプトよりもさらに自動化された管理とプロビジョニング解除のオプションを使用できます。
自動化シナリオでは、リソース テナント管理者が、ID プロビジョニング システムを使用して、プロビジョニングとプロビジョニング解除プロセスを自動化します。 Microsoft の商用クラウド インスタンス内のシナリオには、テナント間同期があります。 Microsoft ソブリン クラウドの複数のインスタンスにまたがるシナリオの場合、テナント間同期ではクラウド間はまだサポートされていないため、他のアプローチが必要です。
たとえば、Microsoft の商用クラウド インスタンス内に、次の要件を持つ複数の子会社がある多国籍/地域の複合企業があるとします。
- それぞれ独自の Microsoft Entra テナントを持っており、連携する必要がある。
- テナント間で新しいユーザーを同期することに加え、属性の更新を自動的に同期し、プロビジョニング解除を自動化する。
- 子会社の従業員が退社した場合、次回の同期中に他のすべてのテナントからそのアカウントを削除する。
拡張されたクラウド間シナリオでは、防衛産業基盤 (DIB) の請負業者には、防衛基盤と商用基盤の子会社があります。 これらには、競合する規制要件があります。
- 米国の防衛ビジネスは、Microsoft 365 US Government GCC High や Azure Government などの米国ソブリン クラウド テナントに存在する。
- 商用ビジネスは、グローバル Azure クラウドで実行されている Microsoft Entra 環境など、商用内の別個の Microsoft Entra テナントに存在する。
クロスクラウド アーキテクチャにデプロイされた単一の会社のように機能するため、すべてのユーザーは両方のテナントに同期されます。 この方法を使用すると、両方のテナント間で統合 GAL を利用できるようになり、両方のテナントに自動的に同期されるユーザーには、アプリケーションとコンテンツに対するエンタイトルメントと制限を含めることができる場合があります。 要件の例としては次のようなものがあります。
- 米国の従業員は、両方のテナントにどこからでもアクセスできます。
- 米国以外の従業員は、両方のテナントの統合 GAL に表示されるが、GCC High テナント内の保護されたコンテンツにはアクセスできません。
このシナリオでは、両方のテナントでユーザーを構成し、それらのユーザーを適切なエンタイトルメントとデータ保護ポリシーに関連付けるために、自動同期と ID 管理が必要となります。
クロスクラウド B2B では、リモート クラウド インスタンスで共同作業を行う各組織に対してテナント間アクセス設定を構成する必要があります。
アカウントのプロビジョニング
このセクションでは、自動化シナリオでアカウント プロビジョニングを自動化するための 3 つの手法について説明します。
手法 1: Microsoft Entra ID の組み込みテナント間同期機能を使用する
この方法は、同期する必要があるすべてのテナントが同じクラウド インスタンス (商用間など) 内にある場合にのみ機能します。
手法 2: Microsoft Identity Manager を使用してアカウントをプロビジョニングする
Microsoft Identity Manager (MIM) などの外部 ID およびアクセス管理 (IAM) ソリューションを同期エンジンとして使用します。
この高度なデプロイでは、同期エンジンとして MIM が使用されます。 MIM は、Microsoft Graph API と Exchange Online PowerShell を呼び出します。 これに代わる実装としては、Microsoft Industry Solutions が提供するクラウド ホスト型の Active Directory 同期サービス (ADSS) マネージド サービス オファリングがあります。 他の IAM オファリング (SailPoint、Omada、OKTA など) を使用して最初から作成できる Microsoft 以外のオファリングがあります。
次の図に示すように、あるテナントから別のテナントへの ID (ユーザー、連絡先、グループ) のクラウド間同期を実行します。
この記事の範囲外の考慮事項としては、オンプレミス アプリケーションの統合があります。
手法 3: Microsoft Entra Connect を使用してアカウントをプロビジョニングする
この手法は、従来の Windows Server ベースの Active Directory Domain Services (AD DS) ですべての ID を管理している複雑な組織にのみ適用されます。 この方法では、次の図に示すように、同期エンジンとして Microsoft Entra Connect を使用します。
MIM の手法とは異なり、すべての ID ソース (ユーザー、連絡先、グループ) は、従来の Windows Server ベースの Active Directory Domain Services (AD DS) から取得されます。 AD DS ディレクトリは、通常、複数のテナントの ID を管理する複雑な組織のオンプレミス デプロイです。 クラウドのみの ID は、この手法の範囲内には含まれません。 同期の範囲に含めるには、すべての ID が AD DS 内に存在する必要があります。
概念的には、この手法では、ユーザーは内部メンバー ユーザーとしてホーム テナントに同期されます (既定の動作)。 または、ユーザーを外部ユーザーとしてリソース テナントに同期することもできます (カスタマイズされた動作)。
Microsoft では、Microsoft Entra Connect 構成で行われる変更を慎重に考慮しつつ、この二重のユーザー同期手法をサポートしています。 たとえば、ウィザード駆動型のセットアップ構成を変更する場合、サポート インシデント中に構成を再構築する必要がある場合は、変更を文書化する必要があります。
Microsoft Entra Connect では、そのままの状態ですぐに外部ユーザーを同期することはできません。 ユーザーを内部から外部アカウントに変換するために外部プロセス (PowerShell スクリプトなど) を使用して拡張する必要があります。
この手法の利点としては、Microsoft Entra Connect では AD DS に格納されている属性で ID が同期されることがあげられます。 同期には、スコープ内のすべてのテナントへのアドレス帳属性、マネージャー属性、グループ メンバーシップ、およびその他のハイブリッド ID 属性が含まれる場合があります。 ID のプロビジョニング解除は、AD DS に合わせて行われます。 この特定のタスクでは、クラウド ID を管理するために、より複雑な IAM ソリューションは必要ありません。
テナントごとに Microsoft Entra Connect の 1 対 1 のリレーションシップがあります。 各テナントには、メンバーまたは外部ユーザー アカウントの同期をサポートするために個別に変更できる Microsoft Entra Connect の独自の構成があります。
適切なトポロジの選択
自動化シナリオでは、ほとんどの場合、次のトポロジのいずれかが使用されます。
- メッシュ型トポロジ: すべてのテナントのすべてのリソースを共有できます。 他のテナントのユーザーを各リソース テナントに外部ユーザーとして作成します。
- 単一リソース テナント トポロジでは、1 つのテナント (リソース テナント) を使用します。そこでは、他のテナントのユーザーは外部ユーザーです。
以下の表は、ソリューションを設計する際のデシジョン ツリーとして参照してください。 表の後の図では、自分の組織に適したトポロジを判断できるように、両方のトポロジを示しています。
メッシュ型トポロジとシングル リソース テナント型トポロジの比較
| 考慮事項 | メッシュ型トポロジ | シングル リソース テナント |
|---|---|---|
| ユーザーとリソースを含んだ個別の Microsoft Entra テナントが会社ごとに存在する | はい | はい |
| リソースの場所とコラボレーション | ||
| 共有アプリとその他のリソースは現在のホーム テナントに維持される | はい | いいえ。 リソース テナント内のアプリとその他のリソースのみを共有できます。 他のテナント内に維持されているアプリやその他のリソースは共有できません。 |
| 個々の会社の GAL (統合 GAL) ですべて表示可能 | はい | いいえ |
| リソース アクセスと管理 | ||
| Microsoft Entra ID に接続されているすべてのアプリケーションはすべての会社間で共有できます。 | はい | いいえ。 リソース テナント内のアプリケーションのみが共有されます。 他のテナント内に維持されているアプリケーションは共有できません。 |
| グローバル リソース管理 | テナント レベルで維持されます。 | リソース テナントに統合されます。 |
| ライセンス: Microsoft 365 の Office 365 SharePoint、統合 GAL、Teams アクセスではいずれもゲストがサポートされますが、他の Exchange Online シナリオではされません。 | テナント レベルで維持されます。 | テナント レベルで維持されます。 |
| ライセンス: Microsoft Entra ID (Premium) | 最初の 5 万人の月間アクティブ ユーザーは無料です (テナントごと)。 | 最初の 5 万人の月間アクティブ ユーザーは無料です。 |
| ライセンス: サービスとしてのソフトウェア (SaaS) アプリ | 個々のテナン内で維持されます。テナントごとにユーザーごとのライセンスが必要な場合があります。 | すべての共有リソースは、シングル リソース テナントに存在します。 必要に応じて、シングル テナントへのライセンスの統合を検討できます。 |
メッシュ型トポロジ
次の図は、メッシュ トポロジを示しています。
メッシュ トポロジでは、各ホーム テナントのすべてのユーザーは他の各テナントに同期され、それらはリソース テナントになります。
- テナント内のあらゆるリソースを外部ユーザーと共有できます。
- 各組織は、複合企業内のすべてのユーザーを表示できます。 上の図には、4 つの統合 GAL があります。そのそれぞれにホーム ユーザーと、他の 3 つのテナントの外部ユーザーが含まれています。
「マルチテナント ユーザー管理に関する一般的な考慮事項」では、このシナリオでのユーザーのプロビジョニング、管理、プロビジョニング解除に関する情報が提供されています。
クロスクラウドのメッシュ トポロジ
メッシュ トポロジは、クロスソブリン クラウド ソリューションにまたがる DIB 防衛請負業者のシナリオのように、わずか 2 つのテナントでも使用できます。 メッシュ トポロジと同様に、各ホーム テナントの各ユーザーは他のテナントに同期され、それがリソース テナントになります。 手法 3 セクションの図では、パブリック商用テナントの内部ユーザーが、外部ユーザー アカウントとして米国ソブリン GCC High テナントに同期されています。 同時に、GCC High の内部ユーザーは外部ユーザー アカウントとして商用に同期されています。
この図では、データの保存場所も示されています。 データの分類とコンプライアンスは、この記事の範囲外ですが、アプリケーションとコンテンツに対するエンタイトルメントと制限を含めることができます。 コンテンツには、内部ユーザーのユーザー所有データがある場所 (Exchange Online メールボックスや OneDrive に格納されているデータなど) が含まれる場合があります。 コンテンツは、そのホーム テナントに存在し、リソース テナントには存在しない場合があります。 共有データは、両方のテナントに存在する可能性があります。 コンテンツに対するアクセスは、アクセスの制御や条件付きアクセス ポリシーによって制限することができます。
シングル リソース テナント型トポロジ
次の図は、単一リソース テナント トポロジを示しています。
単一リソース テナント トポロジでは、ユーザーとその属性はリソース テナント (上の図の A 社) に同期されます。
- メンバー組織間で共有されるすべてのリソースは、単一のリソース テナントに存在する必要があります。 複数の子会社が同じ SaaS アプリのサブスクリプションを保有している場合は、それらのサブスクリプションを統合できます。
- リソース テナントの GAL にのみ、全社のユーザーが表示されます。
アカウントの管理
このソリューションでは、ソース テナントのユーザーの属性の変更が検出されて、リソース テナントの外部ユーザーに同期されます。 これらの属性を使用して、承認の決定 (動的メンバーシップ グループを使用している場合など) を行うことができます。
アカウントのプロビジョニング解除
ソース環境でオブジェクトが削除されると、オートメーションによってそれが検出されて、関連する外部ユーザー オブジェクトがターゲット環境から削除されます。
「マルチテナント ユーザー管理に関する一般的な考慮事項」では、このシナリオでのユーザーのプロビジョニング、管理、プロビジョニング解除に関する追加情報を提供します。
次のステップ
- このシリーズ記事の第 1 回目の「マルチテナント ユーザー管理の概要」では、Microsoft Entra マルチテナント環境でユーザー ライフサイクル管理を構成、提供するためのガイダンスを提供しています。
- 「マルチテナント ユーザー管理の一般的な考慮事項」では、テナント間同期、ディレクトリ オブジェクト、Microsoft Entra 条件付きアクセス、追加のアクセス制御、Office 365 に関する考慮事項のガイダンスを提供しています。
- マルチテナント ユーザー管理の一般的なソリューション (シングル テナントでは要件を満たせない場合): テナント間での自動ユーザー ライフサイクル管理とリソース割り当て、テナント間でのオンプレミス アプリ共有、といった課題のガイダンスを説明します。