将 Google Cloud 与 Microsoft Entra ID（以前称为 Azure AD）联合

Last reviewed 2024-06-26 UTC

本文介绍如何配置 Cloud Identity 或 Google Workspace 以使用 Microsoft Entra ID（以前称为 Azure AD）作为 IdP 和身份来源。

本文将比较 Microsoft Entra ID 的逻辑结构与 Cloud Identity 和 Google Workspace 使用的结构，并说明如何映射 Microsoft Entra ID 租户、网域、用户和群组。

实现联合

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

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

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

  预配是单向的，这意味着 Microsoft Entra ID 中所做的更改将复制到 Google Cloud，但反之则不会。此外，预配不包括密码。

• 单点登录：每当用户需要进行身份验证时，Google Cloud 都会使用安全断言标记语言 (SAML) 协议将身份验证委派给 Microsoft Entra ID。根据您的 Microsoft Entra ID 配置，Microsoft Entra ID 可能会执行以下操作之一：

  • 自行执行身份验证。
  • 使用直通式身份验证或密码哈希同步。
  • 将身份验证委派给本地 AD FS 服务器。

Cloud Identity 或 Google Workspace 将身份验证委派给 Microsoft Entra ID 时，不仅可以避免将密码同步到 Google Cloud，还可以确保强制执行在 Microsoft Entra ID 或 AD FS 中配置的任何适用政策或多重身份验证 (MFA) 机制。

注意：本文档引用了来自 Microsoft Azure 市场的 Google Cloud/G Suite Connector by Microsoft 库应用。此应用属于 Microsoft 产品，Google 不提供相关维护和支持。

Microsoft Entra ID 的逻辑结构

使用 Azure 时，您使用一个或多个 Microsoft Entra ID 租户（也称为目录）。Microsoft Entra ID 租户是顶级结构。它们被视为管理边界，并充当用户、群组以及资源和资源组的容器。

每个 Microsoft Entra ID 租户与至少一个 DNS 网域相关联。此 DNS 网域会反映在用户名中（也称为“用户主体名称”，英文简称为 UPN），其格式为 name@domain，其中 domain 是与相应租户关联的一个 DNS 网域。

企业可能会维护多个 Microsoft Entra ID 租户。拥有多个租户的常见原因包括需要区分组织的不同部分、将生产资源与开发和测试资源分离，以及使用单独的租户从本地 Active Directory 集成多个林。

Google Cloud 的逻辑结构

在 Google Cloud 中，组织充当所有资源的容器，并且可以使用文件夹和项目进一步细分。但是，除服务账号外，组织不会用于管理用户和群组，因此组织与 Microsoft Entra ID 租户不同。

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 账号的用户和群组。

将 Microsoft Entra ID 与 Google Cloud 集成

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

• 如何将 Microsoft Entra ID 租户映射到 Cloud Identity 或 Google Workspace 账号
• 如何映射 DNS 网域
• 如何映射用户
• 如何映射群组

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

Google Cloud 仅与 Microsoft Entra ID 交互，而不与您的本地 Active Directory 交互。因此，将本地 Active Directory 的林和网域映射到 Microsoft Entra ID 的方式无关紧要。

映射 Microsoft Entra ID 租户

以下部分介绍了如何针对这些场景映射 Microsoft Entra ID 租户：

• 单个租户
• 多个租户
• 外部用户

单个租户

如果仅使用单个 Microsoft Entra ID 租户，则可以将租户映射到单个 Cloud Identity 或 Google Workspaceh 账号，并将其联合。然后，此 Cloud Identity 或 Google Workspaceh 账号会为单个 Google Cloud 组织提供基础，供您用来管理所有 Google Cloud 资源。

多个租户

在较大的组织中，拥有多个 Microsoft Entra ID 租户的情况比较常见。多个租户可用于区分测试和生产环境，或区分组织的不同部分。

您可以将多个 Microsoft Entra ID 租户映射到单个 Cloud Identity 或 Google Workspace 账号，并相应地设置用户预配和单点登录。不过，这种 N:1 映射可能会削弱 Microsoft Entra ID 租户之间的隔离性：如果您向多个 Microsoft Entra ID 租户授予在单个 Cloud Identity 或 Google Workspace 账号中创建和修改用户的权限，那么这些租户可能会干扰和篡改彼此的更改。

