Google Cloud と Active Directory の連携

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

この記事では、Active Directory の論理構造と Cloud Identity および G Suite で使用される構造を比較し、Active Directory のフォレスト、ドメイン、ユーザー、グループをマッピングする方法について説明します。この記事では、シナリオに最適なマッピング方法を決定する際に役立つフローチャートも紹介します。

この記事では、読者が Active Directory について十分に理解していることを前提としています。

連携を実装する

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

Cloud Identity を使用した Active Directory の連携

Active Directory と Cloud Identity または G Suite 間の連携を設定するには、次の 2 つの手順が必要です。

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

    プロビジョニングは一方向に機能します。つまり、Active Directory の変更は Google Cloud に複製されますが、その逆は行われません。また、プロビジョニングにはパスワードは含まれません。連携の設定では、Active Directory が認証情報を管理する唯一のシステムとして維持されます。

  • シングル サインオン: ユーザーの認証が必要な場合は常に、Google Cloud が SAML(Security Assertion Markup Language)プロトコルを使用して Active Directory に認証を委任します。この委任により、Active Directory のみがユーザー認証情報を管理すること、そして該当するポリシーまたは多要素認証(MFA)メカニズムが適用されることが確実になります。ただし、ログインが成功するには、それぞれのユーザーが事前にプロビジョニングされている必要があります。

連携を実装するには、以下のツールを使用できます。

  • Google Cloud Directory Sync: Google が無料で提供している、同期プロセスを実装するツールです。Cloud Directory Sync はセキュア ソケットレイヤ(SSL)を使用して Google Cloud と通信します。通常、このツールは既存のコンピューティング環境内で稼働します。
  • Active Directory フェデレーション サービス(AD FS): Microsoft が Windows Server の一部として提供しているコンポーネントです。AD FS の利用により、Active Directory を使用した連携認証が可能になります。通常、AD FS は既存のコンピューティング環境内で稼働します。

Google Cloud 用の API は一般公開されていること、さらに SAML はオープン標準であることから、さまざまなツールを使用して連携を実装できます。この記事では Cloud Directory Sync と AD FS を使用する場合の方法に焦点を当てます。

Active Directory の論理構造

Active Directory インフラストラクチャの最上位コンポーネントはフォレストです。フォレストは 1 つ以上のドメインを含むコンテナとして機能します。フォレストには、フォレスト ルートドメインにちなんだ名前が付けられます。Active Directory フォレスト内のドメインは互いを信頼し、いずれかのドメインで認証されたユーザーにはフォレスト内の別のドメインにあるリソースへのアクセスを許可します。一方、フォレストについては、フォレスト間の信頼を使用して接続されるのでない限り、個々のフォレストはデフォルトで互いを信頼しません。したがって、あるフォレストで認証されたユーザーでも、別のフォレスト内のリソースにはアクセスできません。

Active Directory のインフラストラクチャ

Active Directory のドメインはリソースを管理するためのコンテナであり、管理上の境界とみなされます。管理の簡素化や他の構造の適用を行うには 1 つのフォレストに複数のドメインを含めるという方法がありますが、フォレスト内のドメインがセキュリティ境界を表すことはありません。

Google Cloud の論理構造

Google Cloud ではすべてのリソースで、組織がコンテナとしての機能を果たします。組織内のリソースは、フォルダやプロジェクトを使用してセグメント化できます。したがって、組織、フォルダ、プロジェクトが Active Directory のドメインと同様の目的を果たします。

Active Directory はユーザーをリソースとして扱うため、ユーザーの管理と認証はドメインに関連付けられます。一方、Google Cloud はサービス アカウントを除き、組織内のユーザーを管理しません。代わりに、Google Cloud は Cloud Identity または G Suite を使用してユーザーを管理します。

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

GCP の論理構造

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

Active Directory と Google Cloud の統合

Active Directory と Google Cloud の論理構造には特定の類似点があるとは言え、これら 2 つの構造をマッピングするのにすべてのシナリオで共通して適用できる最良の方法というものはありません。2 つのシステムを統合して構造をマッピングする際の正しいアプローチは、次の複数の要素によって左右されます。

  • ドメインとフォレストを Cloud Identity または G Suite アカウントにマッピングする方法
  • DNS ドメインをマッピングする方法
  • ユーザーをマッピングする方法
  • グループをマッピングする方法

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

