Google Cloud と Active Directory の連携

Last reviewed 2023-02-27 UTC

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

この記事では、Active Directory の論理構造と Cloud Identity と Google Workspace で使用される構造を比較し、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 または Google Workspace との間の連携を設定するには、次の 2 つの手順が必要です。

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

Google Cloud 用の API は一般公開されていること、さらに SAML はオープン標準であることから、さまざまなツールを使用して連携を実装できます。この記事では Google 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 または 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 アカウントのユーザーとグループを参照できます。

Active Directory と Google Cloud の統合

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

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

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

フォレストのマッピング

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

したがって、フォレスト間に信頼がない複数のフォレストを 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにマッピングすることはできません。代わりに、各フォレストは、別々の Cloud Identity アカウントまたは Google Workspace アカウントにマッピングする必要があります。それには、フォレストごとに 1 つ以上の Google Cloud Directory Sync インスタンスと、1 つの AD FS サーバーまたはフリートが稼働している必要があります。

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

DNS ドメインのマッピング

DNS は、Active Directory 内だけでなく、Cloud Identity と Google Workspace に対しても重要な役割を果たします。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 ドメイ