Google Cloud と Azure Active Directory の連携

この記事では、Azure AD を IdP および ID のソースとして使用するように Cloud Identity や Google Workspace を構成する方法について説明します。

この記事では、Azure AD の論理構造と、Cloud Identity および Google Workspace で使用される構造を比較し、Azure AD テナント、ドメイン、ユーザー、グループをマッピングする方法について説明します。

連携を実装する

Google Cloud では、認証とアクセス管理に Google ID が使用されます。すべての従業員がすでに Azure AD にアカウントを持っている場合、各従業員の Google ID を手動で管理すると、不要な管理オーバーヘッドが発生する場合があります。Google Cloud と既存の ID 管理システムの間でユーザー ID を連携させることで、Google ID のメンテナンスを自動化できます。さらに、Google ID のライフサイクルを Azure AD の既存ユーザーに結び付けることができます。

Cloud Identity と Azure AD を連携させる

Azure AD と Cloud Identity または Google Workspace 間の連携の設定には、次に挙げる 2 つのことが必要です。

  • ユーザーのプロビジョニング: 関連するユーザーとグループは、Azure AD から Cloud Identity または Google Workspace に定期的に同期されます。このプロセスにより、Azure AD で新しいユーザーを作成するか、Active Directory から Azure AD に新しいユーザーを同期すると、関連付けられたユーザーが初回ログインを行う前でも、Google Cloud で参照できるようになります。また、同プロセスにより、ユーザーの削除も確実に反映されます。

    プロビジョニングは一方向に機能します。つまり、Azure AD の変更は Google Cloud に複製されますが、その逆は行われません。また、プロビジョニングにパスワードは含まれません。

  • シングル サインオン: ユーザーの認証が必要な場合は常に、Google Cloud が SAML(Security Assertion Markup Language)プロトコルを使用して Active Directory に認証を委任します。Azure AD の構成に応じて、Azure AD は次のいずれかを行います。

    • 認証自体を実行する。
    • パススルー認証またはパスワード ハッシュ同期を使用する。
    • オンプレミスの AD FS サーバーに認証を委任する。

Cloud Identity または Google Workspace に認証を Azure AD に委任させると、パスワードを Google Cloud に同期する必要がなくなることに加え、Azure AD や AD FS で構成した該当するポリシーや多要素認証(MFA)メカニズムが使用されるようになります。

Azure AD の論理構造

Azure を使用する場合、1 つ以上の Azure AD テナント(「ディレクトリ」とも呼ばれます)を使用します。Azure AD テナントは最上位の構造です。テナントは管理上の境界とみなされ、ユーザー、グループ、リソース、リソース グループのコンテナとしての役割を果たします。

Azure AD テナントごとに、1 つ以上の DNS ドメインが関連付けられます。この DNS ドメインはユーザー名(「ユーザー プリンシパル名」や「UPN」とも呼ばれます)に反映されます。ユーザー名は、name@domain の形式です。ここで、domain は、対応するテナントに関連付けられた DNS ドメインの 1 つです。

Azure AD の論理構造。

企業が複数の Azure AD テナントを維持している場合もあります。組織のさまざまな部分を区別する、本番環境のリソースを開発やテスト用のリソースから分離する、または個別のテナントを使用してオンプレミスの Active Directory の複数のフォレストを統合することなどが、複数のテナントを使用する一般的な理由として挙げられます。

Google Cloud の論理構造

Google Cloud ではすべてのリソースで、組織がコンテナとしての機能を果たします。組織内のリソースは、フォルダやプロジェクトを使用してセグメント化できます。ただし、Azure AD テナントとは異なり、サービス アカウントを除いて、組織はユーザーとグループの管理には使用されません。

ユーザーとグループの管理には、Google Cloud が Cloud Identity または Google Workspace を使用します。Cloud Identity アカウントまたは Google Workspace アカウントは、ユーザーとグループのプライベート ディレクトリとして機能します。ユーザーはアカウント管理者として、ユーザーとグループのライフサイクルと設定を制御し、認証の実行方法を定義できます。

Google Cloud の論理構造。

Cloud Identity アカウントまたは Google Workspace アカウントを作成すると、Google Cloud 組織が自動的に作成されます。Cloud Identity アカウントまたは Google Workspace アカウントと、それに関連付けられている Google Cloud 組織は同じ名前を共有し、互いに関連付けられます。ただし、Google Cloud 組織は、他の Cloud Identity アカウントや Google Workspace アカウントのユーザーとグループを参照できます。