フォレストのマッピング

特に大規模な組織では、企業全体の ID とアクセスを管理するために、複数の Active Directory ドメインを使用する場合がよくあります。Active Directory と Google Cloud の連携を計画する際に最初に考慮すべき要素は、Active Directory インフラストラクチャのトポロジです。

単一フォレスト、単一ドメイン

単一フォレスト、単一ドメイン

フォレストに含まれるドメインが 1 つだけの場合、Active Directory フォレスト全体を 1 つの Cloud Identity または G Suite アカウントにマッピングできます。このアカウントを 1 つの Google Cloud 組織の管理単位として使用して、Google Cloud リソースを管理できます。

単一ドメイン環境では、ドメイン コントローラとグローバル カタログ サーバーの両方が、Active Directory 内で管理されているすべてのオプジェクトへのアクセスを提供します。ほとんどの場合、ユーザー アカントとグループを Google Cloud に同期するにも、シングル サインオンを処理する単一の AD FS インスタンスまたはフリートを保守するにも、1 つの Cloud Directory Sync インスタンスを実行するだけで対処できます。

単一フォレスト、複数ドメイン

単一フォレスト、複数ドメイン

フォレストに複数の Active Directory ドメインが含まれている場合、それらのドメインを 1 つ以上のドメインツリーで編成できます。どちらの場合も、フォレスト全体を 1 つの Cloud Identity または G Suite アカウントにマッピングできます。このアカウントを 1 つの Google Cloud 組織の管理単位として使用して、Google Cloud リソースを管理できます。

マルチドメイン環境では、ドメイン コントローラから取得できる情報と、グローバル カタログ サーバーに対するクエリによって取得できる情報には違いがあります。ドメイン コントローラから取得できるのは、そのドメイン コントローラが処理するローカル ドメイン内のデータだけです。一方、グローバル カタログ サーバーはフォレストに含まれるすべてのドメイン内の情報へのアクセスを提供します。重要な点として、グローバル カタログ サーバーから提供されるデータは部分的なものであり、特定の LDAP 属性が欠落しています。この制限は、グループを同期するように Cloud Directory Sync を構成する方法に影響を与える場合があります。

グループのマッピングに予定している方法によっては、マルチドメイン フォレストを Google Cloud と連携させるためには、1 つ以上の Cloud Directory Sync インスタンスを実行する一方、シングル サインオンについては単一の AD FS インスタンスまたはフリートで処理しなければならない場合があります。

フォレスト間の信頼がある複数のフォレスト

フォレスト間の信頼がある複数のフォレスト

大規模な組織では、合併や買収の結果、複数の Active Directory フォレストが存在することは珍しくありません。こうした複数のフォレストを結合するには、双方向でのフォレスト間の信頼を使用します。これにより、ユーザーが各フォレストの境界を超えてリソースの共有またはアクセスを行うことができます。

すべてのフォレストに別のフォレストとの双方向の信頼関係がある場合、環境全体を 1 つの Cloud Identity または G Suite アカウントにマッピングできます。このアカウントを 1 つの Google Cloud 組織の管理単位として使用して、Google Cloud リソースを管理できます。

グローバル カタログ サーバーは複数のドメイン内のデータへのアクセスを提供しますが、そのスコープは単一のフォレストに制限されます。したがってマルチ フォレスト環境では、たとえばユーザーの完全なリストを取得するには複数のドメイン コントローラまたは複数のグローバル カタログ サーバーに対してクエリを行う必要があります。この制限により、マルチ フォレスト環境を Google Cloud と連携させるには、フォレストごとに少なくとも 1 つの Cloud Directory Sync インスタンスが必要になります。フォレスト間の信頼を使用すれば、フォレストの境界を超えてユーザー認証が機能するため、シングル サインオンを処理するには単一の AD FS インスタンスまたはフリートがあれば十分です。

フォレスト間の信頼がない複数のフォレストにまたがる環境でも、Google Cloud との連携に関連するすべての Active Directory ドメインが外部の信頼を介して接続されている場合は、上記と同じ考慮事項が適用されます。

