将 Google Cloud 与 Active Directory 联合:简介

本文是由多篇文章组成的系列文章中的第一篇。该系列文章讨论如何将基于 Active Directory 的现有身份管理解决方案扩展到 Google Cloud。本文介绍了如何在混合计算环境中建立一致的身份验证和授权机制,重点讲解了如何使用 Cloud Identity,但部分讨论内容适用于 G Suite

该系列包含以下部分:

企业 IT 部门通常依靠 Active Directory 来管理用户帐号并控制对应用和计算资源的访问权限。因此,Active Directory 成为其 IT 环境和本地基础架构的基石。

在实现混合策略的过程中将现有 IT 环境扩展到 Google Cloud 时,您需要在一个地方管理所有身份。拥有单一身份管理解决方案可以最大限度地减少管理工作量,并有助于确保用户和应用可以在混合环境中安全地进行身份验证。

本文将比较 Active Directory 和 GCP 的逻辑结构,并讨论如何将 Active Directory 帐号映射到 GCP 中的用户和群组帐号以实现联合。我们在本文的末尾提供了一个流程图,可帮助您针对使用场景确定在 Active Directory 与 GCP 之间进行映射的最佳方法。

本文假定您熟悉 Active Directory。

实现联合

Google Cloud 使用 Google 身份进行身份验证和访问权限管理。对于任何 Google Cloud 资源的访问都要求员工必须拥有 Google 身份。如果所有员工在 Active Directory 中都拥有帐号,手动维护每位员工的 Google 身份将非常麻烦。通过在 Active Directory 与 Google Cloud 之间联合用户身份,您可以自动维护 Google 帐号并将其生命周期与 Active Directory 中的帐号相结合。实现联合有助于确保达成以下目标:

  • Active Directory 仍然是进行身份管理的唯一可靠来源。
  • 对于 Active Directory 中的所有用户帐号或所选的部分帐号,系统将自动创建 Google 帐号。
  • 如果在 Active Directory 中停用或删除了某个帐号,则相应的 Google 帐号也会被暂停或删除。相反,暂停或删除 Google 帐号对 Active Directory 没有影响,因为系统会在下次同步期间自动重新创建 Google 帐号。
  • Active Directory 可处理用户身份验证,因此您无需将密码同步到 Google Cloud。

在 Google 方面,您可以使用 Cloud Identity 设置私人用户帐号目录,以便在其中创建和管理 Google 帐号。将 Active Directory 与 Cloud Identity 联合需要执行两个步骤:

将 Active Directory 与 Cloud Identity 联合

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

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

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

为了实现联合,您可以使用以下工具:

  • Google Cloud Directory Sync 是 Google 提供的免费工具,可实现同步过程。Cloud Directory Sync 通过安全套接字层 (SSL) 与 Cloud Identity 通信,通常在现有计算环境中运行。
  • Active Directory Federation Services (AD FS) 由 Microsoft 作为 Windows Server 的一部分提供。借助 AD FS,您可以使用 Active Directory 进行联合身份验证。AD FS 通常在现有计算环境中运行。

由于 Cloud Identity 的 API 是公开提供的,并且 SAML 是开放标准,因此可以使用多种工具来实现联合。本文重点介绍如何使用 Cloud Directory Sync 和 AD FS。

Active Directory 的逻辑结构

在 Active Directory 基础架构中,最上层的组成部分是“林” (forest)。林充当一个或多个网域的容器,并从林根网域派生其名称。Active Directory 林中的网域彼此信任,允许在一个网域中进行了身份验证的用户访问另一个网域中的资源。除非使用跨林信任连接林,否则默认情况下,单独的林不会相互信任,并且在一个林中进行身份验证的用户无法访问其他林中的资源。

Active Directory 基础架构

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

Google Cloud 的逻辑结构

在 Google Cloud 中,您可以管理组织中的资源,还可以使用文件夹和项目进一步将这些资源细分。因此,组织、文件夹和项目的用途类似于 Active Directory 网域。

