この記事では、Microsoft Entra ID（旧 Azure AD）を ID の IdP およびソースとして使用するよう Cloud Identity または Google Workspace を構成する方法について説明します。
この記事では、Microsoft Entra ID の論理構造と Cloud Identity および Google Workspace で使用される構造を比較し、Microsoft Entra ID テナント、ドメイン、ユーザー、グループをマッピングする方法について説明します。
連携の実装
Google Cloud では、認証とアクセス管理に Google ID が使用されます。各従業員がすでに Microsoft Entra ID のアカウントを持っている場合、各従業員の Google ID を手動で管理すると、不要な管理の負担が増える可能性があります。Google Cloud と既存の ID 管理システムの間でユーザー ID を連携させることで、Google ID のメンテナンスを自動化できます。さらに、Google ID のライフサイクルを Microsoft Entra ID の既存ユーザーに結び付けることができます。
Microsoft Entra ID と Cloud Identity または Google Workspace の連携を設定するには、次の 2 つの作業が必要です。
ユーザーのプロビジョニング: 関連するユーザーとグループが Microsoft Entra ID から Cloud Identity または Google Workspace に定期的に同期されます。このプロセスにより、Microsoft Entra ID で新しいユーザーを作成するか、Active Directory から Microsoft Entra ID に新しいユーザーを同期したときに、新しいユーザーが Google Cloud でも公開されます。これにより、関連付けられたユーザーが初回ログインする前でも、Google Cloud 内で参照できるようになります。このプロセスにより、ユーザーの削除も確実に反映されます。
プロビジョニングは一方向に機能します。つまり、Microsoft Entra ID の変更は Google Cloud に複製されますが、その逆は行われません。また、プロビジョニングにパスワードは含まれません。
シングル サインオン: ユーザーの認証が必要な場合は常に、Google Cloud が SAML（Security Assertion Markup Language）プロトコルを使用して Microsoft Entra ID に認証を委任します。Microsoft Entra ID は、Microsoft Entra ID の構成に応じて次のいずれかを行います。
- 認証自体を実行する。
- パススルー認証またはパスワード ハッシュ同期を使用する。
- オンプレミスの AD FS サーバーに認証を委任する。
Cloud Identity または Google Workspace から Microsoft Entra ID へ認証を委任させると、パスワードを Google Cloud に同期する必要がなくなるだけでなく、Microsoft Entra ID や AD FS で構成した該当するポリシーや多要素認証（MFA）メカニズムが使用されるようになります。
Microsoft Entra ID の論理構造
Azure を使用する場合、1 つ以上の Microsoft Entra ID テナント（ディレクトリとも呼ばれます）を使用します。Microsoft Entra ID テナントは最上位の構造です。テナントは管理上の境界とみなされ、ユーザー、グループ、リソース、リソース グループのコンテナとしての役割を果たします。
Microsoft Entra ID テナントごとに、1 つ以上の DNS ドメインが関連付けられます。この DNS ドメインは、ユーザー名（ユーザー プリンシパル名または UPN とも呼ばれる）に反映されます。ユーザー名は、name@domain という形式をとり、domain は対応するテナントに関連付けられた DNS ドメインのうちの 1 つです。
企業が複数の Microsoft Entra ID テナントを維持している場合もあります。複数のテナントを使用する一般的な理由としては、組織のさまざまな部分を区別するため、本番環境のリソースを開発やテスト用のリソースから分離するため、別個のテナントを使用してオンプレミスの Active Directory の複数のフォレストを統合するため、などが挙げられます。
Google Cloud の論理構造
Google Cloud ではすべてのリソースで、組織がコンテナとしての機能を果たします。組織内のリソースは、フォルダやプロジェクトを使用してセグメント化できます。ただし、Microsoft Entra ID テナントとは異なり、サービス アカウントを除いて、組織はユーザーとグループの管理には使用されません。
ユーザーとグループを管理するために、Google Cloud は Cloud Identity または Google Workspace を使用します。Cloud Identity アカウントまたは Google Workspace アカウントは、ユーザーとグループのプライベート ディレクトリとして機能します。ユーザーはアカウント管理者として、ユーザーとグループのライフサイクルと設定を制御し、認証の実行方法を定義できます。
Cloud Identity アカウントまたは Google Workspace アカウントを作成すると、Google Cloud 組織が自動的に作成されます。Cloud Identity アカウントまたは Google Workspace アカウントとそれに関連付けられている Google Cloud 組織は、同じ名前を共有し、互いに関連付けられます。ただし、Google Cloud 組織は、他の Cloud Identity アカウントまたは Google Workspace アカウントのユーザーとグループを参照できます。
Microsoft Entra ID と Google Cloud の統合
Microsoft Entra ID と Google Cloud の論理構造には一定の類似点がありますが、この 2 つの構造間にすべてのシナリオで同等に十分機能するマッピングは存在しません。2 つのシステムを統合して構造をマッピングする際の正しいアプローチは、次の複数の要素によって異なります。
- Microsoft Entra ID テナントを Cloud Identity アカウントまたは Google Workspace アカウントにマッピングする方法
- DNS ドメインをマッピングする方法
- ユーザーをマッピングする方法
- グループをマッピングする方法
以降のセクションで、上記のそれぞれの要素について説明します。
Google Cloud は Microsoft Entra ID とのみ連携します。オンプレミスの Active Directory とは連携しません。このため、オンプレミスの Active Directory のフォレストとドメインが Microsoft Entra ID にどのようにマッピングされているかは、ほとんど問題になりません。
Microsoft Entra ID テナントのマッピング
単一のテナント
Microsoft Entra ID テナントを 1 つだけ使用する場合は、テナントを 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにマッピングし、2 つのアカウント間の連携を設定できます。この Cloud Identity アカウントや Google Workspace アカウントにより、1 つの Google Cloud 組織の基盤が提供され、それを使用して Google Cloud リソースをすべて管理できます。
複数のテナント
大規模な組織で複数の Microsoft Entra ID テナントを使用することは珍しくありません。テスト環境と本番環境を区別する、または組織のさまざまな部分を区別する場合には、複数のテナントが使用されます。
複数の Microsoft Entra ID テナントから 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにユーザーとグループをプロビジョニングすることはできます。ただし、現時点では複数の Microsoft Entra ID テナント間のユーザーで機能するようにシングル サインオンを設定することはできません。複数の Microsoft Entra ID テナントを使用する場合は、テナントごとに個別の Cloud Identity アカウントまたは Google Workspace アカウントを作成し、各ペア間の連携を設定する必要があります。
Google Cloud では、Cloud Identity アカウントまたは Google Workspace アカウントごとに別の組織が作成されます。Google Cloud では、1 つの組織内でプロジェクトとフォルダを使用してリソースを整理できるため、多くの場合、複数の組織を作成するのは現実的ではありません。ただし、いずれかの組織を選択して他の Cloud Identity アカウントまたは Google Workspace アカウントに関連付けることで、複数の Active Directory フォレストと連携する 1 つの組織を効果的に作成できます。選択していない組織は未使用のままになります。
外部ユーザー
Microsoft Entra ID B2B を使用すると、外部ユーザーをゲストとして Microsoft Entra ID テナントに招待できます。ゲストごとに新しいユーザーが作成され、Microsoft Entra ID によってゲストユーザーに UPN が自動的に割り当てられます。Microsoft Entra ID が生成する UPN では、招待者のメールアドレスから取得されたプレフィックスとテナントの初期ドメイン（prefix#EXT#@tenant.onmicrosoft.com）の組み合わせが使用されます。
Microsoft Entra ID から Cloud Identity または Google Workspace にゲストユーザーをプロビジョニングする場合、以下の制限があります。
onmicrosoft.comは、Cloud Identity または Google Workspace で追加および確認できないドメインのため、ゲストユーザーの UPN を Cloud Identity や Google Workspace のメールアドレスにマッピングできません。したがって、UPN 以外の属性を使用してユーザーをマッピングする必要があります。- ゲストユーザーがホームテナントで一時停止された場合、Cloud Identity または Google Workspace の対応するユーザーは有効なままになり、Google Cloud リソースへのアクセスが正しく取り消されない場合があります。
別の Microsoft Entra ID テナントからのゲストユーザーに対応するより良い方法は、前のセクションで説明したように、複数の Cloud Identity アカウントまたは Google Workspace アカウントを作成し、それぞれを別の Microsoft Entra ID テナントと連携することです。詳細については、Microsoft Entra ID の B2B ユーザー プロビジョニングとシングル サインオンをご覧ください。
外部ユーザーに特定の Google Cloud リソースへのアクセス権を付与する必要がある際に、対象ユーザーが Cloud Identity または Google Workspace でユーザー アカウントを保有していることは前提条件ではありません。ポリシーで制限されていない限り、外部ユーザーに Google ID があれば、それぞれのプロジェクト、フォルダ、組織に、メンバーとして外部ユーザーを直接追加することもできます。
DNS ドメインのマッピング
DNS は、Microsoft Entra ID だけでなく、Cloud Identity と Google Workspace に対しても重要な役割を果たします。Microsoft Entra ID と Google Cloud の連携を計画する際に考慮すべき 2 番目の要素は、Microsoft Entra ID と Google Cloud との間で DNS ドメインを共有またはマッピングする方法です。
Google Cloud での DNS ドメインの使用
Google Cloud が認証目的のために使用する Google ログインでは、メールアドレスを使用してユーザーを識別します。メールアドレスを使用すると、各ユーザーをグローバルに一意のユーザーとして識別できるだけでなく、Google Cloud が該当するメールアドレスに通知メッセージを送信することもできます。
Google ログインは、メールアドレスのドメイン部分（@ に続く部分）に基づいて、ユーザーの認証に使用するディレクトリまたは ID プロバイダを決定します。たとえば、gmail.com ドメインを使用するメールアドレスの場合、Google ログインは Gmail ユーザーのディレクトリを使用して認証を行います。
Google Workspace アカウントまたは Cloud Identity アカウントを登録すると、ログインで認証に使用できるプライベート ディレクトリが作成されます。Gmail ディレクトリが gmail.com ドメインに関連付けられるのと同じ方法で、Google Workspace アカウントと Cloud Identity アカウントにカスタム ドメインを関連付ける必要があります。関連付けを行う際には次の 3 種類のドメインが使用されます。
- プライマリ ドメイン: このドメインは Cloud Identity アカウントまたは Google Workspace アカウントを識別し、Google Cloud で組織の名前として使用されます。Cloud Identity または Google Workspace に登録する際に、このドメイン名を指定する必要があります。
- セカンダリ ドメイン: プライマリ ドメインとあわせて、追加のセカンダリ ドメインを Cloud Identity アカウントまたは Google Workspace アカウントに関連付けることができます。ディレクトリ内の各ユーザーは、プライマリ ドメインまたはセカンダリ ドメインのいずれかに関連付けられます。
example.comがプライマリ ドメインで、secondary.example.comがセカンダリ ドメインの場合、johndoe@example.comとjohndoe@secondary.example.comという 2 つのユーザーはそれぞれ別のユーザーとみなされます。 - エイリアス ドメイン: エイリアス ドメインは、別のドメインの代替名です。つまり、
alias.example.comがexample.comのエイリアス ドメインとして設定されている場合、johndoe@example.comとjohndoe@alias.example.comは同じユーザーを指します。
いずれのドメインも、次の要件を満たす必要があります。
- 有効なグローバル DNS ドメイン名でなければなりません。ドメイン設定時には、ドメイン所有権を確認するために、該当する DNS ゾーンに対する管理者権限が必要になる場合があります。
example.comなどのドメインで参照できるディレクトリは 1 つのみです。ただし、subdomain.example.comなどのさまざまなサブドメインを使用して異なるディレクトリを参照できます。- プライマリ ドメインとセカンダリ ドメインには有効な MX レコードが必要です。これにより、該当するドメイン名を使用して生成されたメールアドレスへ送信されるメッセージを適切に配信できます。
Microsoft Entra ID での DNS ドメインの使用
Cloud Identity および Google Workspace が DNS を使用する方法は、Microsoft Entra ID が DNS を使用して Microsoft Entra ID テナントを識別し、ユーザー名をテナントに関連付ける方法と似ています。ただし、注意すべき相違点が 2 点あります。
初期ドメイン: Microsoft Entra ID テナントを作成すると、テナントは
onmicrosoft.comのサブドメインである初期ドメインに関連付けられます。このドメインは、ユーザーがドメインを所有していないという点と、そのユーザーには該当する DNS ゾーンへの管理者権限が付与されていないという点で、ユーザーが登録するカスタム ドメイン名とは異なります。Cloud Identity には初期ドメインに相当するものはありません。ユーザーが Cloud Identity アカウントに関連付けるすべてのドメインは、ユーザーが所有するものでなければなりません。この要件は、
onmicrosoft.comサブドメインを Cloud Identity ドメインとして登録できないことを意味します。ユーザー ID で使用されるドメイン: Microsoft Entra ID はメールアドレスの MOERA（Microsoft Online Email Routing Addresses）と UPN を区別します。どちらも RFC 822 形式（
user@domain）に従いますが、異なる目的を果たします。UPN はユーザーの識別とログイン フォームで使用され、メールの配信には MOERA のみが使用されます。UPN で使用するドメイン サフィックスは Microsoft Entra ID テナントの登録ドメインのいずれかと一致しなければなりません。この要件は、メールアドレスには適用されません。
Cloud Identity と Google Workspace は UPN のコンセプトを使用せず、代わりにユーザーのメールアドレスを ID として使用します。そのため、メールアドレスで使用されるドメインは、Cloud Identity アカウントまたは Google Workspace アカウントの登録済みドメインのいずれかと一致する必要があります。
Microsoft Entra ID テナントと、Cloud Identity アカウントまたは Google Workspace アカウントは、同じ DNS ドメインを使用できます。同じドメインを使用できない場合は、ユーザー プロビジョニングとシングル サインオンを構成して、ドメイン名に代えることができます。
上記で説明した 2 つの相違点を考慮して、Microsoft Entra ID と Cloud Identity または Google Workspace との間のユーザーのマッピング方法の計画に基づいて、ドメイン マッピングを行う必要があります。
ユーザーのマッピング
Microsoft Entra ID と Google Cloud の連携を計画する際に検討する 3 番目の要素は、Microsoft Entra ID と Cloud Identity または Google Workspace との間でユーザーをマッピングする方法です。
Microsoft Entra ID ユーザーを Cloud Identity または Google Workspace のユーザーに正しくマッピングするには、ユーザーごとに次の 2 つの情報が必要です。
- どの Microsoft Entra ID ユーザーが Cloud Identity または Google Workspace 内のユーザーに対応しているかを同期中に追跡するために使用できる、安定した一意の ID。
- ドメインの部分が Cloud Identity のプライマリ ドメイン、セカンダリ ドメイン、またはエイリアス ドメインに相当するメールアドレス。このメールアドレスは Google Cloud 全体で使用されるため、アドレスは人が読んで理解できる必要があります。
内部的には、Microsoft Entra ID は ObjectId によってユーザーを識別します。ObjectId は、ランダムに生成される、グローバルに一意の ID です。この ID は安定しているため、最初の要件を満たしていますが、人間には理解できず、メールアドレスの形式にも従っていません。ユーザーをマッピングするのに唯一実用的な選択肢は、UPN またはメールアドレスでマッピングすることです。
Microsoft Entra ID でシングル サインオンを使用するように構成された Cloud Identity アカウントまたは Google Workspace アカウントに属するメールアドレスをユーザーが入力すると、ユーザーは Microsoft Entra ID ログイン画面にリダイレクトされます。
Microsoft Entra ID ではユーザーを識別するためにメールアドレスではなく UPN を使用します。したがって、Microsoft Entra ID ログイン画面では UPN を入力するよう求められます。
Microsoft Entra ID テナントが AD FS を使用してログインするように構成されている場合、ユーザーはさらに AD FS ログイン画面にリダイレクトされます。AD FS は、Active Directory UPN または Windows 2000 より前のログオン名（domain\user）でユーザーを識別できます。
Cloud Identity または Google Workspace で使用するメールアドレス、Microsoft Entra ID で使用する UPN、Active Directory で使用する UPN がすべて異なる場合、一連のログイン画面によりエンドユーザーが混乱する可能性があります。一方、サンプルのスクリーンショット（johndoe@example.com）のように、3 つの ID すべてが同じである場合、ユーザーは UPN とメールアドレスの技術的な相違に気づかないため、ユーザーが混乱する可能性を最小限に抑えることができます。
UPN によるマッピング
ユーザー エクスペリエンスの観点から、Microsoft Entra ID の UPN を Cloud Identity または Google Workspace のメールアドレスにマッピングすることをおすすめします。また、UPN を使用するもう一つの利点として、Microsoft Entra ID が一意性を保証するため、名前の競合リスクを回避できることが挙げられます。
ただし、Microsoft Entra ID の UPN を Cloud Identity のメールアドレスにマッピングするには、次の要件を満たす必要があります。
- Google Cloud から送信される通知メールがユーザーのメールボックスに正しく配信されるように、Microsoft Entra ID の UPN を有効なメールアドレスにする必要があります。有効なメールアドレスでない場合は、GCP から送信されるメールをユーザーが受信できるよう、エイリアスのメールアドレスを構成します。
- Microsoft Entra ID 内のすべての関連ユーザーの UPN では、サフィックス（
user@custom-domain）としてカスタム ドメインを使用する必要があります。Microsoft Entra ID の初期ドメイン（user@tenant.onmicrosoft.com）を使用する UPN は、Cloud Identity のメールアドレスにはマッピングできません。これは、初期ドメインは管理者自身が所有しているのではなく、Microsoft が所有しているためです。 - Microsoft Entra ID で UPN に使用するすべてのカスタム ドメインが Cloud Identity にも登録されていること。この要件は、ドメイン検証を行うために、該当する DNS ゾーンへのアクセス権が必要であることを意味します。Microsoft Entra ID でドメイン所有権を確認するために作成した既存の
TXTDNS レコードをオーバーライドするのを回避するには、Cloud Identity でCNAMEレコードを使用してドメイン所有権を確認します。
メールアドレスによるユーザーのマッピング
Microsoft Entra ID の UPN を Cloud Identity または Google Workspace のメールアドレスにマッピングできない場合は、メールアドレスでユーザーをマッピングできます。
Active Directory でメールアドレスを指定すると、アドレスが各 user オブジェクトの mail 属性に保存され、Microsoft Entra ID Connect によって値が Microsoft Entra ID の Mail 属性に同期されます。Cloud Identity または cloudid_name_short のメールアドレスにこの属性をマッピングできるように、Microsoft Entra ID では、ユーザーのプロビジョニングにこの属性も使用できます。
重要な点として、Microsoft Entra ID の Mail 属性は現在 Azure ポータルには表示されず、API または PowerShell でのみ表示および編集できます。ユーザー インターフェースではメールアドレスと予備のメールアドレスを指定できますが、いずれの値も Mail 属性に格納されないため、Cloud Identity や cloudid_name_short へのプロビジョニングには使用できません。このことから、メールアドレスでユーザーをマッピングする方法が実用的であるのは、ユーザーの作成と編集の作業の大部分を Microsoft Entra ID ではなく Active Directory で行う場合に限られます。
メールアドレスでユーザーをマッピングするには、さらに次の要件も満たす必要があります。
- メールの割り当てが完了している必要があります。同期の対象となるすべてのユーザーに、メールアドレスが割り当てられている必要があります。特に、ユーザーがオンプレミスの Active Directory から同期されている場合は、
mailは Active Directory ではオプションのユーザー属性であるため、このケースに該当しない可能性があります。Microsoft Entra ID でMail属性にメールアドレスがないユーザーは同期中、暗黙的に無視されます。 - メールアドレスが Microsoft Entra ID テナント全体で一意である必要があります。Active Directory はユーザー作成時に一意性を確認しませんが、Microsoft Entra ID Connect はデフォルトで競合を検出します。そのため、影響を受けるユーザーの同期が失敗する可能性があります。
- メールアドレスで使用されているドメインを Microsoft Entra ID に登録しておく必要はありませんが、Cloud Identity または Google Workspace には登録しておく必要があります。この要件は、ドメイン検証を行うためにそれぞれの DNS ゾーンにアクセスする必要があり、所有していないドメイン（
gmail.comなど）でメールアドレスを使用できないことを意味します。
ユーザー ライフサイクルのマッピング
Microsoft Entra ID ユーザーと Cloud Identity または Google Workspace のユーザー間のマッピングを定義したら、どのユーザー群をプロビジョニングするかを決定する必要があります。この決定については、ID セットのマッピングに関するおすすめの方法をご覧ください。
Microsoft Entra ID テナントのすべてのユーザーをプロビジョニングしない場合は、ユーザー割り当てまたはスコープ フィルタを使用して、一部のユーザーのプロビジョニングを有効にできます。
次の表では、Microsoft Entra ID プロビジョニングのデフォルトの動作が要約されています。また、ユーザーのプロビジョニングを有効または無効にすることで、Microsoft Entra ID が Cloud Identity または Google Workspace でどのアクションを行うかを制御する方法を示しています。
| Microsoft Entra ID のユーザーのプロビジョニングが有効 | Cloud Identity / Google Workspace のユーザーの状態 | Microsoft Entra ID で実行されるアクション | Cloud Identity / Google Workspace で行われるアクション |
|---|---|---|---|
| × | （存在しない） | プロビジョニングを有効にする | 新しいユーザーを作成する（*） |
| × | 存在する（有効） | プロビジョニングを有効にする | 既存のユーザーを更新する |
| × | 存在する（停止中） | プロビジョニングを有効にする | 既存のユーザーを更新し、停止したままにする |
| ○ | 存在する | ユーザーを変更する | 既存のユーザーを更新する |
| ○ | 存在する | UPN / メールアドレスの名前を変更する | メインのメールアドレスを変更し、以前のアドレスをエイリアスとして保持する |
| ○ | 存在する | プロビジョニングを無効にする | ユーザーはそのままにする |
| ○ | 存在する | ユーザーを削除する（復元可能） | ユーザーを停止する |
| ○ | 存在する | ユーザーを完全に削除する | ユーザーを一時停止して、メールアドレスに del_ 接頭辞を追加する |
（*）同じメールアドレスの一般ユーザー向けアカウントが存在する場合、その一般ユーザー向けアカウントは強制排除されます。
グループのマッピング
Microsoft Entra ID と Google Cloud の連携を計画する際に考慮すべき 4 番目の要素は、Microsoft Entra ID と Google Cloud の間でグループを同期するかどうか、同期する場合はどのようにグループをマッピングするかです。
Google Cloud では、複数のプロジェクトで効率的にアクセスを管理する一般的な手段としてグループが使用されます。各プロジェクトで個々のユーザーを Cloud IAM のロールに割り当てるのではなく、組織内の共通のロールをモデル化する一連のグループを定義します。それらのグループを一連の Cloud IAM のロールに割り当てます。グループのメンバーシップを変更することで、一連のリソース全体に対するユーザーのアクセス権を制御できます。
Microsoft Entra ID と Google Cloud 間のグループのマッピングは省略可能です。ユーザーのプロビジョニングを設定すると、Cloud Identity または Google Workspace でグループの作成と管理を直接行えます。つまり、Active Directory または Microsoft Entra ID が ID 管理の中心的なシステムとなりますが、Google Cloud のアクセス管理としては中心的なシステムにはなりません。
Active Directory または Microsoft Entra ID を ID 管理とアクセス管理の中心システムとして維持するには、Cloud Identity や Google Workspace でグループを管理するのではなく、Microsoft Entra ID からグループを同期することをおすすめします。このアプローチでは、Google Cloud のリソースに対するアクセス権を割り当てるユーザーを制御するために、Active Directory または Microsoft Entra ID のグループ メンバーシップを使用できるよう、Cloud IAM を設定できます。
Cloud Identity と Google Workspace のグループ
Cloud Identity と Google Workspace に存在するグループは、1 種類のみです。Cloud Identity と Google Workspace のグループは、定義されている Cloud Identity アカウントまたは Google Workspace アカウントの範囲に限定されません。代わりに、これらのグループは別の Cloud Identity または Google Workspace アカウントからのユーザーを含み、他のアカウント内での参照とネストをサポートします。また任意の Google Cloud 組織間での使用も可能です。
ユーザーと同様に、Cloud Identity と Google Workspace は、メールアドレスでグループを識別します。メールアドレスが実際のメールボックスに対応している必要はありません。ただし、メールアドレスには、該当する Cloud Identity アカウントに登録されているドメインのうちの 1 つが使用されている必要があります。
Cloud IAM でグループを操作する際に、ほとんどの場合、名前ではなくメールアドレスでグループを指定する必要があります。したがって、グループには意味のある名前を付けるだけでなく、意味のある、かつ認識しやすいメールアドレスを割り当てることをおすすめします。
Microsoft Entra ID のグループ
Microsoft Entra ID では、ユースケースに応じた複数の種類のグループをサポートしています。グループは単一のテナントにスコープ設定され、オブジェクト ID によって識別されます。オブジェクト ID は、ランダムに生成される、グローバルに一意の ID です。グループはネストすることができ、同じテナントのユーザー、または Azure B2B を使用して他のテナントから招待されたユーザーのいずれかを含めることができます。Microsoft Entra ID では、クエリに基づいてメンバーが自動的に決定される動的グループもサポートしています。
Microsoft Entra ID と Cloud Identity または Google Workspace を統合する場合、グループの 2 つのプロパティ（メールが有効かどうか、セキュリティが有効かどうか）が特に重要です。
- セキュリティが有効なグループは、Microsoft Entra ID のリソースへのアクセス管理に使用できます。そのため、セキュリティが有効なグループはいずれも、Google Cloud との関連では重要になる可能性があります。
- メールが有効なグループにはメールアドレスがあります。Cloud Identity と Google Workspace では、グループはメールアドレスで識別される必要があるため、このメールアドレスは重要です。
Microsoft Entra ID では、セキュリティ タイプのグループと Office 365 タイプのグループ（統合グループとも呼ばれます）を作成できます。オンプレミスの Active Directory からグループを同期する場合、または Office 365 タイプを使用する場合は、配布リストタイプのグループも作成できます。
次の表に、Microsoft Entra ID Connect のデフォルトの構成を前提として、メールが有効かセキュリティが有効かに関するこれらの種類のグループの違いと、これらのグループが Active Directory のグループタイプにどう対応するかを示します。
| ソース | Active Directory のグループの種類 | Microsoft Entra ID のグループの種類 | メールが有効 | セキュリティが有効 |
|---|---|---|---|---|
| Microsoft Entra ID | - | Office 365 グループ | 既定 | 任意 |
| Microsoft Entra ID | - | セキュリティ グループ | 任意 | 既定 |
| オンプレミス | セキュリティ グループ（メールあり） | セキュリティ グループ | ○ | ○ |
| オンプレミス | セキュリティ グループ（メールなし） | セキュリティ グループ | × | ○ |
| オンプレミス | 配布リスト（メールあり） | 配布リスト | ○ | × |
| オンプレミス | 配布リスト（メールなし） | （Microsoft Entra ID Connect では無視されます） |
ユーザーの場合とは異なり、Microsoft Entra ID では、グループに割り当てられたメールアドレスで、Microsoft Entra ID でカスタム ドメインとして登録されたドメインを使用する必要があります。この要件により、デフォルトの動作は次のようになります。
- Active Directory のグループが Microsoft Entra ID に登録済みのドメインを使用するメールアドレスを使用している場合、そのメールアドレスは Microsoft Entra ID との同期中に適切に維持される。
- Active Directory のグループが Microsoft Entra ID に登録されていないメールアドレスを使用している場合、Microsoft Entra ID は同期中に新しいメールアドレスを自動生成する。このメールアドレスには、テナントのデフォルト ドメインが使用されます。テナントがデフォルト ドメインとして初期ドメインを使用している場合、生成されるメールアドレスは
[name]@[tenant].onmicrosoft.comの形式になります。 - Microsoft Entra ID に Office 365 グループを作成すると、Microsoft Entra ID はテナントのデフォルト ドメインを使用するメールアドレスも自動生成する。
グループ ID のマッピング
Microsoft Entra ID グループを Cloud Identity グループまたは Google Workspace グループに正常にマッピングするには、共通の ID が必要で、この ID はメールアドレスとする必要があります。Microsoft Entra ID 側では、この要件に以下の 2 つの選択肢があります。
- Microsoft Entra ID 内のグループのメールアドレスを使用して、Cloud Identity または Google Workspace のメールアドレスにマッピングできます。
- Microsoft Entra ID のグループ名からメールアドレスを取得し、そのアドレスを Cloud Identity または Google Workspace のメールアドレスにマッピングできます。
メールアドレスによるマッピング
メールアドレスによるグループ マッピングが最も明白な選択ですが、それでもまだ、求められる要件がいくつかあります。
- 同期の対象とするすべてのグループにメールアドレスが割り当てられていること。これは実際のところ、メールが有効なグループのみ同期が可能であることを意味します。メールアドレスがないグループはプロビジョニング時に無視されます。
- メールアドレスがそのテナント全体で一意であること。Microsoft Entra ID は一意性を強制しないため、カスタム チェックまたはポリシーの実装が必要になる場合があります。
- メールアドレスで使用されているドメインは、Microsoft Entra ID と Cloud Identity / Google Workspace の両方に登録されている必要があります。
tenant.onmicrosoft.comドメインを含め、Cloud Identity / Google Workspace に登録されていないドメインを使用するメールアドレスを持つグループは、同期に失敗します。
すべての関連グループが上記の条件を満たしている場合は、これらのメールアドレスで使用されるドメインを識別し、Cloud Identity または Google Workspace に登録された DNS ドメインのリストにこれらのドメインが含まれていることを確認します。
名前によるマッピング
Cloud Identity や Google Workspace にプロビジョニングするセキュリティ グループの多くでメールが有効になっていない場合、メールアドレスでグループをマッピングするための要件を満たすのは困難です。その場合は、グループの表示名からメールアドレスを自動的に取得することをおすすめします。
メールアドレスの取得には、2 つの問題が伴います。
- グループの名前から取得したメールアドレスは、ユーザーのメールアドレスと競合する可能性があります。
- Microsoft Entra ID では、グループ名に一意性を強制しません。Microsoft Entra ID テナント内の複数のグループが同じ名前を共有している場合、この名前から派生したメールアドレスが競合し、1 つのグループしか正常に同期されなくなります。
最初の問題を解決するには、生成されたメールアドレスに、ユーザーが使用しているドメインとは異なるドメインを使用します。たとえば、すべてのユーザーがドメインとして example.com のメールアドレスを使用している場合は、すべてのグループに groups.example.com を使用できます。Cloud Identity または Google Workspace にサブドメインを登録する場合、ドメインの所有権の確認は必要ないため、DNS ゾーン groups.example.com は存在さえ必要ありません。
2 つ目の問題であるグループ名の重複は、技術的にはオブジェクト ID からグループのメールアドレスを派生させるだけで解決できます。結果として生成されたグループ名はかなり難解で、扱いにくいため、Cloud Identity または Google Workspace へのプロビジョニングを設定する前に、Microsoft Entra ID で重複するグループ名を特定して名前を変更します。
グループ ライフサイクルのマッピング
Microsoft Entra ID のグループと Cloud Identity または Google Workspace のグループ間のマッピングを定義したら、どのグループ群をプロビジョニングするかを決定する必要があります。ユーザーの場合と同様に、グループの割り当てまたはスコープ フィルタを使用して、一部のグループのプロビジョニングを有効にできます。
次の表では、Microsoft Entra ID プロビジョニングのデフォルトの動作が要約されています。また、グループのプロビジョニングを有効または無効にすることで、Microsoft Entra ID が Cloud Identity または Google Workspace でどのアクションを行うかを制御する方法を示しています。
| Microsoft Entra ID のグループのプロビジョニングが有効 | Cloud Identity / Google Workspace のグループの状態 | Microsoft Entra ID で実行されるアクション | Cloud Identity / Google Workspace で行われるアクション |
|---|---|---|---|
| × | （存在しない） | プロビジョニングを有効にする | 新しいグループを作成する |
| × | 存在する | プロビジョニングを有効にする | メンバーを追加し、すべての既存メンバーは保持する |
| ○ | 存在する | グループ名を変更する | グループ名を変更する |
| ○ | 存在する | 説明を変更する | 説明を更新する |
| ○ | 存在する | メンバーを追加する | メンバーを追加し、すべての既存メンバーは保持する |
| ○ | 存在する | メンバーを削除する | メンバーを削除する |
| ○ | 存在する | プロビジョニングを無効にする | グループはそのままになる（メンバーを含む） |
| ○ | 存在する | グループを削除する | グループはそのままになる（メンバーを含む） |
次のステップ
- アカウントと組織の計画に関するベスト プラクティスと、Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスを確認する。
- Microsoft Entra ID と Cloud Identity 間でプロビジョニングとシングル サインオンを構成する方法を確認する。
- 特権管理者アカウントを管理する際のベスト プラクティスを確認する。