フォレスト間の信頼がない複数のフォレスト

フォレスト間の信頼がない複数のフォレスト

上の図に示されている環境では、フォレストの境界を超えて認証を行ったりリソースにアクセスすることは不可能です。また、単一の AD FS インスタンスまたはフリートですべてのフォレストからのユーザー シングル サインオン リクエストを処理することもできません。

そのため、フォレスト間の信頼がない複数のフォレストを 1 つの Cloud Identity または G Suite アカウントにマッピングすることはできません。代わりに、各フォレストを別個の Cloud Identity アカウントにマッピングする必要があります。それには、フォレストごとに少なくとも 1 つの Cloud Directory Sync インスタンスと少なくとも 1 つの AD FS サーバーまたはフリートを実行しなければなりません。

Google Cloud では、Cloud Identity アカウントまたは G Suite アカウントごとに個別の組織が作成されます。ほとんどの場合、ユーザーが複数の異なる組織を保守する必要はありません。いずれかの組織を選択しそれを他の Cloud Identity または G Suite アカウントと関連付けることで、複数の Active Directory フォレストと連携する組織を作成できます。選択した以外の組織は未使用のままになります。

DNS ドメインのマッピング

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

Active Directory での DNS ドメインの使用法

Active Directory フォレストでは、次のようにさまざまなところで DNS ドメインが使用されます。

  • Active Directory DNS ドメイン: 各 Active Directory ドメインが 1 つの DNS ドメインに相当します。このドメインは、おそらくはグローバル ドメイン(corp.example.com など)ですが、ローカル ドメイン名(corp.localcorp.internal など)である場合もあります。
  • メール交換(MX)ドメイン: メールアドレスで DNS ドメインが使用されます。このドメインは Active Directory DNS ドメインと同じであることもありますが、通常は異なり、多くの場合は短縮されたドメイン(example.com など)が使用されます。Active Directory のユーザーには、オプションの mail 属性に関連付けられたメールアドレスが割り当てられていることが理想的です。
  • UPN サフィックス ドメイン: これらのドメインはユーザー プリンシパル名(UPN)に使用されます。デフォルトでは、ユーザーのドメインの Active Directory DNS ドメインが UPN の構築に使用されます。たとえば corp.example.com ドメイン内のユーザー john の UPN はデフォルトで john@corp.example.com となります。ただし、Active Directory DNS ドメインにも MX ドメインにも相当しない別の DNS ドメインを UPN サフィックスとして使用するようにフォレストを構成することもできます。UPN はオプションで、ユーザーの userPrincipalName フィールドに格納されます。
  • エンドポイント ドメイン: 通常、AD FS サーバーなどの一般公開されるサーバーには DNS 名(login.external.example.com など)が割り当てられます。こうした目的で使用されるドメインは、MX、UPN サフィックス、または Active Directory DNS ドメインと重複する場合も、まったく異なるドメインである場合もあります。

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

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

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

Google Cloud での 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 レコードが必要です。これにより、該当するドメイン名を使用して生成されたメールアドレスへ送信されるメッセージを適切に配信できます。

ディレクトリ間の同期を有効にするには、Active Directory ドメインと Cloud Identity または G Suite が使用するドメインとの間になんらかのマッピングが必要です。適切なマッピングの決定は、Active Directory の使用方法によって異なります。また決定には、Active Directory フォレスト内のユーザーの識別方法と Cloud Identity または G Suite へのマッピング方法の検討も必要になります。

ユーザーのマッピング

Active Directory と Google Cloud の連携を計画する際に考慮すべき 3 番目の要素は、Active Directory と Cloud Identity または G Suite をどのようにマッピングするかです。

Active Directory 内のユーザーを識別する

Active Directory では、ユーザーを一意に識別するために内部で 2 つの識別子が使用されます。

  • objectGUID: これはグローバルに一意の ID で、ユーザーの作成時に生成されます。この ID が変更されることはありません。
  • objectSID: この SID(セキュリティ識別子)は、すべてのアクセス チェックで使用されます。この ID がドメイン内で安定した一意の ID でも、フォレスト内の別のドメインに移動したときにユーザーは新しい SID を割り当てられる可能性があります。