Active Directory 将用户帐号视为资源,因此用户帐号管理和身份验证与网域相关联。相反,除服务帐号外,Google Cloud 自身不管理组织中的用户帐号,而是依靠 Cloud Identity 或 G Suite 来管理。

使用 Cloud Identity,您可以为用户帐号和群组创建和管理专用目录。其中的每个目录都是独立管理的,例如,其允许的身份验证方法或其强制实施的密码政策各不相同。在 Cloud Identity 中,目录被称为 Cloud Identity 帐号,由域名标识。

GCP 身份基础架构

与林和林根网域在 Active Directory 中始终一前一后地创建的方式类似,Cloud Identity 帐号与 Google Cloud 组织始终以并行方式创建。正如林根网域与林共用相同的名称并且不能彼此分离一样,Cloud Identity 帐号与 Google Cloud 组织也共用相同的名称,并且彼此关联。但是,Google Cloud 组织可以从其他 Cloud Identity 帐号引用用户和群组。

将 Active Directory 与 Google Cloud 集成

尽管 Active Directory 与 Google Cloud 的逻辑结构之间存在某些相似之处,但两种结构之间的单一映射并非同样适用于所有场景。相反,整合两个系统和映射结构的正确方法取决于多种因素:

  • 如何将网域和林映射到 Cloud Identity 帐号
  • 如何映射 DNS 网域
  • 如何映射用户帐号
  • 如何映射群组

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

映射林

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

单个林、单个网域

单个林、单个网域

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

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

单个林、多个网域

单个林、多个网域

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

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

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

具有跨林信任的多个林

具有跨林信任的多个林

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

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

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

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

缺少跨林信任的多个林

缺少跨林信任的多个林

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

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

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

映射 DNS 网域

DNS 在 Active Directory 和 Cloud Identity 中都起着至关重要的作用。计划将 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.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但是,您可以将林配置为使用其他 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 用户帐号的目录进行身份验证。

在 GCP 中使用 DNS 网域

在注册 G SuiteCloud Identity 帐号时,您实际上是在创建一个可供 Google Identity Platform 用于身份验证的专用目录。G Suite 和 Cloud Identity 帐号必须与自定义网域关联,具体方式与将 Gmail 目录和 gmail.com 网域关联的方式相同。系统使用了以下三种不同的网域:

  • 主网域:此网域可标识 Cloud Identity 目录,也可用作 Google Cloud 中组织的名称。在注册 Cloud Identity 时,您需要指定此域名。
  • 辅助网域:您可以将其他辅助网域以及主网域与 Cloud Identity 目录关联。目录中的每个帐号都与主网域或其中一个辅助网域关联。因此,如果 example.com 是主网域,secondary.example.com 是目录的辅助网域,则 johndoe@example.comjohndoe@secondary.example.com 这两个帐号将被视为单独的帐号。
  • 别名网域:别名网域是主网域的备用网域。也就是说,如果 alias.example.com 设置为别名网域,则 johndoe@example.comjohndoe@alias.example.com 指的是同一帐号。别名网域只能为主网域提供备用名称;无法为辅助网域添加别名网域。

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

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

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

映射用户帐号

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

在 Active Directory 中标识用户帐号

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

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

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

  • UPN (userPrincipalName):标识用户帐号的首选方法是使用 UPN。UPN 遵循 RFC 822 格式的电子邮件地址,创建方式是将用户名与 UPN 后缀网域相结合,如 johndoe@corp.example.com 所示。尽管 UPN 是标识用户帐号的首选方式,但 UPN 是可选的,因此 Active Directory 林中的某些用户帐号可能缺少 UPN。

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

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

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

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

映射帐号身份

对于每个用户帐号,需要两条信息才能将 Active Directory 帐号映射到 Cloud Identity 帐号:

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

在 Active Directory 用户帐号中,有两个候选字段可用于提供 Cloud Identity 电子邮件地址:userPrincipalNamemail

按用户主体名称映射

