Google Cloud と Azure Active Directory の連携

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

この記事では、Azure AD の論理構造と Cloud Identity および G Suite で使用される構造を比較し、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 または G Suite との間の連携の設定には、次の 2 つのプロセスが必要です。

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

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

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

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

Cloud Identity または G Suite で認証を 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 または G Suite を使用します。Cloud Identity アカウントまたは G Suite アカウントは、ユーザーとグループのプライベート ディレクトリとして機能します。ユーザーはアカウント管理者として、ユーザーとグループのライフサイクルと設定を制御し、認証の実行方法を定義できます。

Google Cloud の論理構造

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

Azure AD と Google Cloud の統合

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

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

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

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

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

単一のテナント

Azure AD テナントを 1 つだけ使用する場合は、テナントを 1 つの Cloud Identity アカウントまたは G Suite アカウントにマッピングし、2 つのアカウント間の連携を設定できます。この Cloud Identity アカウントまたは G Suite アカウントは、すべての Google Cloud リソースの管理に使用できる単一の Google Cloud 組織の基盤となります。

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

複数のテナント

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

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

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

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

外部ユーザー

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

Azure AD から Cloud Identity または G Suite にゲストユーザーをプロビジョニングするには、特定の制限があります。

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

別の Azure AD テナントからのゲストユーザーに対応するより良い方法は、前のセクションで説明したように、複数の Cloud Identity アカウントまたは G Suite アカウントを作成し、それぞれを別の Azure AD テナントと連携することです。

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

DNS ドメインのマッピング

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

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

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

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

GCP での DNS ドメインの使用法

G Suite アカウントまたは Cloud Identity アカウントを登録すると、ログインで認証に使用できるプライベート ディレクトリが作成されます。Gmail ディレクトリが gmail.com ドメインに関連付けられるのと同じように、G Suite アカウントや Cloud Identity アカウントにはカスタム ドメインを関連付ける必要があります。それには次の 3 種類のドメインが使用されます。

  • プライマリ ドメイン: このドメインは Cloud Identity アカウントまたは G Suite アカウントを識別し、Google Cloud で組織の名前として使用されます。Cloud Identity または G Suite に登録する場合、このドメイン名を指定する必要があります。
  • セカンダリ ドメイン: プライマリ ドメインとあわせて、追加のセカンダリ ドメインを Cloud Identity アカウントまたは G Suite アカウントに関連付けることができます。ディレクトリ内の各ユーザーは、プライマリ ドメインまたはセカンダリ ドメインのいずれかに関連付けられます。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 と G Suite が 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 と G Suite は UPN のコンセプトに依存せず、代わりにユーザーのメールアドレスを ID として使用します。そのため、メールアドレスで使用されるドメインは、Cloud Identity アカウントまたは G Suite アカウントの登録済みドメインのいずれかと一致する必要があります。

Azure AD テナントと Cloud Identity アカウントまたは G Suite アカウントは、同じ DNS ドメインを使用できます。上記で説明した 2 つの違いを考慮して、Azure AD と Cloud Identity または G Suite との間のユーザーのマッピング方法の計画に基づいて、ドメイン マッピングを行う必要があります。

ユーザーのマッピング

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

Azure AD ユーザーを Cloud Identity または G Suite のユーザーに正しくマッピングするには、ユーザーごとに次の 2 つの情報が必要です。

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

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

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

Azure AD でシングル サインオンを使用するように構成された Cloud Identity アカウントまたは G Suite アカウントに属するメールアドレスをユーザーが入力すると、そのユーザーは 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 または G Suite で使用するメールアドレス、Azure AD で使用する UPN、Active Directory で使用する UPN がすべて異なる場合、一連のログイン画面によりエンドユーザーが混乱する可能性があります。一方、サンプルのスクリーンショット(johndoe@example.com)のように、3 つの ID すべてが同じである場合、ユーザーは UPN とメールアドレスの技術的な相違に気づかないため、ユーザーの潜在的な混乱を最小限に抑えることができます。

UPN によるマッピング

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

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

  • Google Cloud から送信される通知メールがユーザーのメールボックスに正しく配信されるように、Azure AD UPN を有効なメールアドレスにする必要があります。有効なメールアドレスでない場合は、Google Cloud から送信されるメールをユーザーが受信できるよう、エイリアスのメールアドレスを構成します。
  • 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 または G Suite のメールアドレスにマッピングできない場合は、メールアドレスでユーザーをマッピングできます。

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 または cloudid_name_short に登録されている必要があります。この要件は、ドメイン検証を行うためにそれぞれの DNS ゾーンにアクセスする必要があり、所有していないドメイン(gmail.comなど)でメールアドレスを使用できないことを意味します。

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

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

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

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

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

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

グループのマッピング

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

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

Azure AD と Google Cloud 間のグループのマッピングはオプションです。ユーザーのプロビジョニングを設定すると、Cloud Identity または G Suite でグループの作成と管理を直接行えます。つまり、Active Directory または Azure AD が ID 管理の中心的なシステムとなりますが、Google Cloud のアクセス管理としては中心的なシステムにはなりません。

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

Cloud Identity と G Suite のグループ

Cloud Identity と G Suite では、1 種類のグループしかありません。Cloud Identity と G Suite のグループは、グループが定義された Cloud Identity または G Suite アカウントのスコープに限定されません。代わりに、これらのグループは別の Cloud Identity または G Suite アカウントからのユーザーを含み、他のアカウント内での参照とネストをサポートします。また任意の Google Cloud 組織間での使用も可能です。

ユーザーと同様に、Cloud Identity と G Suite はメールアドレスでグループを識別します。メールアドレスが実際のメールボックスに対応している必要はありません。ただし、メールアドレスには、該当する Cloud Identity アカウントに登録されているドメインのうちの 1 つが使用されている必要があります。

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

Azure AD でのグループ

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

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

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

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 グループまたは G Suite グループに正常にマッピングするには、共通の ID が必要で、この ID はメールアドレスである必要があります。Azure AD 側では、この要件に 2 つの選択肢があります。

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

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

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

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

すべての関連グループが上記の条件を満たしている場合は、これらのメールアドレスで使用されるドメインを識別し、Cloud Identity または G Suite に登録された DNS ドメインのリストにこれらのドメインが含まれていることを確認します。

名前によるマッピング

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

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

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

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

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

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

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

次の表では、Azure AD プロビジョニングのデフォルトの動作が要約されています。また、グループのプロビジョニングを有効または無効にすることで、Azure AD が Cloud Identity または G Suite でどのアクションを行うかを制御する方法を示しています。

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

次のステップ