ユーザーにとっては、上記の ID はいずれも意味を持ちません。そのため、Active Directory では人間がユーザーを識別しやすいように 2 つの識別手段を用意しています。

  • UPN(userPrincipalName): ユーザーを識別するのに推奨される手段は UPN です。UPN は RFC 822 形式のメールアドレスを遵守しており、ユーザー名と UPN サフィックス ドメインを結合して作成されます(例: johndoe@corp.example.com)。UPN はユーザーを識別するのに推奨される手段ではありますが、これはオプションであるため、Active Directory フォレスト内のユーザーによっては UPN がない可能性もあります。

    UPN を有効なメールアドレスにすることがベスト プラクティスとみなされていますが、Active Directory ではこの手法を強制していません。

  • Windows 2000 以前のログオン名(sAMAccountName): このログオン名は、NetBIOS ドメイン名とユーザー名を domain\user の形式で結合したものです(例: corp\johndoe)。これらの名前はレガシーとみなされますが、今でも一般的に使用されていて、ユーザーに唯一必須の識別子となっています。

注意する点として、Active Directory ではユーザーの識別にユーザーのメールアドレス(mail)を使用しません。したがって、このフィールドは必須でもなければ、フォレスト内で一意にする必要もありません。

これらの識別子はいずれも随時、変更できます。

ユーザー ID のマッピング

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

  • どの Active Directory ユーザーが Cloud Identity または G Suite のどのユーザーに対応するかを同期中に追跡するために使用できる、安定した一意の ID。AD 側でこの目的を果たすのに最適な ID は、objectGUID です。
  • ドメイン部分が Cloud Identity または G Suite アカウントのプライマリ ドメイン、セカンダリ ドメイン、またはエイリアス ドメインに相当するメールアドレス。このメールアドレスは Google Cloud 全体で使用されるため、意味のあるアドレスであることを確認してください。objectGUID からアドレスを派生させるという方法は実際的ではありません。他の方法で自動的に生成されるメールアドレスにしても同じことです。

Active Directory ユーザーのフィールドのうち、Cloud Identity または G Suite メールアドレスを提供する候補となるのは userPrincipalNamemail の 2 つです。

ユーザー プリンシパル名によるマッピング

userPrincipalName フィールドを使用する場合、同期の対象となるすべてのユーザーが次の 2 つの条件を満たす必要があります。

  • UPN が有効なメールアドレスであること。また、UPN サフィックス ドメインとして使用されているすべてのドメインが MX ドメインであり、かつ、ユーザーの UPN に送信されるメールがそのユーザーのメール受信トレイに配信されるように設定されていることも必要です。
  • UPN 割り当てが完了していること。同期の対象となるすべてのユーザーに UPN を割り当てる必要があります。UPN が割り当てられていないユーザーを調べるには、次の PowerShell コマンドが役立ちます。

    Get-ADUser -LDAPFilter "(!userPrincipalName=*)"

以上の 2 つの条件が満たされていれば、UPN を問題なく Cloud Identity または G Suite メールアドレスにマッピングできます。いずれかの UPN サフィックス ドメインを Cloud Identity または G Suite のプライマリ ドメインとして使用し、もう一方の UPN サフィックス ドメインをセカンダリ ドメインとして追加できます。

いずれかの条件が満たされない場合でも、UPN を Cloud Identity または G Suite のメールアドレスにマッピングできますが、次の点に注意してください。

  • UPN が有効なメールアドレスでなければ、ユーザーは Google Cloud から送信される通知メールを受け取れません。それによって、ユーザーが重要な情報を見逃す可能性があります。
  • UPN が割り当てられていないユーザーは、同期の際に無視されます。
  • UPN サフィックス ドメインを別のドメインに置き換えるように同期を構成できます。ただし、フォレスト内で複数の UPN サフィックス ドメインを使用している場合、この方法を採ると、すべての UPN サフィックス ドメインが単一のドメインで置き換えられるため、重複が生じる可能性があります。ユーザーが重複している場合、そのうち 1 つのユーザーしか同期されません。

UPN を使用してユーザーをマッピングする主な利点として、UPN はフォレスト全体で一意であることが保証されています。また、UPN はキュレートされたドメインのセットを使用するため、潜在的な同期の問題を回避するのに役立ちます。

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

