将 Google Cloud 与 Active Directory 联合

Last reviewed 2023-02-27 UTC

本文介绍如何配置 Cloud Identity 或 Google Workspace，以使用 Active Directory 作为 IdP 和权威来源。

本文将比较 Active Directory 的逻辑结构与 Cloud Identity 和 Google Workspace 使用的结构，并说明如何映射 Active Directory 林、网域、用户和群组。本文还提供了一个流程图，可帮助您确定最适合您的场景的映射方法。

本文假定您熟悉 Active Directory。

实现联合

Google Cloud 使用 Google 身份进行身份验证和访问权限管理。如果所有员工都已经有 Active Directory 账号，再为每一位员工手动维护 Google 身份将增加不必要的管理开销。通过在 Google Cloud 与您现有的身份管理系统之间联合用户身份，您可以自动维护 Google 身份并将其生命周期与 Active Directory 中的现有用户联系起来。

在 Active Directory 和 Cloud Identity 或 Google Workspace 之间设置联合需要两个步骤：

• 预配用户：相关用户和群组定期从 Active Directory 同步到 Cloud Identity 或 Google Workspace。此过程可确保当您在 Active Directory 中创建新用户时，可以在 Google Cloud 中引用该用户，即使是在关联用户首次登录之前也是如此。此过程还可确保用户删除操作生效。

  预配是单向的，这意味着 Active Directory 中所做的更改将复制到 Google Cloud，但反之则不会。此外，配置不包括密码。在联合设置中，Active Directory 仍然是管理这些凭据的唯一系统。

• 单点登录：每当用户需要进行身份验证时，Google Cloud 都会使用安全断言标记语言 (SAML) 协议将身份验证委派给 Active Directory。此委派确保只有 Active Directory 可管理用户凭据，并且将会实施任何适用的政策或多重身份验证 (MFA) 机制。但是，必须先预配相应的用户，才能登录成功。

为了实现联合，您可以使用以下工具：