通常，如需与多个 Microsoft Entra ID 租户集成，更好的方法是为每个租户创建单独的 Cloud Identity 或 Google Workspace 账号，并将 Cloud Identity 或 Google Workspace 账号与 Microsoft Entra ID 租户相联合。

在 Google Cloud 中，系统会为每个 Cloud Identity 或 Google Workspace 账号创建一个单独的组织。由于 Google Cloud 允许使用单一组织内的项目和文件夹来整理资源，因此使用多个组织通常并不实用。但是，您可以选择其中一个组织并将该组织与其他 Cloud Identity 或 Google Workspace 账号关联，从而有效地创建与多个 Active Directory 林联合的组织。其他组织则保持未使用状态。

外部用户

借助 Microsoft Entra ID B2B，您可以邀请外部用户作为 Microsoft Entra ID 租户的访客。系统会为每个访客创建一个新用户，Microsoft Entra ID 会自动向这些访客用户分配 UPN。Microsoft Entra ID 生成的 UPN 使用从邀请对象的电子邮件地址派生的前缀，与租户的初始网域相结合：prefix#EXT#@tenant.onmicrosoft.com。

将访客用户从 Microsoft Entra ID 预配到 Cloud Identity 或 Google Workspace 会受到特定限制：

• 您无法将访客用户的 UPN 映射到 Cloud Identity 或 Google Workspace 中的电子邮件地址，因为无法在 Cloud Identity 或 Google Workspace 中添加和验证 onmicrosoft.com 网域。因此，您必须使用 UPN 以外的特性来映射用户。
• 如果访客用户在其主租户中被暂停，则 Cloud Identity 或 Google Workspace 中的相应用户可能仍处于活跃状态，并且可能无法正确撤消其对 Google Cloud 资源的访问权限。

为处理来自不同 Microsoft Entra ID 租户的访客用户，一种更好的方法是创建多个 Cloud Identity 或 Google Workspace 账号，然后如上一部分所述，将每个账号与不同的 Microsoft Entra ID 租户联合。如需了解详情，请参阅 Microsoft Entra ID B2B 用户预配和单点登录

如需授予外部用户对某些 Google Cloud 资源的访问权限，用户在 Cloud Identity 或 Google Workspace 中拥有用户账号并不是前提条件。除非存在政策限制，否则只要外部用户拥有 Google 身份，您就可以直接添加该用户作为个别项目、文件夹或组织的成员。

映射 DNS 网域

DNS 在 Microsoft Entra ID 以及 Cloud Identity 和 Google Workspace 中都起着至关重要的作用。计划将 Microsoft Entra ID 与 Google Cloud 联合时要考虑的第二个因素是如何在 Microsoft Entra ID 与 Google Cloud 之间共享或映射 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 记录，这样，如果使用此域名构成电子邮件地址，向其发送的邮件便可以正确递送。

在 Microsoft Entra ID 中使用 DNS 网域

Cloud Identity 和 Google Workspace 使用 DNS 的方式类似于 Microsoft Entra ID 依赖 DNS 来区分 Microsoft Entra ID 租户并将用户名与租户关联的方式。但要注意两个显著的差别：

1. 初始网域：创建 Microsoft Entra ID 租户时，该租户会关联至初始网域，也就是 onmicrosoft.com 的子网域。此网域与您可能注册的其他自定义域名不同，您不拥有该网域，也没有对相应 DNS 区域的管理员权限。

   Cloud Identity 没有等效的初始网域，而是要求您拥有与 Cloud Identity 账号关联的所有网域。也就是说，您无法将 onmicrosoft.com 子网域注册为 Cloud Identity 网域。

2. 用户标识符中使用的网域：Microsoft Entra ID 会区分电子邮件地址 MOERA (Microsoft Online Email Routing Addresses) 和 UPN。两者都遵循 RFC 822 格式 (user@domain)，但它们的使用目的不同：UPN 用于识别用户并在登录表单中使用，而 MOERA 用于递送电子邮件。

   UPN 使用的域名后缀必须与 Microsoft Entra ID 租户的注册网域之一匹配 - 相同的要求不适用于电子邮件地址。

   Cloud Identity 和 Google Workspace 不依赖于 UPN，而是使用用户的电子邮件地址作为标识符。因此，电子邮件地址使用的网域必须与 Cloud Identity 或 Google Workspace 账号的一个注册网域匹配。