mail フィールドを使用する場合、同期の対象となるすべてのユーザーが次の条件を満たす必要があります。

  • メールの割り当てが完了している必要があります。同期の対象となるすべてのユーザーの mail フィールドに値が入力されている必要があります。このフィールドに値が入力されていないユーザーを調べるには、次の PowerShell コマンドが役立ちます。

    Get-ADUser -LDAPFilter "(!mail=*)"
  • キュレートされたドメインのセットをメールアドレスで使用していて、それらのドメインのすべてを自分が所有していること。ユーザーの中にパートナー会社や消費者向けメール プロバイダを参照するメールアドレスを使用しているものがある場合、それらのメールアドレスは使用できません。

  • すべてのメールアドレスがフォレスト全体で一意であること。Active Directory では一意性を強制しないため、カスタム チェックまたはポリシーを実装しなければならない場合があります。

関連するグループのすべてが上記の条件を満たしている場合、これらのメールアドレスで使用されるすべてのドメインを識別し、Cloud Identity または G Suite のプライマリ ドメインとセカンダリ ドメインとして使用できます。

いずれかの条件が満たされない場合でも、メールアドレスを Cloud Identity または G Suite のメールアドレスにマッピングできますが、次の点に注意してください。

  • 同期中にメールアドレスを持たないユーザーは無視されます。また、Cloud Identity や G Suite アカウントに関連付けられていないドメインを使用するユーザーも同様です。
  • 2 つのユーザーが同じメールアドレスを共有している場合、いずれか 1 つのユーザーだけが同期されます。
  • メールアドレスのドメインを別のドメインに置き換えるように同期を構成できます。ただし、このプロセスによって重複が生じる可能性があります。その場合、重複するユーザーのうち、いずれか 1 つだけが同期されます。

グループのマッピング

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

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

Active Directory では、配信グループとセキュリティ グループという 2 種類のグループを区別しています。配信グループは、メールリストを管理するために使用されます。Microsoft Exchange から G Suite に移行する場合、Cloud Directory Sync が通常の配信グループと動的配信グループの両方を処理できるよう、配信グループを同期する必要があります。ただし、Google Cloud の ID およびアクセス管理では、配信グループは重要ではありません。したがって、ここではセキュリティ グループについてのみ説明します。

Azure AD と Google Cloud 間のグループのマッピングはオプションです。ユーザー プロビジョニングを設定すると、Cloud Identity または G Suite でグループを直接作成、管理できるようになります。つまり、Active Directory はアクセス管理を除く ID 管理の中心的なシステムとして維持されます。Active Directory を ID 管理とアクセス管理の中心的なシステムとして維持するには、Cloud Identity や G Suite による管理ではなく、Active Directory からセキュリティ グループを同期することをおすすめします。このアプローチでは、Active Directory 内のグループ メンバーシップを使用して Cloud IAM を設定すれば、Google Cloud 内の特定のリソースにアクセスするユーザーを制御できるようになります。

Active Directory 内のセキュリティ グループ

セキュリティ グループは、Windows セキュリティと Active Directory アクセス管理の基礎としてのロールを果たします。このロールを補完するために、Active Directory にはドメイン ローカル グループ、グローバル グループ、ユニバーサル グループという 3 種類のグループがあります。

AD でのセキュリティ グループ

ドメイン ローカル グループ
これらのグループが関連するのは単一ドメインのスコープ内のみです。したがって、他のドメインで参照できません。ドメイン ローカル グループのメンバーリストをフォレスト全体でレプリケートする必要はないため、グループに含めることができるメンバーのタイプという点では、最も柔軟性のあるグループです。
グローバル グループ
これらのグループは他のドメインに対して表面化されるため、他のドメインでも参照できます。ただし、メンバーリストはレプリケートされません。この制限により、これらのグループには限られたタイプのメンバーしか含めることができません。これらのグループに含めることができるのは、同じドメイン内のユーザーと他のグローバル グループのみです。
ユニバーサル グループ
これらのグループは、そのメンバーリストとあわせてフォレスト全体でレプリケートされます。したがって、他のドメインで参照できるだけでなく、これらのグループにはユーザーと他のユニバーサル グループに加え、すべてのドメインのグローバル グループを含めることもできます。

