このドキュメントでは、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 の既存ユーザーに結び付けることができます。
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（GCDS）: Google が無料で提供している、同期プロセスを実装するツールです。GCDS はセキュア ソケットレイヤ（SSL）を使用して Google Cloud と通信します。通常、このツールは既存のコンピューティング環境内で稼働します。
- Active Directory フェデレーション サービス（AD FS）: Microsoft が Windows Server の一部として提供しているコンポーネントです。AD FS の利用により、Active Directory を使用した連携認証が可能になります。通常、AD FS は既存のコンピューティング環境内で稼働します。
Google Cloud 用の API は一般公開されていること、さらに SAML はオープン標準であることから、さまざまなツールを使用して連携を実装できます。このドキュメントでは、GCDS と AD FS の使用を中心に説明します。
Active Directory の論理構造
Active Directory インフラストラクチャの最上位コンポーネントはフォレストです。フォレストは 1 つ以上のドメインを含むコンテナとして機能します。フォレストには、フォレスト ルートドメインにちなんだ名前が付けられます。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 アカウントは、ユーザーとグループのプライベート ディレクトリとして機能します。ユーザーはアカウント管理者として、ユーザーとグループのライフサイクルと設定を制御し、認証の実行方法を定義できます。
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 つの GCDS インスタンスを実行するだけで対処できます。
単一フォレスト、複数ドメイン
フォレストに複数の Active Directory ドメインが含まれている場合、それらのドメインを 1 つ以上のドメインツリーで編成できます。どちらの場合も、フォレスト全体を 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにマッピングできます。このアカウントを 1 つの Google Cloud 組織の管理単位として使用して、Google Cloud リソースを管理できます。
マルチドメイン環境では、ドメイン コントローラから取得できる情報と、グローバル カタログ サーバーに対するクエリによって取得できる情報には違いがあります。ドメイン コントローラから取得できるのは、そのドメイン コントローラが処理するローカル ドメイン内のデータだけです。一方、グローバル カタログ サーバーはフォレストに含まれるすべてのドメイン内の情報へのアクセスを提供します。重要な点として、グローバル カタログ サーバーから提供されるデータは部分的なものであり、特定の LDAP 属性が欠落しています。この制限は、グループを同期するように GCDS を構成する方法に影響を与える場合があります。
グループのマッピングに予定している方法によっては、マルチドメイン フォレストを Google Cloud と連携させるためには、1 つ以上の GCDS インスタンスを実行する一方、シングル サインオンについては単一の AD FS インスタンスまたはフリートで処理しなければならない場合があります。
フォレスト間の信頼がある複数のフォレスト
大規模な組織では、合併や買収の結果、複数の Active Directory フォレストが存在することは珍しくありません。こうした複数のフォレストを結合するには、双方向でのフォレスト間の信頼を使用します。これにより、ユーザーが各フォレストの境界を超えてリソースの共有またはアクセスを行うことができます。
すべてのフォレストに他のフォレストとの双方向の信頼関係がある場合は、その環境全体を 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにマッピングできます。このアカウントを 1 つの Google Cloud 組織の管理単位として使用して、Google Cloud リソースを管理できます。
グローバル カタログ サーバーは複数のドメイン内のデータへのアクセスを提供しますが、そのスコープは単一のフォレストに制限されます。マルチ フォレスト環境では、たとえばユーザーの完全なリストを取得するには複数のドメイン コントローラまたは複数のグローバル カタログ サーバーに対してクエリを行う必要があります。この制限により、マルチフォレスト環境を Google Cloud と連携させるには、フォレストごとに少なくとも 1 つの GCDS インスタンスが必要になります。フォレスト間の信頼を使用すれば、フォレストの境界を超えてユーザー認証が機能するため、シングル サインオンを処理するには単一の AD FS インスタンスまたはフリートがあれば十分です。
フォレスト間の信頼がない複数のフォレストにまたがる環境でも、Google Cloud との連携に関連するすべての Active Directory ドメインが外部の信頼を介して接続されている場合は、上記と同じ考慮事項が適用されます。
フォレスト間の信頼がない複数のフォレスト
上の図に示されている環境では、フォレストの境界を超えて認証を行ったりリソースにアクセスすることは不可能です。また、単一の AD FS インスタンスまたはフリートですべてのフォレストからのユーザー シングル サインオン リクエストを処理することもできません。
したがって、フォレスト間に信頼がない複数のフォレストを 1 つの Cloud Identity アカウントまたは Google Workspace アカウントにマッピングすることはできません。代わりに、各フォレストを別々の Cloud Identity アカウントまたは Google Workspace アカウントにマッピングする必要があります。それには、フォレストごとに少なくとも 1 つの GCDS インスタンスと、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.local、corp.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 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 レコードが必要です。これにより、該当するドメイン名を使用して生成されたメールアドレスへ送信されるメッセージを適切に配信できます。
ディレクトリ間の同期を有効にするには、Active Directory ドメインと、Cloud Identity または Google Workspace が使用するドメインとの間でなんらかのマッピングが必要です。適切なマッピングの決定は、Active Directory の使用方法によって異なります。またその決定には、Active Directory フォレスト内のユーザーの識別方法と Cloud Identity または Google Workspace へのマッピング方法の精査も必要になります。
ユーザーをマッピングする
Active Directory と Google Cloud の連携を計画する際に考慮すべき 3 番目の要素は、Active Directory と Cloud Identity または Google Workspace との間のユーザーのマッピング方法です。
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<var>userの形式で結合したものです（例:corp\johndoe）。これらの名前はレガシーとみなされますが、今でも一般的に使用されていて、ユーザーに唯一必須の識別子となっています。
注意する点として、Active Directory ではユーザーの識別にユーザーのメールアドレス（mail）を使用しません。したがって、このフィールドは必須でもなければ、フォレスト内で一意にする必要もありません。
これらの識別子はいずれも随時、変更できます。
ユーザー ID をマッピングする
Active Directory ユーザーを Cloud Identity ユーザーまたは Google Workspace ユーザーにマッピングするには、ユーザーごとに次の 2 つの情報が必要です。
- どの Active Directory ユーザーが Cloud Identity または Google Workspace 内のユーザーに対応しているかを同期中に追跡するために使用できる、安定した一意の ID。AD 側でこの目的を果たすのに最適な ID は、
objectGUIDです。 - ドメインの部分が Cloud Identity アカウントまたは Google Workspace アカウントのプライマリ ドメイン、セカンダリ ドメイン、またはエイリアス ドメインに相当するメールアドレス。このメールアドレスは Google Cloud 全体で使用されるため、意味のあるアドレスであることを確認してください。
objectGUIDからアドレスを派生させるという方法は実際的ではありません。他の方法で自動的に生成されるメールアドレスにしても同じことです。
Active Directory ユーザーの場合、userPrincipalName フィールドと mail フィールドが、Cloud Identity または Google Workspace のメールアドレスを提供する候補になります。
ユーザー プリンシパル名でマッピングする
userPrincipalName フィールドを使用する場合、同期の対象となるすべてのユーザーが次の 2 つの条件を満たす必要があります。
- ユーザー プリンシパル名（UPN）は有効なメールアドレスにする必要があります。また、UPN サフィックス ドメインとして使用されているすべてのドメインが MX ドメインであり、かつ、ユーザーの UPN に送信されるメールがそのユーザーのメール受信トレイに配信されるように設定されていることも必要です。
UPN 割り当てが完了している必要があります。同期の対象となるすべてのユーザーに UPN を割り当てる必要があります。UPN が割り当てられていないユーザーを調べるには、次の PowerShell コマンドが役立ちます。
Get-ADUser -LDAPFilter "(!userPrincipalName=*)"
以上の 2 つの条件が満たされていれば、UPN を Cloud Identity または Google Workspace のメールアドレスに安全にマッピングできます。Cloud Identity や Google Workspace では、UPN サフィックス ドメインのいずれかをプライマリ ドメインとして使用し、他の UPN サフィックス ドメインをセカンダリ ドメインとして追加できます。
いずれかの条件が満たされていない場合でも、UPN を Cloud Identity や Google Workspace のメールアドレスにマッピングできますが、次の注意事項があります。
- UPN が有効なメールアドレスでなければ、ユーザーは Google Cloud から送信される通知メールを受け取れません。それによって、ユーザーが重要な情報を見逃す可能性があります。
- UPN が割り当てられていないユーザーは、同期の際に無視されます。
- UPN サフィックス ドメインを別のドメインに置き換えるように同期を構成できます。ただし、フォレスト内で複数の UPN サフィックス ドメインを使用している場合、この方法を採ると、すべての UPN サフィックス ドメインが単一のドメインで置き換えられるため、重複が生じる可能性があります。ユーザーが重複している場合、そのうち 1 つのユーザーしか同期されません。
UPN を使用してユーザーをマッピングする主な利点として、UPN はフォレスト全体で一意であることが保証されています。また、UPN はキュレートされたドメインのセットを使用するため、潜在的な同期の問題を回避するのに役立ちます。
メールアドレスでマッピングする
mail フィールドを使用する場合、同期の対象となるすべてのユーザーが次の条件を満たす必要があります。
メールの割り当てが完了している必要があります。同期の対象となるすべてのユーザーの
mailフィールドに値が入力されている必要があります。このフィールドに値が入力されていないユーザーを調べるには、次の PowerShell コマンドが役立ちます。Get-ADUser -LDAPFilter "(!mail=*)"
キュレートされたドメインのセットをメールアドレスで使用していて、それらのドメインのすべてを自分が所有していること。ユーザーの中にパートナー会社や消費者向けメール プロバイダを参照するメールアドレスを使用しているものがある場合、それらのメールアドレスは使用できません。
すべてのメールアドレスがフォレスト全体で一意であること。Active Directory では一意性を強制しないため、カスタム チェックまたはポリシーを実装しなければならない場合があります。
関連するすべてのユーザーが上記の条件を満たしている場合は、これらのメールアドレスで使用されているすべてのドメインを識別し、Cloud Identity または Google Workspace でプライマリ ドメインまたはセカンダリ ドメインとして使用できます。
いずれかの条件が満たされていない場合でも、メールアドレスを Cloud Identity や Google Workspace のメールアドレスにマッピングできますが、次の点に注意してください。
- 同期中にメールアドレスがないユーザーは無視されます。また、メールアドレスがあるユーザーでも、Cloud Identity アカウントまたは Google Workspace アカウントに関連付けられていないドメインを使用しているユーザーも同様に無視されます。
- 2 つのユーザーが同じメールアドレスを共有している場合、いずれか 1 つのユーザーだけが同期されます。
- メールアドレスのドメインを別のドメインに置き換えるように同期を構成できます。ただし、このプロセスによって重複が生じる可能性があります。その場合、重複するユーザーのうち、いずれか 1 つだけが同期されます。
グループをマッピングする
Active Directory と Google Cloud の連携を計画する際に考慮すべき 4 番目の要素は、Active Directory と Google Cloud の間でグループを同期するかどうか、同期する場合はどのようにグループをマッピングするかです。
Google Cloud では、複数のプロジェクトで効率的にアクセスを管理する一般的な手段としてグループを使用できます。各プロジェクトで個々のユーザーを IAM のロールに割り当てるのではなく、組織内の共通のロールをモデル化したグループを定義して、そのグループを一連の IAM のロールに割り当てます。グループのメンバーシップを変更することで、一連のリソース全体に対するユーザーのアクセス権を制御できます。
Active Directory では、配信グループとセキュリティ グループという 2 種類のグループを区別しています。配信グループは、メールリストを管理するために使用されます。Microsoft Exchange から Google Workspace に移行する場合、GCDS が通常の配信グループと動的配信グループの両方を処理できるように、配信グループを同期する必要があります。ただし、配信グループは、Google Cloud の Identity and Access Management では重要でないため、ここでは、セキュリティ グループについてのみ説明します。
Active Directory と Google Cloud の間でのグループのマッピングはオプションです。ユーザー プロビジョニングを設定すると、Cloud Identity や Google Workspace 内でグループを直接作成して管理できます。つまり、Active Directory は、ID 管理に関しては中央システムであり続けますが、アクセス管理に関してはそうではなくなります。Active Directory を ID 管理とアクセス管理の中央システムとして維持するには、セキュリティ グループを Cloud Identity や Google Workspace で管理するのではなく、Active Directory から同期することをおすすめします。このアプローチでは、Active Directory 内のグループ メンバーシップを使用して IAM を設定すれば、Google Cloud 内の特定のリソースにアクセスするユーザーを制御できるようになります。
Active Directory 内のセキュリティ グループ
セキュリティ グループは、Windows セキュリティと Active Directory アクセス管理の基礎としての役割を果たします。この役割を補完するために、Active Directory にはドメイン ローカル グループ、グローバル グループ、ユニバーサル グループという 3 種類のグループがあります。
- ドメイン ローカル グループ
- これらのグループが関連するのは単一ドメインのスコープ内のみです。したがって、他のドメインで参照できません。ドメイン ローカル グループのメンバーリストをフォレスト全体でレプリケートする必要はないため、グループに含めることができるメンバーのタイプという点では、最も柔軟性のあるグループです。
- グローバル グループ
- これらのグループは他のドメインに対して表面化されるため、他のドメインでも参照できます。ただし、メンバーリストはレプリケートされません。この制限により、これらのグループには限られたタイプのメンバーしか含めることができません。これらのグループに含めることができるのは、同じドメイン内のユーザーと他のグローバル グループのみです。
- ユニバーサル グループ
- これらのグループは、そのメンバーリストとあわせてフォレスト全体でレプリケートされます。したがって、他のドメインで参照できるだけでなく、これらのグループにはユーザーと他のユニバーサル グループに加え、すべてのドメインのグローバル グループを含めることもできます。
Active Directory フォレストに 1 つのドメインしか含まれていなければ、GCDS を使用して上記の 3 種類すべてのセキュリティ グループを同期できます。Active Directory フォレストで複数のドメインを使用する場合、グループの種類によって、そのグループを Cloud Identity または Google Workspace と同期できるかどうかが決まります。
ドメイン ローカル グループとグローバル グループはフォレスト全体で完全にはレプリケートされないため、グローバル カタログ サーバーに格納されるこれらのグループに関する情報は不完全です。これは意図的な制限で、ディレクトリ レプリケーションの高速化には役立ちますが、このようなグループを Cloud Identity または Google Workspace と同期する場合は障害となります。具体的には、グローバル カタログ サーバーをソースとして使用するように GCDS を構成すると、このツールはフォレスト全体ですべてのドメインからグループを検出できます。ただし、メンバーリストが含まれていてレプリケーションに適切なグループは、グローバル カタログ サーバーと同じドメイン内にあるグループだけです。マルチドメイン フォレスト内のドメイン ローカル グループやグローバル グループを同期させるには、ドメインごとに個別の GCDS インスタンスを実行する必要があります。
ユニバーサル グループはフォレスト全体で完全にレプリケートされるため、こうした制限はありません。1 つの GCDS インスタンスで複数のドメイン内にあるユニバーサル グループを同期できます。
複数の Active Directory ドメインを Cloud Identity または Google Workspace に同期するために複数の GCDS インスタンスが必要であると結論付ける前に、すべてのグループを同期する必要がない場合があるので注意してください。このことから、Active Directory フォレスト全体で各種のセキュリティ グループが一般にどのように使用されているかを調べる価値はあります。
Active Directory でのセキュリティ グループの使用法
以降のセクションでは、Active Directory で使用されるセキュリティ グループのタイプについて説明します。
リソース グループ
Windows ではアクセス制御リスト（ACL）ベースのアクセスモデルを使用しています。ファイルや LDAP オブジェクトなどのリソースごとに、そのリソースにアクセスできるユーザーを制御する ACL が関連付けられます。リソースと ACL はかなり細分化されることから、ACL はかなりの数に上ります。したがって、ACL の保守を簡素化するために、「リソース グループ」を作成して使用頻度やアクセス頻度が高いリソースをまとめるのが一般的です。リソース グループを関連する ACL に追加した後は、ACL を変更するのではなく、リソース グループのメンバーシップを変更するだけでアクセスを管理できます。
このようにまとめられるリソースは、一般に単一のドメイン内にあります。このことから、リソース グループは 1 つのドメイン内のみで ACL または他のリソース グループで参照される傾向があります。ほとんどのリソース グループはローカルであるため、通常は Active Directory 内でドメイン ローカル グループを使用して実装されます。
ロールグループと組織グループ
リソース グループはアクセス管理を簡素化するのに役立ちますが、大規模な環境では多数のリソース グループに新しいユーザーを追加しなければならない場合があります。このことから、リソース グループは一般に「ロールグループ」または「組織グループ」によって補完されます。
ロールグループは、組織内での特定のロールに必要な権限を集約したものです。たとえば、エンジニアリング ドキュメント閲覧者という名前のロールグループは、すべてのエンジニアリング ドキュメントに対する読み取り専用アクセス権限をメンバーに付与します。実際には、ロールグループを作成し、そのロールグループを各種のドキュメントへのアクセス制御に使用するすべてのリソース グループのメンバーにすることでこれを実現します。
同様に、組織グループは組織内の部門に必要な権限を集約したものです。たとえば、エンジニアリングという名前の組織グループは、エンジニアリング部門のメンバーが共通して必要とするすべてのリソースへのアクセス権限を付与します。
技術的には、ロールグループとリソース グループの間に違いはなく、一般的にこの 2 つは同時に使用されます。ただし、ロールグループと組織グループはリソース グループとは異なり、ドメインの境界を超えた関連性を持つことができます。ロールグループや組織グループを他のドメイン内のリソース グループで参照できるようにするために、これらのグループは通常、グローバル グループを使用して実装されます。このように実装されるグループのメンバーは 1 つのドメインのメンバーに制約されます。場合によっては、別のドメインからのメンバーを許容できるよう、ユニバーサル グループで補完されることもあります。
次の図は、マルチドメイン Active Directory 環境で一般的に使用されるネストパターンを示しています。
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 つが使用されている必要があります。
Active Directory グループとは異なり、Cloud Identity や Google Workspace のグループのメンバーには、同じグループの他のメンバーを一覧表示する権限が暗黙的には付与されません。グループ メンバーシップのクエリを行うには、通常、明示的な承認が必要となります。
Google Cloud でのグループの使用法
Google Cloud では ACL ベースのアクセスモデルではなくロールベースのアクセスモデルを使用しています。ロールは、特定のスコープ内にある特定の種類のすべてのリソースに適用されます。たとえば、Kubernetes Engine デベロッパーのロールには、特定のプロジェクトのすべてのクラスタに含まれる Kubernetes API オブジェクトに対する完全アクセス権が許可されます。ロールの性質上、Google Cloud 上でリソース グループを保守する必要はほとんどありません。さらに、リソース グループを Google Cloud に同期する必要もめったにありません。
ロールグループと組織グループは多数のユーザーのアクセスを管理しやすくするためのものであることから、Google Cloud でも Active Directory での場合と同じ関連性があります。ロールグループと組織グループを同期すると、Active Directory を主要なアクセス管理システムとして維持するのに役立ちます。
リソース グループをドメイン ローカル グループとして、役割グループと組織グループをグローバル グループまたはユニバーサル グループとして一貫して実装すると、グループタイプに基づいて役割グループと組織グループだけを確実に同期できます。
マルチドメイン フォレストごとに 1 つの GCDS インスタンスを実行するだけで十分なのか、あるいは複数の GCDS インスタンスが必要になるのかという問題は、グローバル グループを使用するかどうかという問題になります。ユニバーサル グループを使用してロールグループと組織グループのすべてを実装する場合は、1 つの GCDS インスタンスで十分です。そうでなければ、ドメインごとに GCDS インスタンスが必要になります。
グループ ID をマッピングする
Active Directory のセキュリティ グループを Cloud Identity グループや Google Workspace グループにマッピングするには、共通の ID が必要です。Cloud Identity と Google Workspace では、この ID は、ドメインの部分が Cloud Identity アカウントまたは Google Workspace アカウントの、プライマリ ドメイン、セカンダリ ドメイン、またはエイリアス ドメインに相当するメールアドレスである必要があります。このメールアドレスは Google Cloud 全体で使用されるため、人間が読んで理解できるアドレスでなければなりません。メールアドレスがメールボックスに対応している必要はありません。
Active Directory では、グループを識別するためにグループの共通名（cn）または Windows 2000 以前のログオン名（sAMAccountName）が使用されます。ユーザー アカウントと同様にグループにもメールアドレス（mail）を割り当てることはできますが、グループのメールアドレスはオプションの属性であり、Active Directory は一意性を検証しません。
Active Directory と Cloud Identity または Google Workspace との間でグループ ID をマッピングするには、次の 2 つの方法があります。
共通名でマッピングする
共通名（cn）を使用する利点としては、共有名は可用性が保証されていること、そして少なくとも組織部門内では一意であることが挙げられます。ただし、共有名はメールアドレスではないため、サフィックス（@DOMAIN）を付加してメールアドレスに変換する必要があります。
GCDS は、グループ名へのサフィックスの付加を自動的に処理するように構成できます。Active Directory を使用すると、グループ名とユーザー名が競合しないため、この方法で取得したメールアドレスでも競合が発生する可能性は低くなります。
Active Directory フォレストに複数のドメインが含まれている場合は、次の点に注意してください。
- 異なるドメイン内にある 2 つのグループが共通名を共有している場合、それぞれのグループに生成されるメールアドレスで競合が発生し、同期の際にいずれかのグループが無視されます。
- 単一のフォレストに含まれるドメイン内のグループだけを同期できます。それぞれの個別の GCDS インスタンスを使用して複数のフォレスト内のグループを同期する場合、共通名から生成されるメールアドレスには、その共通名に対応するフォレストが反映されません。この曖昧さにより、GCDS インスタンスは以前に他の GCDS インスタンスによって別のフォレストから作成されたグループを削除します。
- ドメイン置換を使用してユーザーをマッピングしている場合、共通名でグループをマッピングすることはできません。
メールアドレスでマッピングする
メールアドレス（mail）を使用してグループ ID をマッピングするということは、メールアドレスを使用してユーザーをマッピングする場合と同じく、次の条件を満たさなければならないことを意味します。
メールの割り当てが完了している必要があります。配信グループには一般にメールアドレスが割り当てられますが、セキュリティ グループにこの属性が欠落している場合は珍しくありません。メールアドレスを使用して ID をマッピングするには、同期の対象となるセキュリティ グループの
mailフィールドに値が入力されている必要があります。このフィールドに値が入力されていないアカウントを調べるには、次の PowerShell コマンドが役立ちます。Get-ADGroup -LDAPFilter "(!mail=*)"
キュレートされたドメインのセットをメールアドレスで使用していて、それらのドメインのすべてを自分が所有していること。ユーザーの中にパートナー会社や消費者向けメール プロバイダを参照するメールアドレスを使用しているものがある場合、それらのメールアドレスは使用できません。
すべてのメールアドレスがフォレスト全体で一意であること。Active Directory では一意性を強制しないため、カスタム チェックまたはポリシーを実装しなければならない場合があります。
関連するグループのすべてが上記の条件を満たしている場合は、これらのメールアドレスで使用されているすべてのドメインを識別して、Cloud Identity または Google Workspace に登録されている DNS ドメインのリストで該当するドメインがすべて含まれることが保証されます。
いずれかの条件が満たされていない場合でも、UPN を Cloud Identity や Google Workspace のメールアドレスにマッピングできますが、次の点に注意してください。
- 同期中にメールアドレスがないグループは無視されます。また、メールアドレスがあるグループでも、Cloud Identity アカウントまたは Google Workspace アカウントに関連付けられていないドメインを使用している場合は同様に無視されます。
- 2 つのグループが同じメールアドレスを共有している場合、いずれか 1 つのグループだけが同期されます。
Active Directory フォレストに複数のドメインが含まれていて、ドメイン置換を使用してユーザーをマッピングしている場合、メールアドレスでグループをマッピングすることはできません。
組織部門をマッピングする
ほとんどの Active Directory ドメインでは、リソースをクラスタ化して階層構造に編成する際、アクセスを制御する際、ポリシーを適用する際など、組織部門を広く利用します。
Google Cloud ではフォルダとプロジェクトが同じような目的を果たしますが、Google Cloud 組織内で管理されるリソースの種類は Active Directory 内で管理されるリソースとは大幅に異なります。そのため、企業に適切な Google Cloud フォルダ階層は Active Directory での組織部門の構造とは顕著に異なる傾向があります。したがって、組織部門を自動的にフォルダとプロジェクトにマッピングするという方法はほぼ不可能であり、GCDS でもサポートされていません。
フォルダとは無関係に、Cloud Identity と Google Workspace は組織部門のコンセプトをサポートしています。Active Directory の場合と同様に、組織部門はユーザーをクラスタ化して編成するために作成されます。ただし Active Directory での場合とは異なり、組織部門はグループではなくユーザーにのみ適用されます。
GCDS には、Active Directory の組織部門を Cloud Identity や Google Workspace に同期するオプションが用意されています。Active Directory の ID 管理を Google Cloud に拡張するためだけに Cloud Identity を使用するというシナリオでは、通常、組織部門をマッピングする必要はありません。
適切なマッピングを選択する
このドキュメントの冒頭で述べたように、Active Directory と Google Cloud の構造をマッピングする際に、あらゆるシナリオに共通して適用できる最良の方法というものはありません。シナリオに適切なマッピングを選択できるよう、これまでのセクションで説明した条件を以下の決定グラフにまとめます。
まず、次のフローチャートを参照して、必要な Cloud Identity アカウントや Google Workspace アカウント、GCDS インスタンス、AD FS インスタンスまたはフリートの数を特定します。
次に、2 つ目のフローチャートを参照して、Cloud Identity アカウントや Google Workspace アカウントで構成するドメインを特定します。
次のステップ
- アカウントと組織の計画に関するベスト プラクティスと、Google Cloud と外部 ID プロバイダの連携に関するベスト プラクティスを確認する。
- Active Directory のユーザーとグループが Cloud Identity と同期されるように GCDS を構成する。
- Active Directory と Google Cloud 間でのシングル サインオンを構成する。
- 特権管理者アカウントを管理する際のベスト プラクティスを学習する。