Azure AD と Google Cloud の統合

Azure AD と Google Cloud の論理構造には一定の類似点がありますが、この 2 つの構造間にすべてのシナリオで同等に十分機能するマッピングは存在しません。2 つのシステムを統合して構造をマッピングする際の正しいアプローチは、次の複数の要素によって異なります。

  • Azure AD テナントを Cloud Identity アカウントまたは Google Workspace アカウントにマッピングする方法
  • DNS ドメインをマッピングする方法
  • ユーザーをマッピングする方法
  • グループをマッピングする方法

以降のセクションで、上記のそれぞれの要素について説明します。

Google Cloud は Azure AD とのみ連携します。オンプレミスの Active Directory とは連携しません。このため、オンプレミスの Active Directory のフォレストとドメインが Azure AD にどのようにマッピングされているかは、ほとんど問題になりません。

Azure AD テナントのマッピング

単一のテナント

単一の Azure AD テナントのみを使用する場合は、テナントを 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにマッピングし、それら間の連携を設定できます。この Cloud Identity アカウントや Google Workspace アカウントにより、単体の Google Cloud 組織の基盤が提供され、それを使用して Google Cloud リソースをすべて管理できます。

テナントを単一の Cloud Identity アカウントにマッピングする

複数のテナント

大規模な組織で複数の Azure AD テナントを使用することは珍しくありません。テスト環境と本番環境を区別したり、組織のさまざまな部分を区別したりする場合には、複数のテナントが使用されます。

複数の Azure AD テナントから 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにユーザーとグループをプロビジョニングすることは可能ですが、現時点では、複数の Azure AD テナント間のユーザーで機能するようにシングル サインオンを設定することはできません。複数の Azure AD テナントを使用する場合は、Cloud Identity アカウントか Google Workspace アカウントをテナントごとに個別に作成し、各ペア間の連携を設定する必要があります。

Google Cloud では、Cloud Identity アカウントまたは Google Workspace アカウントごとに別の組織が作成されます。Google Cloud では、1 つの組織内でプロジェクトフォルダを使用してリソースを整理できるため、多くの場合、複数の組織を作成するのは現実的ではありません。とはいえ、いずれかの組織を選択して、他の Cloud Identity アカウントや Google Workspace アカウントに関連付けることで、実質的に複数の Active Directory フォレストと連携する組織を作成できます。もう一方の組織は、未使用のまま残ります。

複数の Active Directory フォレストと連携する組織

外部ユーザー