Active Directory フォレストに 1 つのドメインしか含まれていなければ、Cloud Directory Sync を使用して上記の 3 種類すべてのセキュリティ グループを同期できます。Active Directory フォレストで複数のドメインを使用している場合、グループの種類によって、そのドメインが Cloud Identity または G Suite と同期できるかどうかが決まります。

ドメイン ローカル グループとグローバル グループはフォレスト全体で完全にはレプリケートされないため、グローバル カタログ サーバーに格納されるこれらのグループに関する情報は不完全です。これは意図的な制限で、ディレクトリ レプリケーションの高速化には役立ちますが、このようなグループを Cloud Identity または G Suite と同期する場合は障害となります。具体的には、グローバル カタログ サーバーをソースとして使用するように Cloud Directory Sync を構成すると、このツールはフォレスト全体ですべてのドメインからグループを検出できます。ただし、メンバーリストが含まれていてレプリケーションに適切なグループは、グローバル カタログ サーバーと同じドメイン内にあるグループだけです。マルチドメイン フォレスト内のドメイン ローカル グループやグローバル グループを同期させるには、ドメインごとに個別の Cloud Directory Sync インスタンスを実行する必要があります。

ユニバーサル グループはフォレスト全体で完全にレプリケートされるため、こうした制限はありません。1 つの Cloud Directory Sync インスタンスで複数のドメイン内にあるユニバーサル グループを同期できます。

複数の Cloud Directory Sync インスタンスでは、複数の Active Directory ドメインを Cloud Identity または G Suite に同期する必要があると判断する前に、必ずしもすべてのグループを同期する必要がないことに注意してください。このことから、Active Directory フォレスト全体で各種のセキュリティ グループが一般にどのように使用されているかを調べる価値はあります。

Active Directory でのセキュリティ グループの使用法

リソース グループ

Windows ではアクセス制御リスト(ACL)ベースのアクセスモデルを使用しています。ファイルや LDAP オブジェクトなどのリソースごとに、そのリソースにアクセスできるユーザーを制御する ACL が関連付けられます。リソースと ACL はかなり細分化されることから、ACL はかなりの数に上ります。したがって、ACL の保守を簡素化するために、「リソース グループ」を作成して使用頻度やアクセス頻度が高いリソースをまとめるのが一般的です。リソース グループを関連する ACL に追加した後は、ACL を変更するのではなく、リソース グループのメンバーシップを変更するだけでアクセスを管理できます。

このようにまとめられるリソースは、一般に単一のドメイン内にあります。このことから、リソース グループは 1 つのドメイン内のみで ACL または他のリソース グループで参照される傾向があります。ほとんどのリソース グループはローカルであるため、通常は Active Directory 内でドメイン ローカル グループを使用して実装されます。

ロールグループと組織グループ

リソース グループはアクセス管理を簡素化するのに役立ちますが、大規模な環境では多数のリソース グループに新しいユーザーを追加しなければならない場合があります。このことから、リソース グループは一般に「ロールグループ」または「組織グループ」によって補完されます

ロールグループは、組織内での特定のロールに必要な権限を集約したものです。たとえば、エンジニアリング ドキュメント閲覧者という名前のロールグループは、すべてのエンジニアリング ドキュメントに対する読み取り専用アクセス権限をメンバーに付与します。実際には、ロールグループを作成し、そのロールグループを各種のドキュメントへのアクセス制御に使用するすべてのリソース グループのメンバーにすることでこれを実現します。

同様に、組織グループは組織内の部門に必要な権限を集約したものです。たとえば、エンジニアリングという名前の組織グループは、エンジニアリング部門のメンバーが共通して必要とするすべてのリソースへのアクセス権限を付与します。

技術的には、ロールグループとリソース グループの間に違いはなく、一般的にこの 2 つは同時に使用されます。ただし、ロールグループと組織グループはリソース グループとは異なり、ドメインの境界を超えた関連性を持つことができます。ロールグループや組織グループを他のドメイン内のリソース グループで参照できるようにするために、これらのグループは通常、グローバル グループを使用して実装されます。このように実装されるグループのメンバーは 1 つのドメインのメンバーに制約されます。場合によっては、別のドメインからのメンバーを許容できるよう、ユニバーサル グループで補完されることもあります。