Microsoft Entra ID 租户和 Cloud Identity 或 Google Workspace 账号可以使用相同的 DNS 网域。如果无法使用相同的网域，您可以配置用户预配和单点登录来替换域名。

考虑到上述两个差异，您的网域映射应取决于您计划如何在 Microsoft Entra ID 和 Cloud Identity 或 Google Workspace 之间映射用户。

Map users（映射用户）

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

如果要将 Microsoft Entra ID 用户成功映射到 Cloud Identity 或 Google Workspace 中的用户，需要关于每个用户的两条信息：

1. 一个稳定的唯一 ID，您可以在同步期间使用该 ID 来跟踪哪个 Microsoft Entra ID 用户对应于 Cloud Identity 或 Google Workspace 中的哪个用户。
2. 一个电子邮件地址，其网域部分对应于 Cloud Identity 的主要、辅助或别名网域。由于此电子邮件地址将在整个 Google Cloud 中使用，因此该地址应当直观易记。

Microsoft Entra ID 在内部通过 ObjectId 识别用户，ObjectId 是随机生成的全局唯一 ID。虽然此 ID 的稳定性符合第一个要求，但它对人类毫无意义，并且不遵循电子邮件地址的格式。如需映射用户，唯一可行的选项是按 UPN 或电子邮件地址进行映射。

如果用户输入的电子邮件地址属于配置为使用 Microsoft Entra ID 单点登录的 Cloud Identity 或 Google Workspace 账号，则系统会将用户重定向到 Microsoft Entra ID 登录。

Microsoft Entra ID 使用 UPN 而不是电子邮件地址来识别用户，因此登录屏幕会提示用户提供 UPN。

如果将 Microsoft Entra ID 租户配置为使用 AD FS 进行登录，则系统会将用户重定向到 AD FS 登录屏幕。AD FS 可以通过其 Active Directory UPN 或 Windows 2000 之前的登录名 (domain\user) 来标识用户。

如果 Cloud Identity 或 Google Workspace 使用的电子邮件地址、Microsoft Entra ID 使用的 UPN 以及 Active Directory 使用的 UPN 互不相同，则登录屏幕的顺序很容易造成最终用户的混淆。相反，如果所有三个标识符与示例屏幕截图 ([e-mail]) 中的相同，则 UPN 和电子邮件地址之间的技术差异就不会被用户感知，从而最大程度减少对用户造成的混淆。

通过 UPN 映射

从用户体验的角度来看，将 Microsoft Entra ID UPN 映射到 Cloud Identity 或 Google Workspace 电子邮件地址可能被认为是最佳选项。依赖 UPN 的另一个好处是 Microsoft Entra ID 保证了唯一性，因此可以避免命名冲突的风险。

但是，为了将 Microsoft Entra ID UPN 映射到 Cloud Identity 电子邮件地址，必须满足以下要求：

• Microsoft Entra ID UPN 应该是有效的电子邮件地址，以确保 Google Cloud 发送的任何通知电子邮件都正确地递送到用户的邮箱。如果不能做到，您可以配置别名电子邮件地址以确保用户可以收到此类电子邮件。
• Microsoft Entra ID 中所有相关用户的 UPN 必须使用自定义网域作为后缀 (user@custom-domain)。使用 Microsoft Entra ID 初始网域 ([e-mail]) 的 UPN 无法映射到 Cloud Identity 中的电子邮件地址，因为 Microsoft 是初始网域的所有者，而并非您。
• Microsoft Entra ID 用于 UPN 的所有自定义网域也必须在 Cloud Identity 中注册。此要求意味着您必须有相应 DNS 地区的访问权限才能验证网域。为了避免覆盖您可能已在 Microsoft Entra ID 中创建用于验证网域所有权的现有 TXT DNS 记录，您可以在 Cloud Identity 中使用 CNAME 记录来验证网域所有权。

按电子邮件地址映射用户