• Google Cloud Directory Sync 是 Google 提供的免费工具，可实现同步过程。Google Cloud Directory Sync 通过安全套接字层 (SSL) 与 Google Cloud 通信，通常在现有计算环境中运行。
• Active Directory Federation Services (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 基础架构中，最上层的组成部分是“林” (forest)。林充当一个或多个网域的容器，并从林根网域派生其名称。Active Directory 林中的网域彼此信任，允许在一个网域中进行了身份验证的用户访问另一个网域中的资源。除非使用跨林信任连接林，否则默认情况下，单独的林不会相互信任，并且在一个林中进行身份验证的用户无法访问其他林中的资源。

Active Directory 网域是用于管理资源的容器，被视为管理边界。在一个林中拥有多个网域是简化管理或强制实施其他结构的一种方法，但林中的网域不代表安全边界。

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 的逻辑结构之间存在某些相似之处，但两种结构之间的单一映射并非同样适用于所有场景。相反，集成两个系统和映射结构的正确方法取决于多种因素：

• 如何将网域和林映射到 Cloud Identity 或 Google Workspace 账号
• 如何映射 DNS 网域
• 如何映射用户
• 如何映射群组

以下各部分分别介绍了这些因素。

映射林

您经常使用多个 Active Directory 网域来管理整个企业的身份和访问权限，特别是在大型组织中。当您计划将 Active Directory 与 Google Cloud 联合时，要考虑的第一个因素是 Active Directory 基础架构的拓扑。

单个林、单个网域

当一个林仅包含一个网域时，您可以将整个 Active Directory 林映射到单个 Cloud Identity 或 Google Workspace 账号。 然后，此账号会为单个 Google Cloud 组织提供基础，供您用来管理 Google Cloud 资源。

在单网域环境中，网域控制器和全局目录服务器都提供对在 Active Directory 中管理的所有对象的访问权限。在大多数情况下，您可以运行 Google Cloud Directory Sync 的单个实例，以将用户账号和群组同步到 Google Cloud，并保留单个 AD FS 实例或机群来处理单点登录。

单个林、多个网域

当一个林包含多个 Active Directory 网域时，您可以在一个或多个网域树中组织这些网域。在这两种情况下，您都可以将整个林映射到单个 Cloud Identity 或 Google Workspace 账号。然后，此账号会为单个 Google Cloud 组织提供基础，供您用来管理 Google Cloud 资源。

在多网域环境中，可从网域控制器检索的信息与可从全局目录服务器查询的信息之间存在差异。网域控制器仅提供来自其本地网域的数据，而全局目录服务器则提供对来自林中所有网域的信息的访问权限。很重要的一点是，全局目录服务器提供的数据是部分数据，缺少某些 LDAP 特性。此项限制可能会影响您配置 Google Cloud Directory Sync 以同步群组的方式。

根据您计划映射群组的方式，将多网域林与 Google Cloud 联合需要一个或多个 Google Cloud Directory Sync 实例，但只需要一个 AD FS 实例或机群来处理单点登录。

具有跨林信任的多个林

在较大的组织中，拥有多个 Active Directory 林（通常源自合并或收购）的情况是比较常见的。您可以使用一个双向跨林信任来组合这些林，让用户可以跨单个林的边界共享和访问资源。

如果所有林都与另一个林具有双向信任关系，您可以将整个环境映射到单个 Cloud Identity 或 Google Workspace 账号。此账号会为单个 Google Cloud 组织提供基础，供您用来管理 Google Cloud 资源。

虽然全局目录服务器提供对来自多个网域的数据的访问权限，但其范围仅限于单个林。因此，在多林环境中，您必须查询多个网域控制器或全局目录服务器以获取数据（例如，完整的用户列表）。由于此项限制，如果将多林环境与 Google Cloud 联合，每个林必须至少具有一个 Google Cloud Directory Sync 实例。跨林信任可让用户进行身份验证以跨林边界工作，因此单个 AD FS 实例或机群足以处理单点登录。

如果您的环境跨越多个林而缺少跨林信任，但与联合 Google Cloud 相关的所有 Active Directory 网域都是通过外部信任连接的，则要注意相同的问题。

缺少跨林信任的多个林

在此处显示的环境中，无法跨林边界验证身份或访问资源。单个 AD FS 实例或设备也无法处理所有林的用户的单点登录请求。

因此，无法将缺少跨林信任的多个林映射到单个 Cloud Identity 或 Google Workspace 账号。 每个林必须映射到单独的 Cloud Identity 或 Google Workspace 账号，在此过程中，每个林运行至少一个 Google Cloud Directory Sync 实例和一个 AD FS 服务器或机群。

在 Google Cloud 中，系统会为每个 Cloud Identity 或 Google Workspace 账号创建一个单独的组织。大多数情况下，您不需要维护多个单独的组织。您可以选择其中一个组织并将该组织与其他 Cloud Identity 或 Google Workspace 账号关联，从而有效地创建与多个 Active Directory 林联合的组织。其他组织则保持未使用状态。

映射 DNS 网域

DNS 在 Active Directory 以及 Cloud Identity 和 Google Workspace 中都起着至关重要的作用。计划将 Active Directory 与 Google Cloud 联合时要考虑的第二个因素是如何在 Active Directory 与 Google Cloud 之间共享或映射 DNS 网域。

在 Active Directory 中使用 DNS 网域

在 Active Directory 林中，DNS 网域会在多个位置使用：

• Active Directory DNS 网域：每个 Active Directory 网域对应一个 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 会读取 [e-mail]。但是，您可以将林配置为使用其他 DNS 网域作为 UPN 后缀，这些后缀既不对应于 Active Directory DNS 网域，也不对应于 MX 网域。UPN 是可选的，存储在用户的 userPrincipalName 字段中。
• 端点网域：面向公众的服务器（如 AD FS 服务器）通常会被指定一个 DNS 名称，例如 login.external.example.com。用于这些用途的网域可以与 MX、UPN 后缀或 Active Directory DNS 网域重叠，也可以是完全不同的网域。

在 Google Cloud 中使用 DNS 网域

Google 登录（Google Cloud 依赖其进行身份验证）使用电子邮件地址来识别用户。使用电子邮件地址不仅可以保证用户身份是全局唯一的，还使 Google Cloud 能够向地址发送通知消息。

Google 登录根据电子邮件地址中 @ 后面的网域部分来确定用于验证用户身份的目录或身份提供商。例如，对于使用 gmail.com 网域的电子邮件地址，Google 登录使用 Gmail 用户的目录进行身份验证。

在注册 Google Workspace 或 Cloud Identity 账号时，您将创建一个可供登录用于身份验证的专用目录。Google Workspace 和 Cloud Identity 账号必须与自定义网域关联，具体方式与将 Gmail 目录和 gmail.com 网域关联的方式相同。系统使用了以下三种不同的网域：

• 主网域：此网域可标识 Cloud Identity 或 Google Workspace 账号，也可用作 Google Cloud 中组织的名称。在注册 Cloud Identity 或 Google Workspace 时，您必须指定此域名。
• 辅助网域：您可以将其他辅助网域以及主网域与 Cloud Identity 或 Google Workspace 账号关联。目录中的每个用户都与主网域或其中一个辅助网域关联。如果 example.com 是主域名，secondary.example.com 是辅助域名，则 [e-mail] 和 [e-mail] 这两个用户会被视为单独的用户。
• 别名网域：别名网域是其他网域的备用名称。也就是说，如果 alias.example.com 设置为 example.com 的别名网域，则 [e-mail] 和 [e-mail] 指的是同一用户。

所有网域都必须满足以下要求：

• 它们必须是有效的全局 DNS 域名。在设置过程中，您可能需要拥有相应 DNS 地区的管理员权限才能验证网域所有权。
• 网域（例如 example.com）只能引用单个目录。但是，您可以使用不同的子网域（例如 subdomain.example.com）来引用不同的目录。
• 主网域和辅助网域应具有有效的 MX 记录，这样，如果使用此域名构成电子邮件地址，向其发送的邮件便可以正确递送。

为了能够在目录之间同步，需要在 Active Directory 网域与 Cloud Identity 或 Google Workspace 使用的网域之间进行一些映射。确定正确的映射需要根据您使用 Active Directory 的方式，还需要仔细了解如何在 Active Directory 林中标识用户以及如何将这些用户映射到 Cloud Identity 或 Google Workspace。

映射用户

计划将 Active Directory 与 Google Cloud 联合时要考虑的第三个因素是如何在 Active Directory 与 Cloud Identity 或 Google Workspace 之间映射用户。

在 Active Directory 中标识用户

Active Directory 在内部使用两个标识符来唯一标识用户：

• objectGUID：这是创建用户时生成的全局唯一 ID，永远不会更改。
• objectSID：SID 或安全标识符可用于所有访问检查。虽然这是网域中唯一的 ID，并且很稳定，但是将它移动到林中的其他网域时，系统可能会为用户指定新的 SID。

这些 ID 对用户而言都没有意义，因此 Active Directory 提供了两种易记的方法来标识用户：

• UPN (userPrincipalName)：标识用户的首选方法是使用 UPN。UPN 遵循 RFC 822 格式的电子邮件地址，创建方式是将用户名与 UPN 后缀网域相结合，如 [e-mail] 所示。尽管 UPN 是标识用户的首选方式，但 UPN 是可选的，因此 Active Directory 林中的某些用户可能缺少 UPN。

  虽然普遍认为将 UPN 作为有效的电子邮件地址是最佳做法，但 Active Directory 并未强制执行此做法。

• Windows 2000 之前的登录名 (sAMAccountName)：此名称使用 domain<var>user 格式组合 NetBIOS 域名和用户名，如 corp\johndoe 所示。 尽管这些名称被视为旧式名称，但仍然是通用名称，并且是用户唯一的必需标识符。

值得注意的是，Active Directory 不使用用户的电子邮件地址 (mail) 来标识用户。因此，该字段既不是必填字段，也不必是林中的唯一字段。

所有这些标识符可以随时更改。

映射用户身份

如果要将 Active Directory 用户映射到 Cloud Identity 或 Google Workspace 用户，需要关于每个用户的两条信息：

• 一个稳定的唯一 ID，您可以在同步期间使用该 ID 来跟踪哪个 Active Directory 用户对应于 Cloud Identity 或 Google Workspace 中的哪个用户。在 AD 方面，objectGUID 非常适合此用途。
• 一个电子邮件地址，其网域部分对应于 Cloud Identity 或 Google Workspace 账号的主要、辅助或别名网域。由于此电子邮件地址将在整个 Google Cloud 中使用，因此请确保该地址有意义。从 objectGUID 派生地址不切实际，其他自动生成的电子邮件地址也是如此。

对于 Active Directory 用户，有两个候选字段可用于提供 Cloud Identity 或 Google Workspace 电子邮件地址：userPrincipalName 和 mail。

按用户主体名称映射

如果使用 userPrincipalName 字段，所有要同步的用户必须满足两个条件：

• UPN 必须是有效的电子邮件地址。用作 UPN 后缀网域的所有网域也必须是 MX 网域，并且必须进行设置，以便将发送到用户 UPN 的电子邮件递送到其电子邮件收件箱。

• 指定 UPN 时，所有用户账号都必须拥有 UPN。所有需要同步的用户都必须分配有 UPN。以下 PowerShell 命令可以帮助您查找缺少 UPN 的用户：

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

如果满足这两个条件，您就可以安全地将 UPN 映射到 Cloud Identity 或 Google Workspace 电子邮件地址。您可以使用其中一个 UPN 后缀网域作为 Cloud Identity 或 Google Workspace 中的主网域，并将任何其他 UPN 后缀网域添加为辅助网域。

如果其中一个条件未满足，您仍可以将 UPN 映射到 Cloud Identity 或 Google Workspace 电子邮件地址，但要注意以下事项：

• 如果 UPN 不是有效的电子邮件地址，则用户可能收不到 Google Cloud 发送的通知电子邮件，这可能会导致用户错过重要信息。
• 在同步期间，没有 UPN 的用户会被忽略。
• 您可以配置同步以将 UPN 后缀网域替换为其他网域。当您在林中使用多个 UPN 后缀网域时，此方法可能会创建重复项，因为所有 UPN 后缀网域都将替换为单个网域。如果有重复项，则只能同步一个用户。

使用 UPN 映射用户的一个主要优点是保证 UPN 在整个林中是独一无二的，并且 UPN 使用一组特选网域，这样有助于避免发生潜在的同步问题。

按电子邮件地址映射

如果使用 mail 字段，所有要同步的用户必须满足以下条件：

• 必须填写电子邮件地址字段。所有需要同步的用户都必须填写 mail 字段。以下 PowerShell 命令可以帮助您查找未填写此字段的用户：

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

• 电子邮件地址必须使用一组特选网域，所有这些网域都归您所有。如果您的某些用户使用的是指向合作伙伴公司或消费者电子邮件提供商的电子邮件地址，这些电子邮件地址将无法使用。

• 所有电子邮件地址在整个林中必须是独一无二的。由于 Active Directory 不强制实施唯一性，因此您可能必须实现自定义检查或政策。

如果所有相关用户都符合这些条件，您可以标识这些电子邮件地址使用的所有网域，并将其用作 Cloud Identity 或 Google Workspace 中的主网域和辅助网域。

如果其中一个条件未满足，您仍可以将电子邮件地址映射到 Cloud Identity 或 Google Workspace 电子邮件地址，但要注意以下事项：

• 在同步期间，没有电子邮件地址的用户将被忽略，而且电子邮件地址使用的网域未与 Cloud Identity 或 Google Workspace 账号关联的用户也会被忽略。
• 当两个用户共用同一个电子邮件地址时，只有一个用户会被同步。
• 您可以配置同步以将电子邮件地址的网域替换为其他网域。此过程可能会创建重复项，在这种情况下，只有一个用户会被同步。

映射群组

计划将 Active Directory 与 Google Cloud 联合时要考虑的第四个因素是是否在 Active Directory 与 Google Cloud 之间同步群组以及如何映射这些群组。

在 Google Cloud 中，群组通常用作跨项目高效管理访问权限的方法。您无需在每个项目中为各个用户分配 IAM 角色，您可以定义一组模拟组织中的常见角色的群组，然后为这些群组分配一组 IAM 角色。通过修改群组的成员，您可以控制用户对某一组资源的访问权限。

Active Directory 可区分两种群组：通讯群组和安全群组。通讯群组用于管理电子邮件列表。当您从 Microsoft Exchange 迁移到 Google Workspace 时会涉及同步通讯群组，因此 Google Cloud Directory Sync 可以同时处理常规和动态通讯群组。但是，针对 Google Cloud 的身份和访问权限管理并不涉及通讯群组，因此这里的讨论仅针对安全群组。

可以选择在 Active Directory 与 Google Cloud 之间映射群组。设置用户预配后，您可以直接在 Cloud Identity 或 Google Workspace 中创建和管理群组，这意味着 Active Directory 仍然是身份管理的中央系统，但并不用于访问权限管理。如需将 Active Directory 作为管理身份和管理访问权限的中央系统进行维护，我们建议您从 Active Directory 同步安全群组，而不是在 Cloud Identity 或 Google Workspace 中管理安全群组。通过此方法，您可以设置 IAM，以便在 Active Directory 或 Azure AD 中使用组成员资格来控制谁有权访问 Google Cloud 中的某些资源。

Active Directory 中的安全群组

安全群组在 Windows 安全性和 Active Directory 访问权限管理方面发挥着基础作用。此角色可通过三种不同类型的 Active Directory 群组来实现：网域本地群组、全局群组和通用群组。

网域本地群组

这些群组仅在单个网域的范围内相关，不能被其他网域引用。由于不需要跨林复制其成员列表，因此在可以包含的成员类型方面，网域本地群组最为灵活。

全局群组

这些群组会出现在其他网域中，并且可以被其他网域引用。但是，其成员列表没有被复制。此项限制限定了这些群组可以包含的成员类型。这些群组只能包含同一网域中的用户和其他全局群组。

通用群组

这些群组及其成员列表将在整个林中进行复制。因此，它们可以被其他网域引用，不仅可以包含用户和其他通用群组，还可以包含来自所有网域的全局群组。

如果 Active Directory 林仅包含单个网域，那么您可以通过使用 Google Cloud Directory Sync 来同步这三种类型的安全群组。如果 Active Directory 林使用多个网域，则群组的类型将决定群组是否同步到 Cloud Identity 或 Google Workspace 以及同步方式。

由于网域本地群组和全局群组未在整个林中完全复制，因此全局目录服务器包含有关它们的不完整信息。虽然这项限制是有意设定的，并且有助于加快复制目录的速度，但是当您想要将此类群组同步到 Cloud Identity 或 Google Workspace 时，此限制便成了障碍。具体而言，如果将 Google Cloud Directory Sync 配置为使用全局目录服务器作为源，则该工具将能够跨林在所有网域中查找群组。但只有与全局目录服务器位于同一网域中的群组才会包含成员资格列表，并且适合复制。如需同步多网域林中的网域本地群组或全局群组，您必须为每个网域运行单独的 Google Cloud Directory Sync 实例。

由于通用群组在林中被完全复制，因此没有此项限制。单个 Google Cloud Directory Sync 实例可以同步来自多个网域的通用群组。

在判断您是否需要多个 Google Cloud Directory Sync 实例以将多个 Active Directory 网域同步到 Cloud Identity 或 Google Workspace 之前，请注意并非所有群组都需要同步。因此应该研究一下，通常情况下如何在 Active Directory 林中使用不同类型的安全群组。

在 Active Directory 中使用安全群组

资源群组

Windows 使用基于访问权限控制列表 (ACL) 的访问模型。每个资源（如文件或 LDAP 对象）都有一个关联的 ACL，用于控制哪个用户有权访问该资源。资源和 ACL 非常精细，因此数量很多。为了简化 ACL 的维护，通常会创建资源群组，以打包经常一起使用和访问的资源。您可以一次性将资源群组添加到所有受影响的 ACL，然后进一步管理访问权限（只需更改资源群组的成员，而无需更改 ACL）。

以这种方式捆绑的资源通常位于单个网域中。因此，资源群组也往往仅在单个网域中被引用（在 ACL 中被引用或由其他资源群组引用）。由于大多数资源群组都是本地群组，因此通常使用 Active Directory 中的网域本地群组来实现这些资源群组。

角色和组织群组

资源群组有助于简化访问权限管理，但在大型环境中，您可能需要将新用户添加到大量资源群组。因此，资源群组通常由“角色群组”或“组织群组”进行补充。

角色群组会聚合特定角色在组织中需要的权限。例如，名为 Engineering Documentation Viewer 的角色群组可能会为成员提供对所有工程文档的只读访问权限。在实践中，为了实现此目的，您可以创建一个角色群组，并将其加入所有用于控制文档访问权限的资源群组。

组织群组采用类似的方式聚合组织内的部门所需的权限。例如，名为 Engineering 的组织群组可以授予对工程部门成员通常需要的所有资源的访问权限。

从技术上讲，角色群组和资源群组之间没有区别，而且两者通常可以同时使用。但是，与资源群组不同，角色群组和组织群组可以具有超出网域边界的相关性。为了允许其他网域中的资源群组引用此类群组，角色群组和组织群组通常是通过使用全局群组实现的，这些全局群组局限于单个网域的成员，有时由通用群组补充，从而允许来自不同网域的成员。

下图显示了多网域 Active Directory 环境中常用的嵌套模式。

Cloud Identity 和 Google Workspace 中的群组

在 Cloud Identity 和 Google Workspace 中，只有一种类型的群组。这类群组不限于对其进行了定义的 Cloud Identity 或 Google Workspace 账号的范围。相反，这些群组可以包含不同 Cloud Identity 或 Google Workspace 账号的用户，可以在其他账号中引用和嵌套，也可以在任何 Google Cloud 组织中使用。

与识别用户一样，Cloud Identity 和 Google Workspace 根据电子邮件地址识别群组。电子邮件地址不需要与实际邮箱对应，但必须使用针对相应 Cloud Identity 账号注册的网域之一。

与 Active Directory 群组不同，Cloud Identity 或 Google Workspace 群组的成员未被隐式授予列出同一群组的其他成员的权限。若要查询群组成员资格，通常需要明确授权。

在 Google Cloud 中使用群组

Google Cloud 使用基于角色的访问模型，而不是基于 ACL 的访问模型。角色适用于特定范围内所有特定类型的资源。例如，Kubernetes Engine Developer 角色拥有对给定项目中所有集群内的 Kubernetes API 对象的完整访问权限。由于角色的性质，几乎不需要在 Google Cloud 中维护资源群组，并且不需要将资源群组同步到 Google Cloud。

角色群组和组织群组在 Google Cloud 中的重要性与在 Active Directory 中一样，因为这些群组可让您更轻松地管理大量用户的访问权限。同步角色群组和组织群组有助于将 Active Directory 作为管理访问权限的主要位置进行维护。

如果您始终将资源群组作为网域本地群组实现，将角色群组和组织群组作为全局群组或通用群组实现，则可以使用群组类型来确保只同步角色群组和组织群组。

如果之前的问题是需要为每个多网域林运行单个还是多个 Google Cloud Directory Sync 实例，这个问题现在变成了是否使用全局群组。如果使用通用群组来实现所有角色群组和组织群组，则单个 Google Cloud Directory Sync 实例就足够了；否则，每个网域都需要一个 Google Cloud Directory Sync 实例。

映射群组身份

将 Active Directory 安全群组映射到 Cloud Identity 或 Google Workspace 群组时，需要使用共同的标识符。在 Cloud Identity 和 Google Workspace 中，此标识符必须是网域部分对应于 Cloud Identity 或 Google Workspace 账号的主网域、辅助网域或别名网域的电子邮件地址。由于此电子邮件地址将在整个 Google Cloud 中使用，因此该地址必须直观易记。电子邮件地址不需要与邮箱对应。

在 Active Directory 中，群组由其通用名称 (cn) 或 Windows 2000 之前的登录名 (sAMAccountName) 标识。与用户账号类似，群组也可以具有电子邮件地址 (mail)，但电子邮件地址是群组的可选特性，而 Active Directory 不会验证唯一性。

您可以通过两种方式来映射 Active Directory 与 Cloud Identity 或 Google Workspace 之间的群组身份。

按通用名称映射

使用通用名称 (cn) 的优点是该名称保证可以使用，并且至少在组织单元内是唯一的。但是，通用名称不是电子邮件地址，因此需要附加后缀 @DOMAIN 才能转换为电子邮件地址。

您可以将 Google Cloud Directory Sync 配置为自动将后缀附加到群组名称中。由于 Active Directory 可确保群组名称与用户名称不冲突，因此以这种方式派生的电子邮件地址也不太可能会导致任何冲突。

如果您的 Active Directory 林包含多个网域，则需要注意以下事项：

• 如果不同网域中的两个群组共用一个通用名称，则派生的电子邮件地址将发生冲突，从而导致一个群组在同步期间会被忽略。
• 您只能从单个林的网域中同步群组。如果您使用单独的 Google Cloud Directory Sync 实例同步多个林中的群组，则从通用名称派生的电子邮件地址不会反映它们对应的林。这种歧义将导致 Google Cloud Directory Sync 实例删除之前由另一个 Google Cloud Directory Sync 实例从其他林创建的任何群组。
• 如果使用网域替换来映射用户，则无法按通用名称映射群组。

按电子邮件地址映射

如果使用电子邮件地址 (mail) 映射群组身份，则意味着您必须满足与使用电子邮件地址映射用户时相同的条件：

• 必须填写电子邮件地址字段。虽然通讯群组通常具有电子邮件地址，但安全群组通常缺少此特性。若要使用电子邮件地址映射身份，需要同步的安全群组必须填写 mail 字段。以下 PowerShell 命令可以帮助您查找未填写此字段的账号：

  Get-ADGroup -LDAPFilter "(!mail=*)"

• 电子邮件地址必须使用一组特选网域，所有这些网域都归您所有。如果您的某些用户使用的是指向合作伙伴公司或消费者电子邮件提供商的电子邮件地址，那么您无法使用这些地址。

• 所有电子邮件地址在整个林中必须是独一无二的。由于 Active Directory 不强制实施唯一性，因此您可能必须实现自定义检查或政策。

如果所有相关群组都符合这些条件，您可以标识由这些电子邮件地址使用的所有网域，并确保在 Cloud Identity 或 Google Workspace 中注册的 DNS 网域列表涵盖了这些网域。

如果其中一个条件未满足，您仍可以将 UPN 映射到 Cloud Identity 或 Google Workspace 电子邮件地址，但要注意以下事项：

• 在同步期间，没有电子邮件地址的群组将被忽略，而且电子邮件地址使用的网域未与 Cloud Identity 或 Google Workspace 账号关联的群组也会被忽略。
• 当两个群组共用同一个电子邮件地址时，只有一个群组会被同步。

如果 Active Directory 林包含多个网域，并且您使用网域替换来映射用户，则系统不支持按电子邮件地址映射群组。

映射组织单元

大多数 Active Directory 网域都会广泛使用组织单元，从而以分层方式聚集和整理资源、控制访问权限和实施政策。

在 Google Cloud 中，文件夹和项目的用途相似，尽管在 Google Cloud 组织内管理的资源种类与在 Active Directory 中管理的资源截然不同。因此，企业的相应 Google Cloud 文件夹层次结构往往与 Active Directory 中的组织单元结构有着显著的区别。自动将组织单元映射到文件夹和项目不太现实，并且 Google Cloud Directory Sync 不支持这样做。

Cloud Identity 和 Google Workspace 支持组织单元的概念（与文件夹无关）。系统会创建组织单元，用来聚集和整理用户，这一点类似于 Active Directory。但与 Active Directory 不同的是，它们仅适用于用户，而不适用于群组。

可以使用 Google Cloud Directory Sync 将 Active Directory 组织单元同步到 Cloud Identity 或 Google Workspace。如果在设置后，Cloud Identity 仅用于将 Active Directory 身份管理扩展到 Google Cloud，则通常不需要映射组织单元。

选择正确的映射

正如本文开头所述，没有一种最佳方式来映射 Active Directory 和 Google Cloud 的结构。为了帮助您选择适用于场景的正确映射，以下决策图总结了前几节所讨论的条件。

首先，请参阅下列图表以确定您需要多少个 Cloud Identity 或 Google Workspace 账号、Google Cloud Directory Sync 实例以及 AD FS 实例或机群。

然后参阅第二个图表以确定要在 Cloud Identity 或 Google Workspace 账号中配置的网域。

后续步骤

• 阅读规划账号和组织的最佳做法以及联合 Google Cloud 与外部身份提供商的最佳做法。
• 配置 Google Cloud Directory Sync 以将 Active Directory 用户和群组同步到 Cloud Identity。
• 在 Active Directory 和 Google Cloud 之间配置单点登录。
• 了解管理超级管理员账号的最佳做法