次の図は、マルチドメイン Active Directory 環境で一般的に使用されるネストパターンを示しています。

マルチドメイン AD 環境で使用されるネストパターン

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

Active Directory でのグループとは異なり、Cloud Identity または G Suite でのグループのメンバーには、同じグループの他のメンバーを一覧表示する権限が暗黙的に付与されません。グループ メンバーシップのクエリを行うには、通常、明示的な承認が必要となります。

Google Cloud でのグループの使用法

Google Cloud では ACL ベースのアクセスモデルではなくロールベースのアクセスモデルを使用しています。ロールは、特定のスコープ内にある特定の種類のすべてのリソースに適用されます。たとえば、Kubernetes Engine デベロッパーのロールには、特定のプロジェクトのすべてのクラスタに含まれる Kubernetes API オブジェクトに対する完全アクセス権が許可されます。ロールの性質上、Google Cloud 上でリソース グループを保守する必要はほとんどありません。さらに、リソース グループを Google Cloud に同期する必要もめったにありません。

ロールグループと組織グループは多数のユーザーのアクセスを管理しやすくするためのものであることから、Google Cloud でも Active Directory での場合と同じ関連性があります。ロールグループと組織グループを同期すると、Active Directory を主要なアクセス管理システムとして維持するのに役立ちます。

ロールグループと組織グループの同期

リソース グループをドメイン ローカル グループとして、ロールグループと組織グループをグローバル グループまたはユニバーサル グループとして一貫して実装すると、グループタイプに基づいてロールグループと組織グループだけを確実に同期できます。

マルチドメイン フォレストごとに 1 つの Cloud Directory Sync インスタンスを実行するだけで十分なのか、あるいは複数の Cloud Directory Sync インスタンスが必要になるのかという質問は、グローバル グループを使用するかどうかという質問になります。ユニバーサル グループを使用してロールグループと組織グループのすべてを実装する場合は、1 つの Cloud Directory Sync インスタンスで十分です。そうでなければ、ドメインごとに Cloud Directory Sync インスタンスが必要になります。

グループ ID のマッピング

Active Directory のセキュリティ グループを Cloud Identity または G Suite のグループにマッピングするには、共通識別子が必要です。Cloud Identity と G Suite では、この識別子は、ドメイン部分が Cloud Identity または G Suite アカウントのプライマリ、セカンダリ、エイリアス ドメインに相当するメールアドレスである必要があります。このメールアドレスは Google Cloud 全体で使用されるため、人間が読んで理解できるアドレスでなければなりません。メールアドレスがメールボックスに対応している必要はありません。

Active Directory では、グループを識別するためにグループの共通名(cn)または Windows 2000 以前のログオン名(sAMAccountName)が使用されます。ユーザー アカウントと同様にグループにもメールアドレス(mail)を割り当てることはできますが、グループのメールアドレスはオプションの属性であり、Active Directory は一意性を検証しません。

Active Directory と Cloud Identity または G Suite の間でグループ ID をマッピングするには、2 つのオプションがあります。

共通名によるマッピング

共通名(cn)を使用する利点としては、共有名は可用性が保証されていること、そして少なくとも組織部門内では一意であることが挙げられます。ただし、共有名はメールアドレスではないため、サフィックス(@[DOMAIN])を付加してメールアドレスに変換する必要があります。

Cloud Directory Sync は、グループ名へのサフィックスの付加を自動的に処理するように構成できます。Active Directory を使用すると、グループ名とユーザー名が競合しないため、この方法で取得したメールアドレスでも競合が発生する可能性は低くなります。