如果无法将 Microsoft Entra ID UPN 映射到 Cloud Identity 或 Google Workspace 电子邮件地址，则可以按电子邮件地址映射用户。

在 Active Directory 中指定电子邮件地址时，它会存储在相应 user 对象的 mail 属性中，并且 Microsoft Entra ID Connect 会将该值同步到 Microsoft Entra ID 中的 Mail 属性。Microsoft Entra ID 还允许您使用该特性进行用户预配，以便您可以将其映射到 Cloud Identity 或 cloudid_name_short 中的电子邮件地址。

至关重要的是，Microsoft Entra ID Mail 属性当前未显示在 Azure 门户中，您只能通过 API 或 PowerShell 查看和修改。虽然您可以在界面上指定电子邮件地址和备用邮箱，但这些值都不存储在 Mail 特性中，因此它们不能用于预配到 Cloud Identity 或 cloudid_name_short。 由此可知，只有当您的大部分用户创建和修改操作是在 Active Directory 中而非 Microsoft Entra ID 中进行时，根据电子邮件地址映射用户才是可行的。

如需按电子邮件地址映射用户，需要满足以下附加要求：

• 必须填写电子邮件地址字段。必须为所有要同步的用户指定一个电子邮件地址。特别是当用户从本地 Active Directory 进行同步时，同步的用户账号可能没有分配电子邮件地址，因为 mail 是 Active Directory 中的可选用户特性。在同步过程中，Microsoft Entra ID Mail 属性中缺少电子邮件地址的用户将以静默方式忽略。
• 电子邮件地址在 Microsoft Entra ID 租户中必须是唯一的。虽然 Active Directory 不会检查创建的用户的唯一性，但默认情况下 Microsoft Entra ID Connect 会检测冲突，这可能会导致受影响的用户同步失败。
• 电子邮件地址使用的网域不需要在 Microsoft Entra ID 中注册，但必须在 Cloud Identity 或 Google Workspace 中注册。此要求意味着您必须有相应 DNS 区域的访问权限才能验证网域，并且排除了使用您没有所有权的网域的电子邮件地址（如 gmail.com）的可能性。

映射用户生命周期

定义 Microsoft Entra ID 用户与 Cloud Identity 或 Google Workspace 用户之间的映射后，您必须确定要预配的用户组。如需了解如何做出此决定，请参阅映射身份组的最佳做法。

如果您不想预配 Microsoft Entra ID 租户的所有用户，可以使用用户分配或范围限定过滤条件。

下表汇总了 Microsoft Entra ID 预配的默认行为，并显示了为用户启用或停用预配会如何控制 Microsoft Entra ID 在 Cloud Identity 或 Google Workspace 中执行的操作。

为 Microsoft Entra ID 用户启用了预配	Cloud Identity 或 Google Workspace 中的用户状态	在 Microsoft Entra ID 中执行的操作	在 Cloud Identity 或 Google Workspace 中执行的操作
否	（不存在）	启用预配	创建新用户 (*)
否	存在（活跃）	启用预配	更新现有用户
否	存在（暂停）	启用预配	更新现有用户，保持暂停
是	已存在	修改用户	更新现有用户
是	已存在	重命名 UPN/电子邮件地址	更改主电子邮件地址，将以前的地址保留为别名
是	已存在	停用预配	用户保持原样
是	已存在	软删除用户	暂停用户
是	已存在	永久删除用户	暂停用户，向电子邮件地址添加 del_ 前缀

(*) 如果存在使用同一电子邮件地址的消费者账号，则该消费者账号会被逐出。

注意：如果您为用户启用预配，并稍后停用预配，则 Cloud Identity 或 Google Workspace 中的相应用户仍然处于活跃状态。如需撤消用户登录和访问 Google 服务的权限，您必须在 Microsoft Entra ID 中删除该用户，或在 Cloud Identity 或 Google Workspace 中手动停用该用户。

映射群组

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

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

在 Microsoft Entra ID 和 Google Cloud 之间映射群组是可选操作。设置用户预配后，您可以直接在 Cloud Identity 或 Google Workspace 中创建和管理群组，这意味着 Active Directory 或 Microsoft Entra ID 仍然是管理身份的中央系统，但并不用于管理 Google Cloud 访问权限。