如果使用 userPrincipalName 字段,所有要同步的帐号必须满足两个条件:

  • UPN 必须是有效的电子邮件地址。用作 UPN 后缀网域的所有网域也必须是 MX 网域,并且必须进行设置,以便将发送到用户 UPN 的电子邮件递送到其电子邮件收件箱。
  • 指定 UPN 时,所有用户帐号都必须拥有 UPN。必须为所有要同步的用户帐号指定一个 UPN。以下 PowerShell 命令可以帮助您查找缺少 UPN 的帐号:

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

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

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

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

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

按电子邮件地址映射

如果使用 mail 字段,所有要同步的帐号必须满足以下条件:

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

    Get-ADUser -LDAPFilter "(!mail=*)"
  • 电子邮件地址必须使用一组特选网域,所有这些网域都归您所有。如果您的某些帐号使用的是指向合作伙伴公司或消费者电子邮件提供商的电子邮件地址,这些电子邮件地址将无法使用。

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

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

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

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

映射群组

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

在 Google Cloud 中,群组通常用作跨项目高效管理访问权限的方法。您可以定义一组用于为组织中的公共角色建模的群组,然后将这些群组分配给一组 Cloud IAM 角色,而不是将各个用户分配给每个项目中的 Cloud Identity and Access Management (Cloud IAM) 角色。通过修改群组的成员组成,您可以控制用户对某一组资源的访问权限。

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

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

Active Directory 中的安全群组

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

AD 中的安全群组

网域本地群组
这些群组仅在单个网域的范围内相关,不能被其他网域引用。由于不需要跨林复制其成员列表,因此在可以包含的成员类型方面,网域本地群组最为灵活。
全局群组
这些群组会出现在其他网域中,并且可以被其他网域引用。但是,其成员列表没有被复制。此项限制限定了这些群组可以包含的成员类型。这些群组只能包含同一网域中的用户帐号和其他全局群组。
通用群组
这些群组及其成员列表将在整个林中进行复制。因此,它们可以被其他网域引用,不仅可以包含用户帐号和其他通用群组,还可以包含来自所有网域的全局群组。

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

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

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

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

在 Active Directory 中使用安全群组

资源群组

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

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

角色和组织群组

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

角色群组会聚合特定角色在组织中需要的权限。例如,名为 Engineering Documentation Viewer 的角色群组可能会为成员提供对所有工程文档的只读访问权限。实际上,为了实现此目的,您可以创建角色群组,并使其成为所有资源群组(用于控制对各种文档的访问权限)的成员。

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

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

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

在多网域 AD 环境中使用的嵌套模式

Cloud Identity 中的群组

在 Cloud Identity 中,只有一种类型的群组,其行为与 Active Directory 中的通用群组类似。也就是说,这些群组不限于对其进行了定义的 Cloud Identity 帐号的范围。这些群组可以包含来自不同 Cloud Identity 帐号的用户帐号。可以在其他 Cloud Identity 帐号中引用和嵌套这些群组,并且可以在任何 Google Cloud 组织中使用这些群组。

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

在 Google Cloud 中使用群组

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

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

同步角色群组和组织群组

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

如果之前的问题是为每个多网域林运行单个 Cloud Directory Sync 实例是否足够或者您是否需要多个 Cloud Directory Sync 实例,随后问题会变为您是否使用全局群组。如果使用通用群组实现所有角色群组和组织群组,则单个 Cloud Directory Sync 实例就足够了;否则,每个网域都需要一个 Cloud Directory Sync 实例。

映射群组身份

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

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

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

按通用名称映射

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

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

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

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

按电子邮件地址映射

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

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

    Get-ADGroup -LDAPFilter "(!mail=*)"
  • 电子邮件地址必须使用一组特选网域,所有这些网域都归您所有。如果您的某些帐号使用的是指向合作伙伴公司或消费者电子邮件提供商的电子邮件地址,那么您无法使用这些地址。

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

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

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

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

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

映射组织单元

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

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

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

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

选择正确的映射

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

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

用于确定所需机组或实例数量的决策图

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

用于标识要在 Cloud Identity 中配置的网域的决策图

后续步骤