Active Directory フォレストに複数のドメインが含まれている場合は、次の点に注意してください。

  • 異なるドメイン内にある 2 つのグループが共通名を共有している場合、それぞれのグループに生成されるメールアドレスで競合が発生し、同期の際にいずれかのグループが無視されます。
  • 単一のフォレストに含まれるドメイン内のグループだけを同期できます。それぞれの個別の Cloud Directory Sync インスタンスを使用して複数のフォレスト内のグループを同期する場合、共通名から生成されるメールアドレスには、その共通名に対応するフォレストが反映されません。この曖昧さにより、Cloud Directory Sync インスタンスは以前に他の Cloud Directory Sync インスタンスによって別のフォレストから作成されたグループを削除します。
  • ドメイン置換を使用してユーザーをマッピングしている場合、共通名でグループをマッピングすることはできません。

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

メールアドレス(mail)を使用してグループ ID をマッピングするということは、メールアドレスを使用してユーザーをマッピングする場合と同じく、次の条件を満たさなければならないことを意味します。

  • メールの割り当てが完了している必要があります。配信グループには一般にメールアドレスが割り当てられますが、セキュリティ グループにこの属性が欠落している場合は珍しくありません。メールアドレスを使用して ID をマッピングするには、同期の対象となるセキュリティ グループの mail フィールドに値が入力されている必要があります。このフィールドに値が入力されていないアカウントを調べるには、次の PowerShell コマンドが役立ちます。

    Get-ADGroup -LDAPFilter "(!mail=*)"
  • キュレートされたドメインのセットをメールアドレスで使用していて、それらのドメインのすべてを自分が所有していること。ユーザーの中にパートナー会社や消費者向けメール プロバイダを参照するメールアドレスを使用しているものがある場合、それらのメールアドレスは使用できません。

  • すべてのメールアドレスがフォレスト全体で一意であること。Active Directory では一意性を強制しないため、カスタム チェックまたはポリシーを実装しなければならない場合があります。

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

いずれかの条件が満たされない場合でも、UPN を Cloud Identity または G Suite のメールアドレスにマッピングできますが、次の点に注意してください。

  • メールアドレスのないグループは同期の際に無視されます。Cloud Identity や G Suite アカウントに関連付けられていないドメインを使用するメールアドレスも同様です。
  • 2 つのグループが同じメールアドレスを共有している場合、いずれか 1 つのグループだけが同期されます。

Active Directory フォレストに複数のドメインが含まれていて、ドメイン置換を使用してユーザーをマッピングしている場合、メールアドレスでグループをマッピングすることはできません。

組織部門のマッピング

ほとんどの Active Directory ドメインでは、リソースをクラスタ化して階層構造に編成する際、アクセスを制御する際、ポリシーを適用する際など、組織部門を広く利用します。

Google Cloud ではフォルダとプロジェクトが同じような目的を果たしますが、Google Cloud 組織内で管理されるリソースの種類は Active Directory 内で管理されるリソースとは大幅に異なります。そのため、企業に適切な Google Cloud フォルダ階層は Active Directory での組織部門の構造とは顕著に異なる傾向があります。したがって、組織部門を自動的にフォルダとプロジェクトにマッピングするという方法はほぼ不可能であり、Cloud Directory Sync でもサポートされていません。

Cloud Identity と G Suite では、フォルダとは無関係に組織部門のコンセプトをサポートしています。Active Directory の場合と同様に、組織部門はユーザーをクラスタ化して編成するために作成されます。ただし Active Directory での場合とは異なり、組織部門はグループではなくユーザーにのみ適用されます。

Cloud Directory Sync には、Active Directory の組織部門を Cloud Identity または G Suite に同期するオプションが用意されています。Active Directory の ID 管理を Google Cloud に拡張するためだけに Cloud Identity を使用するというシナリオでは、通常、組織部門をマッピングする必要はありません。

正しいマッピングを選択する

この記事の冒頭で述べたように、Active Directory と Google Cloud の構造をマッピングする際に、あらゆるシナリオに共通して適用できる最良の方法というものはありません。シナリオに適切なマッピングを選択できるよう、これまでのセクションで説明した条件を以下の決定グラフにまとめます。

まず、次のチャートを参照して、必要な Cloud Identity または G Suite アカウントの数、Cloud Directory Sync インスタンスの数、AD FS インスタンスまたはフリートの数を特定します。

必要なフリートまたはインスタンスの数を判断するための決定グラフ

次に、2 番目のチャートを参照して、Cloud Identity または G Suite アカウントに構成するドメインを特定します。

意思決定グラフ

次のステップ