如需将 Active Directory 或 Microsoft Entra ID 作为管理身份和访问权限的中央系统进行维护，我们建议您从 Microsoft Entra ID 同步群组，而不是在 Cloud Identity 或 Google Workspace 中管理群组。通过此方法，您可以设置 IAM，以便在 Active Directory 或 Microsoft Entra ID 中使用组成员资格来控制谁有权访问 Google Cloud 中的资源。

Cloud Identity 和 Google Workspace 中的群组

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

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

在 IAM 中使用群组时，通常需要按电子邮件地址而非名称指定群组。所以群组最好不仅要有一个有意义的名称，而且要有一个有意义的可识别电子邮件地址。

Microsoft Entra ID 中的群组

Microsoft Entra ID 支持多种类型的群组，每种类型的群组都适用于不同的用例。群组的范围限定为单个租户，并由随机生成的全局唯一的对象 ID 标识。群组支持嵌套，可以包含来自同一租户的用户或使用 Azure B2B 从其他租户邀请的用户。Microsoft Entra ID 还支持动态群组，其成员根据查询自动确定。

在将 Microsoft Entra ID 与 Cloud Identity 或 Google Workspace 集成的情境中，群组的两个属性是主要关注点，即：群组是否已启用邮件以及是否已启用安全功能：

• 已启用安全功能的群组可用于管理对 Microsoft Entra ID 中资源的访问权限。因此，任何启用安全功能的群组都可能与 Google Cloud 上下文相关。
• mail-enabled的群组具有电子邮件地址，这是相关的，因为 Cloud Identity 和 Google Workspace 要求根据电子邮件地址标识群组。

在 Microsoft Entra ID 中，您可以创建安全或 Office 365 类型的群组（有时称为统一群组）。从本地 Active Directory 同步群组或使用 Office 365 类型的群组时，还可以创建分发列表类型的群组。

下表总结了这些不同类型的群组在已启用邮件或已启用安全功能方面的差异，以及它们如何映射到 Active Directory 的群组类型（假设在默认的 Microsoft Entra ID Connect 配置场景中）：

来源	Active Directory 群组类型	Microsoft Entra ID 群组类型	已启用邮件	已启用安全功能
Microsoft Entra ID	-	Office 365 群组	始终	可选
Microsoft Entra ID	-	安全群组	可选	始终
本地	安全群组（有电子邮件）	安全群组	是	是
本地	安全群组（无电子邮件）	安全群组	否	是
本地	分发列表（有电子邮件）	分发列表	是	否
本地	分发列表（无电子邮件）	（被 Microsoft Entra ID Connect 忽略）

与用户不同，Microsoft Entra ID 要求分配给群组的电子邮件地址使用已在 Microsoft Entra ID 中注册为自定义网域的网域。此要求会产生以下默认行为：

• 如果 Active Directory 中的群组使用的电子邮件地址使用了之前在 Microsoft Entra ID 中注册的网域，则 Active Directory 会在与 Microsoft Entra ID 同步期间正确地维护该电子邮件地址。
• 如果 Active Directory 中的群组使用的电子邮件地址尚未在 Microsoft Entra ID 中注册，则 Microsoft Entra ID 会在同步期间自动生成新的电子邮件地址。此电子邮件地址使用租户的默认网域。如果您的租户使用初始网域作为默认网域，则生成的电子邮件地址将采用 [name]@[tenant].onmicrosoft.com 的形式。
• 如果您在 Microsoft Entra ID 中创建 Office 365 群组，则 Microsoft Entra ID 还会自动生成使用租户默认网域的电子邮件地址。

映射群组身份

将 Microsoft Entra ID 群组成功映射到 Cloud Identity 或 Google Workspace 群组时，需要使用共同的标识符，并且此标识符必须为电子邮件地址。为此，Microsoft Entra ID 提供了两个选项：

• 您可以使用 Microsoft Entra ID 中群组的电子邮件地址并将其映射到 Cloud Identity 或 Google Workspace 中的电子邮件地址。
• 您可以根据 Microsoft Entra ID 中群组的名称衍生电子邮件地址，并将生成的地址映射到 Cloud Identity 或 Google Workspace 中的电子邮件地址。