Azure AD B2B を使用すると、外部ユーザーを Azure AD テナントのゲストとして招待できます。ゲストごとに新しいユーザーが作成され、Azure AD によってゲストユーザーに UPN が自動的に割り当てられます。Azure AD が生成する UPN では、招待者のメールアドレスから取得した接頭辞と、テナントの初期ドメイン(prefix#EXT#@tenant.onmicrosoft.com)が組み合わされて使用されます。

Azure AD から Cloud Identity や Google Workspace へゲストユーザーをプロビジョニングすることには、一定の制限があります。

  • onmicrosoft.com は、Cloud Identity または Google Workspace で追加および確認できないドメインのため、ゲストユーザーの UPN を Cloud Identity や Google Workspace のメールアドレスにマッピングできません。したがって、UPN 以外の属性を使用してユーザーをマッピングする必要があります。
  • ホームテナントでゲストユーザーが一時停止されている場合でも、Cloud Identity や Google Workspace の対応するユーザーは引き続き有効となり、Google Cloud リソースへのアクセスが正常に取り消されないことがあります。

別の Azure AD テナントからのゲストユーザーに対処するには、前のセクションで説明したように、複数の Cloud Identity アカウントまたは Google Workspace アカウントを作成し、それぞれ別の Azure AD テナントと連携させることをおすすめします。詳細については、Azure Active Directory B2B のユーザー プロビジョニングとシングル サインオンをご覧ください。

外部ユーザーに特定の Google Cloud リソースへのアクセス権を付与する場合、そのユーザーが Cloud Identity または Google Workspace にユーザー アカウントを持っている必要はありません。ポリシーによって制限されていない限り、外部ユーザーが Google ID を持っていれば、該当するプロジェクト、フォルダ、組織のメンバーとしてその外部ユーザーを直接追加できます。

DNS ドメインのマッピング

DNS は、Azure AD に対しても、Cloud Identity や Google Workspace に対しても、重要な役割を果たします。Azure AD と Google Cloud の連携を計画する際に考慮すべき 2 番目の要素は、Active Directory と Google Cloud との間で DNS ドメインを共有またはマッピングする方法です。

Google Cloud での DNS ドメインの使用法

Google Cloud が認証目的のために使用する Google ログインでは、メールアドレスを使用してユーザーを識別します。メールアドレスを使用すると、各ユーザーをグローバルに一意のユーザーとして識別できるだけでなく、Google Cloud が該当するメールアドレスに通知メッセージを送信することもできます。

Google ログインは、メールアドレスのドメイン部分(@ に続く部分)に基づいて、ユーザーの認証に使用するディレクトリまたは ID プロバイダを決定します。たとえば、gmail.com ドメインを使用するメールアドレスの場合、Google ログインは Gmail ユーザーのディレクトリを使用して認証を行います。

Google Cloud での DNS ドメインの使用法。

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.comjohndoe@secondary.example.com という 2 つのユーザーはそれぞれ別のユーザーとみなされます。
  • エイリアス ドメイン: エイリアス ドメインは、プライマリ ドメインの代替ドメインです。つまり、alias.example.com がエイリアス ドメインとして設定されている場合、johndoe@example.comjohndoe@alias.example.com は同じユーザーを指します。エイリアス ドメインで代替名を指定できるのはプライマリ ドメインに対してのみです。セカンダリ ドメインのエイリアス ドメインを追加することはできません。

いずれのドメインも、次の要件を満たす必要があります。

  • 有効なグローバル DNS ドメイン名でなければなりません。ドメイン設定時には、ドメイン所有権を確認するために、該当する DNS ゾーンに対する管理者権限が必要になる場合があります。
  • example.com などのドメインで参照できるディレクトリは 1 つのみです。ただし、subdomain.example.com などのさまざまなサブドメインを使用して異なるディレクトリを参照できます。
  • プライマリ ドメインとセカンダリ ドメインには有効な MX レコードが必要です。これにより、該当するドメイン名を使用して生成されたメールアドレスへ送信されるメッセージを適切に配信できます。

Azure AD での DNS ドメインの使用法

Cloud Identity と Google Workspace が DNS を使用する方法は、Azure AD が DNS を利用して Azure AD テナントを識別し、ユーザー名をテナントに関連付ける方法と似ています。ただし、2 つの注意すべき相違点があります。

  1. 初期ドメイン: Azure AD テナントを作成すると、そのテナントは onmicrosoft.com のサブドメインである初期ドメインに関連付けられます。このドメインは、ユーザーがドメインを所有していないという点と、そのユーザーには該当する DNS ゾーンへの管理者権限が付与されていないという点で、ユーザーが登録するカスタム ドメイン名とは異なります。

    Cloud Identity には初期ドメインに相当するものはありません。ユーザーが Cloud Identity アカウントに関連付けるすべてのドメインは、ユーザーが所有するものでなければなりません。この要件は、onmicrosoft.com サブドメインを Cloud Identity ドメインとして登録できないことを意味します。

  2. ユーザー ID で使用されるドメイン: Azure AD はメールアドレスの MOERA(Microsoft Online Email Routing Addresse)と UPN を区別します。どちらも RFC 822 形式(user@domain)に従いますが、異なる目的を果たします。UPN はユーザーの識別とログイン フォームで使用され、メールの配信には MOERA のみが使用されます。

    UPN で使用するドメイン サフィックスは Azure AD テナントの登録ドメインのいずれかと一致しなければなりません。この要件は、メールアドレスには適用されません。

    Cloud Identity と Google Workspace は UPN のコンセプトに依存せず、代わりにユーザーのメールアドレスを ID として使用します。そのため、メールアドレスで使用されるドメインは、Cloud Identity アカウントまたは Google Workspace アカウントの登録済みドメインと一致する必要があります。

Azure AD テナントと、Cloud Identity アカウントや Google Workspace アカウントは、同じ DNS ドメインを使用できます。前述した 2 つの相違点を考慮すると、ドメインのマッピングは、Azure AD と、Cloud Identity または Google Workspace との間でユーザーをマッピングする方法に基づく必要があります。

ユーザーのマッピング

Active Directory と Google Cloud の連携を計画する際に検討する 3 番目の要素は、Azure AD と Cloud Identity または Google Workspace との間のユーザーをマッピングする方法です。

Azure AD ユーザーを Cloud Identity や Google Workspace のユーザーに問題なくマッピングするには、ユーザーごとに次の 2 つの情報が必要です。

  1. 同期の際、どの Azure AD ユーザーが Cloud Identity または Google Workspace 内のユーザーに対応しているかを追跡するために使用できる、安定した一意の ID。
  2. ドメインの部分が Cloud Identity のプライマリ ドメイン、セカンダリ ドメイン、またはエイリアス ドメインに相当するメールアドレス。このメールアドレスは Google Cloud 全体で使用されるため、アドレスは人が読んで理解できる必要があります。

内部的には、Azure AD は ObjectId によってユーザーを識別します。ObjectId は、ランダムに生成される、グローバルに一意の ID です。この ID は安定しているため、最初の要件を満たしていますが、人間には理解できず、メールアドレスの形式にも従っていません。ユーザーをマッピングするのに唯一実用的な選択肢は、UPN またはメールアドレスでマッピングすることです。

メールアドレスによるユーザーのマッピング。

ユーザーが、Azure AD でシングル サインオンを使用するように構成された Cloud Identity アカウントまたは Google Workspace アカウントに属するメールアドレスを入力すると、Azure AD ログイン画面にリダイレクトされます。

Azure AD ではユーザーを識別するためにメールアドレスではなく UPN を使用します。したがって、Azure AD ログイン画面では UPN を入力するよう求められます。

UPN の入力を求めるログイン画面

Azure AD テナントが AD FS を使用してログインするように構成されている場合、ユーザーはさらに AD FS ログイン画面にリダイレクトされます。AD FS は、Active Directory UPN または Windows 2000 より前のログオン名(domain\user)でユーザーを識別できます。

AD FS のログイン画面

Cloud Identity や Google Workspace で使用するメールアドレス、Azure AD が使用する UPN、Active Directory で使用する UPN がすべて異なる場合、一連のログイン画面によりエンドユーザーが混乱する可能性があります。一方、サンプルのスクリーンショット(johndoe@example.com)のように、3 つの ID すべてが同じである場合、ユーザーは UPN とメールアドレスの技術的な相違に気づかないため、ユーザーが混乱する可能性を最小限に抑えることができます。

UPN によるマッピング

ユーザー エクスペリエンスの観点から、Azure AD UPN は、Cloud Identity または Google Workspace のメールアドレスにマッピングすることをおすすめします。また、UPN を使用するもう 1 つの利点は、Azure AD が一意性を保証するため、名前の競合リスクを回避できることです。

ただし、Azure AD の UPN を Cloud Identity のメールアドレスにマッピングするには、次の要件を満たす必要があります。

  • Google Cloud から送信される通知メールがユーザーのメールボックスに正しく配信されるように、Azure AD UPN を有効なメールアドレスにする必要があります。有効なメールアドレスでない場合は、GCP から送信されるメールをユーザーが受信できるよう、エイリアスのメールアドレスを構成します。
  • Azure AD 内のすべての関連ユーザーの UPN では、サフィックス(user@custom-domain)としてカスタム ドメインを使用する必要があります。Azure AD の初期ドメイン(user@tenant.onmicrosoft.com)を使用する UPN は、Cloud Identity のメールアドレスにはマッピングできません。これは、初期ドメインは管理者自身が所有しているのではなく、Microsoft が所有しているためです。
  • Azure AD で UPN に使用するすべてのカスタム ドメインが Cloud Identity にも登録されていること。この要件は、ドメイン検証を行うために、該当する DNS ゾーンへのアクセス権が必要であることを意味します。Azure AD でドメイン所有権を確認するために作成した既存の TXT DNS レコードをオーバーライドするのを回避するには、Cloud Identity で CNAME レコードを使用してドメイン所有権を確認できます。

メールアドレスによるユーザーのマッピング

Azure AD UPN を Cloud Identity や Google Workspace のメールアドレスにマッピングするという選択肢がない場合は、メールアドレスでユーザーをマッピングできます。

Active Directory でメールアドレスを指定すると、そのアドレスが各 user オブジェクトの mail 属性に保存され、Azure AD Connect によって値が Azure AD の Mail 属性に同期されます。Cloud Identity または cloudid_name_short のメールアドレスにこの属性をマッピングできるように、Azure AD では、ユーザーのプロビジョニングにこの属性も使用できます。

重要なことに、Azure AD の Mail 属性は現在 Azure ポータルには表示されず、API または PowerShell でのみ表示および編集できます。ユーザー インターフェースではメールアドレスと予備のメールアドレスを指定できますが、いずれの値も Mail 属性に格納されないため、Cloud Identity や cloudid_name_short へのプロビジョニングには使用できません。 このことから、メールアドレスでユーザーをマッピングすることが適切な手段になるのは、ユーザーの作成と編集作業の大部分を Azure AD ではなく Active Directory で行う場合に限られます。

メールアドレスでユーザーをマッピングするには、さらに次の要件も満たす必要があります。

  • メールの割り当てが完了している必要があります。同期の対象となるすべてのユーザーに、メールアドレスが割り当てられている必要があります。特に、ユーザーがオンプレミスの Active Directory から同期されている場合は、mail は Active Directory ではオプションのユーザー属性であるため、このケースに該当しない可能性があります。Azure AD で Mail 属性にメールアドレスがないユーザーは同期中、暗黙的に無視されます。
  • メールアドレスがその Azure AD テナント全体で一意である必要があります。Active Directory はユーザー作成時に一意性を確認しませんが、Azure AD Connect はデフォルトで競合を検出します。そのため、影響を受けるユーザーの同期が失敗する可能性があります。
  • メールアドレスで使用されているドメインが Azure AD に登録されている必要はありませんが、Cloud Identity または Google Workspace には登録されている必要があります。この要件は、ドメイン検証を行うためにそれぞれの DNS ゾーンにアクセスする必要があり、所有していないドメイン(gmail.comなど)でメールアドレスを使用できないことを意味します。

ユーザー ライフサイクルのマッピング

Azure AD のユーザーと Cloud Identity または Google Workspace ユーザーとの間のマッピングを定義した後は、プロビジョニングする一連のユーザーを決める必要があります。この決定については、ID セットのマッピングに関するおすすめの方法をご覧ください。

Azure AD テナントのすべてのユーザーをプロビジョニングしない場合は、ユーザー割り当てまたはスコープ フィルタを使用して、一部のユーザーのプロビジョニングを有効にします。

次の表では、Azure AD のプロビジョニングのデフォルトの動作概要と、ユーザーのプロビジョニングを有効化または無効化することによって、Azure AD が Cloud Identity または Google Workspace でどのアクションを行うかを制御する方法を示します。

Azure AD ユーザーに対してプロビジョニングを有効にする Cloud Identity / Google Workspace のユーザーの状態 Azure AD で行われるアクション Cloud Identity / Google Workspace で行われるアクション
× (存在しない) プロビジョニングを有効にする 新しいユーザーを作成する(*)
× 存在する(有効) プロビジョニングを有効にする 既存のユーザーを更新する
× 存在する(停止中) プロビジョニングを有効にする 既存のユーザーを更新し、停止したままにする
存在する ユーザーを変更する 既存のユーザーを更新する
存在する UPN / メールアドレスの名前を変更する メインのメールアドレスを変更し、以前のアドレスをエイリアスとして保持する
存在する プロビジョニングを無効にする ユーザーはそのままにする
存在する ユーザーを削除する(復元可能) ユーザーを停止する
存在する ユーザーを完全に削除する ユーザーを一時停止して、メールアドレスに del_ 接頭辞を追加する

(*)同じメールアドレスの一般ユーザー向けアカウントが存在する場合、その一般ユーザー向けアカウントは強制排除されます。

グループのマッピング

Active Directory と Google Cloud の連携を計画する際に考慮すべき 4 番目の要素は、Active Directory と Google Cloud の間でグループを同期するかどうかと、グループをマッピングする方法です。

Google Cloud では、複数のプロジェクトで効率的にアクセスを管理する一般的な手段としてグループが使用されます。各プロジェクトで個々のユーザーを IAM のロールに割り当てるのではなく、組織内の共通のロールをモデル化する一連のグループを定義します。それらのグループを一連の IAM ロールに割り当てます。こうすると、グループのメンバーシップを変更するだけで、一連のリソース全体に対するユーザーのアクセス権を制御できます。

Azure AD と Google Cloud 間のグループのマッピングはオプションです。ユーザー プロビジョニングを設定すると、Cloud Identity または Google Workspace で直接グループを作成して管理できます。つまり、Active Directory または Azure AD は、ID 管理の中央システムとして残りますが、Google Cloud のアクセス管理に対してはそうではなくなります。

Active Directory や Azure AD を ID 管理とアクセス管理の中央システムとして維持するには、Cloud Identity や Google Workspace でグループを管理するのではなく、グループを Azure AD から同期することをおすすめします。この方法を使うと、IAM を設定して、Active Directory または Azure AD のグループ メンバーシップを使用することで、Google Cloud のリソースに対するアクセス権を持つユーザーを管理できるようになります。

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 つが使用されている必要があります。

IAM でグループを操作する際に、多くの場合、名前ではなくメールアドレスでグループを指定する必要があります。したがって、グループには意味のある名前を付けるだけでなく、意味のある、かつ認識しやすいメールアドレスを割り当てることをおすすめします。

Azure AD でのグループ

Azure AD ではユースケースに応じた複数の種類のグループをサポートしています。グループは単一のテナントにスコープ設定され、オブジェクト ID によって識別されます。オブジェクト ID は、ランダムに生成される、グローバルに一意の ID です。グループはネストすることができ、同じテナントのユーザー、または Azure B2B を使用して他のテナントから招待されたユーザーのいずれかを含めることができます。Azure AD では、クエリに基づいてメンバーが自動的に決定される動的グループもサポートされます。

Azure AD を Cloud Identity または Google Workspace と統合する場合は、グループの 2 つのプロパティ(メールが有効かどうかと、セキュリティが有効かどうか)が特に重要です。

  • セキュリティが有効なグループは、Azure AD のリソースへのアクセス管理に使用できます。したがって、セキュリティが有効なグループはいずれも、Google Cloud との関連では重要になる可能性があります。
  • メールが有効なグループにはメールアドレスがあります。Cloud Identity と Google Workspace では、グループはメールアドレスで識別される必要があるため、このメールアドレスは重要です。

Azure AD では、セキュリティ タイプのグループと Office 365 タイプのグループ(統合グループとも呼ばれます)を作成できます。オンプレミスの Active Directory からグループを同期する場合、または Office 365 タイプを使用する場合は、配布リストタイプのグループも作成できます。

次の表に、メールが有効であるかという点、セキュリティが有効であるかという点でグループの種類をまとめています。また、Azure AD Connect のデフォルト構成を前提として、Active Directory のグループの種類にどのように対応するかを記載しています。

ソース Active Directory のグループの種類 Azure AD のグループの種類 メールが有効 セキュリティが有効
Azure AD - Office 365 グループ 既定 任意
Azure AD - セキュリティ グループ 任意 既定
オンプレミス セキュリティ グループ(メールあり) セキュリティ グループ
オンプレミス セキュリティ グループ(メールなし) セキュリティ グループ ×
オンプレミス 配布リスト(メールあり) 配布リスト ×
オンプレミス 配布リスト(メールなし) (Azure AD Connect によって無視される)

ユーザーの場合とは異なり、Azure AD はグループに割り当てるメールアドレスに、Azure AD でカスタム ドメインとして登録されているドメインの使用を要件としています。この要件により、デフォルトの動作は次のようになります。

  • Active Directory 内のグループで、Azure AD に登録済みのドメインを使用するメールアドレスを使用している場合、そのメールアドレスは Azure AD との同期中に適切に維持されます。
  • Active Directory 内のグループで、Azure AD に未登録のメールアドレスを使用している場合、Azure AD は同期中に新しいメールアドレスを自動生成します。このメールアドレスには、テナントのデフォルト ドメインが使用されます。テナントがデフォルト ドメインとして初期ドメインを使用している場合、生成されるメールアドレスは [name]@[tenant].onmicrosoft.com の形式になります。
  • Azure AD で Office 365 グループを作成する場合も、Azure AD はテナントのデフォルト ドメインを使用したメールアドレスを自動生成します。

グループ ID のマッピング

Azure AD グループを Cloud Identity や Google Workspace に問題なくマッピングするには、共通の ID が必要で、この ID はメールアドレスである必要があります。Azure AD 側では、この要件に 2 つの選択肢があります。

  • Azure AD 内のグループのメールアドレスを使用して、Cloud Identity や Google Workspace のメールアドレスにマッピングできます。
  • Azure AD のグループ名からメールアドレスを取得し、そのアドレスを Cloud Identity や Google Workspace のメールアドレスにマッピングできます。

メールアドレスによるマッピング

メールアドレスによるグループ マッピングが最も明白な選択ですが、それでもまだ、求められる要件がいくつかあります。

  • 同期の対象とするすべてのグループにメールアドレスが割り当てられていること。これは実際のところ、メールが有効なグループのみ同期が可能であることを意味します。メールアドレスがないグループはプロビジョニング時に無視されます。
  • メールアドレスがそのテナント全体で一意であること。Azure AD では一意性を強制しないため、カスタム チェックまたはポリシーを実装しなければならない場合があります。
  • メールアドレスで使用されているドメインは、Azure AD と Cloud Identity / Google Workspace の両方に登録されている必要があります。tenant.onmicrosoft.com ドメインを含め、Cloud Identity / Google Workspace に登録されていないドメインを使用するメールアドレスを持つグループは、同期に失敗します。

関連するグループのすべてが上記の条件を満たしている場合は、これらのメールアドレスで使用されているドメインを識別し、Cloud Identity や Google Workspace に登録された DNS ドメインのリストによってこれらのドメインがカバーされるようにします。

名前によるマッピング

Cloud Identity や Google Workspace にプロビジョニングするセキュリティ グループの多くでメールが有効になっていない場合、メールアドレスでグループをマッピングするために必要な条件を満たすことは困難です。その場合は、グループの表示名からメールアドレスを自動的に取得することをおすすめします。

メールアドレスの取得には、2 つの問題が伴います。

  1. グループの名前から取得したメールアドレスは、ユーザーのメールアドレスと競合する可能性があります。
  2. Azure AD ではグループ名に一意性を強制しません。Azure AD テナント内の複数のグループが同じ名前を共有している場合、この名前から取得されたメールアドレスが競合し、1 つのグループしか正常に同期されません。

最初の問題を解決するには、生成されたメールアドレスに、ユーザーが使用しているドメインとは異なるドメインを使用します。たとえば、すべてのユーザーがドメインとして example.com のメールアドレスを使用している場合は、すべてのグループに groups.example.com を使用できます。Cloud Identity や Google Workspace にサブドメインを登録する場合は、ドメイン所有権の確認が必要ないため、DNS ゾーン groups.example.com が存在する必要もありせん。

2 つ目の問題であるグループ名の重複を解決するには、技術的にはオブジェクト ID からグループのメールアドレスを派生させるだけです。結果として生成されるグループ名は難解で扱いにくいため、Cloud Identity や Google Workspace へのプロビジョニングを設定する前に、Azure AD で重複するグループ名を特定して名前を変更することをおすすめします。

グループ ライフサイクルのマッピング

Azure AD グループと Cloud Identity または Google Workspace のマッピングを定義した後は、プロビジョニングする一連のグループを決める必要があります。ユーザーと同様に、グループの割り当てスコープ フィルタを使用して、一部のグループのプロビジョニングを有効にします。

次の表では、Azure AD のプロビジョニングのデフォルトの動作概要と、グループのプロビジョニングを有効化または無効化することによって、Azure AD が Cloud Identity や Google Workspace で行う操作を制御する方法を示します。

Azure AD グループに対してプロビジョニングを有効にする Cloud Identity / Google Workspace のグループの状態 Azure AD で行われるアクション Cloud Identity / Google Workspace で行われるアクション
× (存在しない) プロビジョニングを有効にする 新しいグループを作成する
× 存在する プロビジョニングを有効にする メンバーを追加し、すべての既存メンバーは保持する
存在する グループ名を変更する グループ名を変更する
存在する 説明を変更する 説明を更新する
存在する メンバーを追加する メンバーを追加し、すべての既存メンバーは保持する
存在する メンバーを削除する メンバーを削除する
存在する プロビジョニングを無効にする グループはそのままになる(メンバーを含む)
存在する グループを削除する グループはそのままになる(メンバーを含む)

次のステップ