通过电子邮件地址映射

按电子邮件地址映射群组是最合适的选择，但需要满足以下几个要求：

• 所有需要同步的群组都必须具有电子邮件地址。实际上，这意味着您只能同步已启用邮件的群组。在预置期间，将忽略缺少电子邮件地址的群组。
• 电子邮件地址在租户内必须是唯一的。由于 Microsoft Entra ID 不强制要求唯一性，因此您可能必须实施自定义检查或政策。
• 电子邮件地址使用的网域必须在 Microsoft Entra ID 和 Cloud Identity 或 Google Workspace 中均已注册。如果群组的电子邮件地址使用未在 Cloud Identity 或 Google Workspace 中注册的网域（包括 tenant.onmicrosoft.com 网域），同步将失败。

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

通过名称映射

满足按电子邮件地址映射群组所需的条件可能很困难，尤其是在您打算预配到 Cloud Identity 或 Google Workspace 上的许多安全群组都未启用邮件的情况下。在这种情况下，最好从群组的显示名称自动衍生电子邮件地址。

衍生电子邮件地址存在两大难点：

1. 根据群组名称衍生的电子邮件地址可能与用户的电子邮件地址冲突。
2. Microsoft Entra ID 不会强制要求群组名称的唯一性。如果您的 Microsoft Entra ID 租户中的多个群组共享相同的名称，则根据此名称衍生的电子邮件地址将发生冲突，从而导致只有一个群组可以成功同步。

您可以通过使用一个与用户使用的任何网域都不相同的网域来生成电子邮件地址以克服第一个难点。例如，如果所有用户都使用带有 example.com 网域的电子邮件地址，那么您可以将 groups.example.com 用于所有群组。在 Cloud Identity 或 Google Workspace 中注册子网域不需要网域验证，因此 DNS 区域 groups.example.com 甚至不必存在。

您可以通过从对象 ID 衍生群组电子邮件地址来克服第二个难点，即重复群组名称。由于生成的群组名称已加密且难以使用，因此在预配 Cloud Identity 或 Google Workspace 之前，最好在 Microsoft Entra ID 中标识并重命名这些重复群组名称。

映射群组生命周期

定义 Microsoft Entra ID 群组与 Cloud Identity 或 Google Workspace 群组之间的映射后，您必须确定要预配的群组。与用户的预配过程类似，您可以使用群组分配或范围过滤条件为部分群组启用预配。

下表汇总了 Microsoft Entra ID 预配的默认行为，并显示了为群组启用或停用预配会如何控制 Microsoft Entra ID 在 Cloud Identity 或 Google Workspace 中执行的操作。

为 Microsoft Entra ID 群组启用了预配	Cloud Identity 或 Google Workspace 中的群组状态	在 Microsoft Entra ID 中执行的操作	在 Cloud Identity 或 Google Workspace 中执行的操作
否	（不存在）	启用预配	创建新群组
否	已存在	启用预配	添加成员，保留所有现有成员
是	已存在	重命名群组	重命名群组
是	已存在	修改说明	更新说明
是	已存在	添加成员	添加成员，保留所有现有成员
是	已存在	移除成员	移除成员
是	已存在	停用预配	群组保持原样（包括成员）
是	已存在	删除群组	群组保持原样（包括成员）

注意：在 Microsoft Entra ID 中删除群组时，Microsoft Entra ID 不会将删除操作传播到 Cloud Identity 或 Google Workspace。同样，如果您为某个群组启用预配，并稍后停用预配，则 Cloud Identity 或 Google Workspace 中的群组将仍然处于活跃状态。此行为可能导致在无意中保留这些用户对 Google Cloud 的访问权限。为了防止这种情况发生，请先从群组中移除所有成员，只有等更改生效之后，再删除 Microsoft Entra ID 中的群组或为 Microsoft Entra ID 中的群组停用预配。

后续步骤

• 阅读规划账号和组织的最佳做法以及联合 Google Cloud 与外部身份提供商的最佳做法。
• 了解如何在 Microsoft Entra ID 和 Cloud Identity 之间配置预配和单点登录。
• 了解管理超级管理员账号的最佳做法。