本指南介绍在 Google Cloud 上运行 Active Directory 的最佳做法，重点介绍特定于 Google Cloud 的做法或在 Google Cloud 上部署 Active Directory 时特别重要的做法。将本指南视为 Microsoft 发布的保护 Active Directory 的常规最佳方案的补充。
架构
以下部分详细介绍与架构相关的最佳做法。
使用最适合您要求的架构模式
要在 Google Cloud 上部署 Active Directory，首先必须确定要使用的网域和林架构。如果您已经在使用 Active Directory，则还必须确定是否以及如何集成这两个环境。
哪种设计最适合您的情况取决于许多因素，包括本地网络的设计、本地与 Google Cloud 资源的交互方式以及您对可用性和管理自主权的要求。请参阅在混合环境中使用 Active Directory 的模式，以了解这些因素如何决定您的设计。
如果您想在 Google Cloud 与本地环境之间维护信任边界，请考虑实施资源林模式。在这种模式下，您在 Google Cloud 上部署一个单独的林，并使用单向林信任将 Google Cloud 林与您现有的本地 Active Directory 林集成在一起。
分离测试和生产
根据对 Active Directory 的使用情况，您可能需要在应用的开发和测试过程中对 Active Directory 进行频繁更改。开发者可能需要能够创建和修改 Active Directory 账号，更改组成员资格（如果应用使用组来处理授权），或者加入和移除计算机。
为了防止开发和测试工作影响生产工作负载或妨碍部署的安全性，请考虑为开发和测试部署单独的 Active Directory 域或林。
有了单独的开发和测试网域或林，您还可以在将管理更改应用于生产之前对其进行验证。此类更改的示例包括试用组策略、测试自动化脚本或有潜在风险的操作（例如提高林的职能级别）。
在 Google Cloud 上部署 Active Directory 之后设置 Cloud Identity 联合
在 Google Cloud 上部署 Active Directory 让您可以在 Google Cloud 上管理 Windows 虚拟机，可以使用户使用其现有用户账号登录 Windows 虚拟机，并支持依赖 Kerberos、NTLM 或 LDAP 进行身份验证的应用。
但是，如果想要使用 Google Cloud 控制台、gcloud 命令行工具或其他 Google 和 Google Cloud 工具，您必须使用 Google 身份进行身份验证。因此，如果您打算将 Active Directory 用作管理用户的主要系统，则在 Google Cloud 上部署 Active Directory 无法代替联合现有 Active Directory 与 Google Cloud。
例如，如果您在 Google Cloud 上部署了单独的林，您可以针对本地 Active Directory 设置联合，如下图所示。然后，在本地 Active Directory 中有账号的用户可以使用需要 Google 身份的工具以及您的依赖 Active Directory 进行身份验证的应用。
如果您决定将现有林或网域扩展到 Google Cloud，那么您还可以选择使用部署在 Google Cloud 上的网域控制器和 AD FS 服务器来设置联合。
联合还允许您对 Google 账号和 Active Directory 账号实施共同生命周期，这样，当您在本地 Active Directory 中停用用户账号时，相应的 Google 用户也会被暂停。
网络
以下部分详细介绍与网络相关的最佳做法。
将 Active Directory 部署到共享 VPC 网络中
要允许在多个项目中使用 Active Directory，请将网域控制器部署到共享 VPC 网络中。使用共享 VPC 网络具有多个优点：
每个可能需要 Active Directory 访问的应用都可以部署到单独的项目中。使用单独的项目有助于隔离资源，并允许您单独管理访问。
您可以为 Active Directory 域控制器使用专用项目，从而精细控制哪些用户可以访问相关的 Google Cloud 资源。
共享 VPC 网络使您可以集中 IP 地址管理和防火墙配置，这有助于确保多个项目之间的一致性。
由于 VPC 是全球性资源，因此您可以跨多个区域使用相同的共享 VPC 网络。
不向外部公开网域控制器
为了缩小 Active Directory 的被攻击面，请避免将外部 IP 地址分配给网域控制器。
由于默认情况下，没有外部 IP 地址的虚拟机实例无法访问互联网，因此您需要采取其他步骤来确保网域控制器上的 Windows 激活和 Windows 更新没有损坏。
要支持 Windows 激活，请在计划在其中部署网域控制器的子网上启用专用 Google 访问通道，并确保虚拟机实例可以访问 kms.windows.googlecloud.com。这允许在 无需直接访问互联网的情况下进行激活。
有多种选项可支持 Windows 更新：
您可以通过部署 Cloud NAT 来允许通过 NAT 网关进行互联网访问。
如果您已设置混合连接，则还可以通过本地 NAT 网关或代理服务器路由出站流量。
提前为网域控制器预留静态 IP 地址
由于网域控制器充当 DNS 服务器，因此需要为它们分配不变的 IP 地址。为此，请为网域控制器虚拟机配置静态内部 IP 地址。
预留 IP 地址时，默认行为是自动选择未使用的地址。为确保网域控制器的 IP 地址易于记忆，请预留内部静态 IP 地址。
在网域控制器上，将网络适配器的 IP 地址设置为相同的地址。此步骤是可选的，但它可以防止 Active Directory 发出警告消息，表明可能仍在动态分配机器的 IP 地址。
跨多个地区部署网域控制器
为了提高可用性，请至少部署两个网域控制器，然后将它们分布在多个地区。由于子网和 IP 地址没有绑定到地区，因此您可以将所有网域控制器部署到单个子网中。
如果计划跨多个区域部署工作负载，请考虑在每个相关区域中部署网域控制器。由于子网是区域性资源，因此部署到其他区域将需要一个额外的子网。
每个区域创建一个站点
当客户端尝试寻找网域控制器时，它将首先在 Active Directory 站点中寻找与客户端 IP 地址对应的网域控制器。如果此站点中没有可用的网域控制器，则客户端将继续尝试在另一个站点中查找网域控制器。
要利用此行为，您可以为在其中部署了网域控制器或网域客户端的每个区域创建一个单独的站点。这样，客户端将自动首选使用位于同一区域中的网域控制器，这有助于减少延迟和区域之间的出站数据传输费用。
如果您的客户端所在的区域没有网域控制器，您也可以影响这些客户端选择的网域控制器，方法是调整站点链接费用以反映区域的地理位置远近并启用尝试下一个最近的站点设置。
使用多个站点会影响网域控制器之间的复制行为。使用多个站点的一个缺点是站点之间的复制频率低于站点内复制。
但是，您无法在 Managed Microsoft AD 中创建 Active Directory 站点，因为 Managed Microsoft AD 不支持 Active Directory 站点和服务功能。
使用 Cloud DNS 专用转发地区
当您在 Compute Engine 中创建新的虚拟机实例时，操作系统将被预配置为使用默认的 DNS 服务器，该服务器提供对内部 DNS 和公共 DNS 的访问权限。
在将机器加入 Active Directory 域之前，您必须确保该机器能够解析 Active Directory 管理的 DNS 记录。Compute Engine 为虚拟机实例配置的默认 DNS 服务器提供内部 DNS 和公用 DNS 的访问权限，但是将无法解析由 Active Directory 管理的 DNS 名称。
在 Cloud DNS 中创建专用 DNS 转发地区，以允许客户端解析由 Active Directory 管理的 DNS 记录。将该地区配置为将与您的 Active Directory 域匹配的查询转发到网域控制器。
与将客户端配置为直接将 Active Directory 域控制器用作 DNS 服务器相比，使用专用 DNS 转发地区具有多个优点：
您无需调整虚拟机实例的网络配置。这简化了创建新虚拟机的过程。
提升或降级域控制器时，您只需更新专用 DNS 转发区域的配置，而无需修改任何客户端设置。
虚拟机实例仍然可以访问内部 DNS。
Cloud DNS 将处理与您的 Active Directory 域不匹配的任何 DNS 记录，从而减少网域控制器上的负载。
如果使用多个网域，请为每个 Active Directory 域创建一个单独的专用 DNS 转发地区。
Cloud DNS 专用转发地区的范围限定为单个 VPC。如果您使用对等互连的多个 VPC，则可以通过配置 DNS 对等互连将专用转发地区公开给其他 VPC。
您仍然必须在网域控制器上手动配置 DNS 设置。使用 127.0.0.1 作为主 DNS 服务器，并酌情使用另一个网域控制器的 IP 地址作为辅助 DNS 服务器。如需了解详情，请参阅建议的 DNS 设置和备用选项。
混合连接
以下部分详细介绍了与混合连接相关的最佳实践。
使用 DNS 入站转发从本地解析 Google Cloud DNS 名称
本地网络中的客户端可能需要能够解析 Google Cloud 上部署的资源的 DNS 名称。如果您扩展林或在 Google Cloud 上部署资源林，请使用 DNS 入站转发来允许本地客户端查找 Google Cloud 上部署的资源的 DNS 记录。要使用入站转发，请创建 DNS 服务器政策以分配入站转发器 IP 地址，并使该地址可供本地网络访问。
如果在 Google Cloud 上使用的 DNS 网域（例如 cloud.example.com）是本地使用的 DNS 网域（例如 example.com）的子网域，请设置 DNS 委派。在本地网域中创建指向入站转发器 IP 地址的 NS 记录。NS 记录使尝试在 Google Cloud 托管网域中查找 DNS 名称的客户端重定向到入站转发器 IP 地址。
如果在 Google Cloud 和本地 Active Directory 上使用的 DNS 网域不同（例如 cloud.example.com 和 corp.example.com），请在本地网域中配置条件 DNS 转发并使用入站转发器 IP 地址作为目标。当收到解析 Google Cloud 托管网域中的 DNS 名称的请求时，本地网域控制器会将请求转发到入站转发器 IP 地址。
使用入站 DNS 转发时，请确保已正确配置防火墙。
如果您将现有网域扩展到 Active Directory，则不需要 DNS 入站转发。在这种情况下，该网域的所有 DNS 记录都会在 Google Cloud 和本地环境中自动复制，并且可以在这两个环境中查找。
使用 DNS 出站转发从 Google Cloud 解析本地 DNS 名称
在 Google Cloud 上运行的客户端可能需要能够解析本地部署的资源的名称。如果您扩展林或在 Google Cloud 上部署资源林，则在 Cloud DNS 中创建专用转发地区以将针对本地网域的 DNS 查询转发到本地 DNS 服务器。
使用出站 DNS 转发时，请确保已正确配置防火墙。
如果您将现有网域扩展到 Active Directory，则不需要 DNS 出站转发。在这种情况下，该网域的所有 DNS 记录都会在 Google Cloud 和本地环境中自动复制，并且可以在这两个环境中查找。
使用 VPN 隧道保护 LDAP 流量
Active Directory 广泛使用 LDAP 协议。与 Active Directory 使用的大多数其他协议不同，LDAP 默认不加密。
Google Cloud 可确保对虚拟机之间的流量进行加密，因此在 VPC 中使用未加密的 LDAP 是可接受的。如果您将 VPC 连接到本地网络，请确保 LDAP 流量仅通过可信通道交换。
如果您使用 Cloud VPN 连接 Google Cloud 和本地网络，则会使用 IPSec 自动加密 Google Cloud 和本地 VPN 端点之间的流量。
Cloud Interconnect 和合作伙伴互连不提供加密。为了确保通信安全，请使用 Google Cloud Marketplace 中的 VPN 设备在互连连接上建立 VPN 隧道。
对林信任使用选择性身份验证和 AES
在 Active Directory 林之间创建信任关系时，请优先使用林信任而不是外部信任，并利用以下功能来提高安全性：
对资源林中的出站信任启用选择性身份验证。选择性身份验证可确保组织林中的用户无法访问资源林中的资源，除非明确向其授予权限。
对组织林中的入站信任启用为 Kerberos 完全委派实施林边界。此功能通过禁止资源林中的资源向组织林中的用户请求票据授予票据 (TGT) 来帮助防止提权攻击。
创建信任时，启用“其他网域支持 Kerberos AES 加密”选项。此选项可确保使用 AES（而不是安全性较低的 RC4 算法）对用于跨林身份验证的票据进行加密。
安全
以下部分详细介绍与安全相关的最佳做法。
避免 Google Cloud 安全性干扰 Active Directory 安全性
Active Directory 使您可以对允许哪些用户访问哪些资源进行精细控制。当机器部署为 Compute Engine 中的虚拟机实例并且用户有权访问底层 Google Cloud 项目时，您必须考虑可能允许用户访问机器的其他路径：
在 Google Cloud 项目中被分配了 Compute Instance Admin 角色的项目成员可以使用密码重置功能创建本地管理员账号。本地管理员账号可用于破坏组策略或安装可能捕获其他已登录用户的网域凭据的恶意软件，从而威胁到 Active Directory 域的安全。
通过添加启动脚本，具有特权的项目成员可以将恶意代码注入在机器下次重启时以
nt authority\system执行的到虚拟机中。通过使用串行控制台，具有特权的项目成员还可以访问 Windows 特殊管理控制台 (SAC)。Windows 将通过 SAC 的登录视为本地登录。因此，SAC 可能会被滥用来规避那些拒绝通过 RDP 的登录但未能拒绝本地登录的政策。
具有特权的项目成员可以使用 SAC 发出
crashdump命令，这可以导致将内存转储写入磁盘。此类内存转储可能包含敏感信息和凭据。通过将永久性磁盘装载到另一个虚拟机或使用快照，具有特权的项目成员可能能够从其本来无权登录的机器访问磁盘内容（可能包括内存转储）。
默认情况下，托管式 Microsoft AD 可以帮助您更好地抵御这些其他访问路径导致的侵害。该服务不允许项目中的特权用户重置网域管理员密码、运行启动脚本或访问 AD 网域控制器虚拟机上的串行控制台。
为了进一步降低风险，请确保以最小权限方式管理包含加入网域的虚拟机实例的项目的 IAM 权限。您可以通过使用组织政策、组政策和安全强化型虚拟机进一步降低风险：
使用组织政策停用串行端口访问权限。
通过停用账号管理器来应用阻止创建本地管理员账号的组政策。在组政策 (Computer Configuration > Preferences > Windows Settings > Ini Files) 中定义 INI 文件偏好设置，以应用以下设置：
- 操作：更新
- 文件路径：
C:\Program Files\Google\Compute Engine\instance_configs.cfg - 版块名称：
accountManager - 属性名称：
disable - 属性值：
true
应用从虚拟机实例中移除所有本地管理员账号的组政策。使用本地用户和组功能 (Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups) 从管理员组和其他敏感组中移除组成员资格。
考虑将安全强化型虚拟机与 BitLocker 磁盘加密结合使用，以防止未经授权的用户读取永久性磁盘或快照。
避免 Active Directory 安全性干扰 Google Cloud 安全性
在 Active Directory 域中，机器信任网域控制器以代表它们处理身份验证和授权。除非受到组政策、机器的本地安全政策或选择性身份验证的限制，否则已成功向一个网域控制器证明身份的用户将被允许登录网域中的任何机器。
Active Directory 用户可登录到任何机器的能力可能使攻击者能够在网域内执行横向移动。如果某些虚拟机实例不受防火墙限制或使用 Google Cloud 服务账号，这种横向移动会导致权限提升：虚拟机实例上的所有进程和用户都可以访问服务账号的凭据。因此，可以使用 Active Directory 登录到机器的任何用户都可以访问这些服务账号凭据，从而获得对服务账号有权访问的任何 Google Cloud 资源的访问权限。
设置托管式 Microsoft AD 时，该服务会创建一个组，以使特定用户能够轻松地通过 RDP 连接加入网域的虚拟机。
为了减少横向移动的风险，请将用户组织到管理层级中，并基于层级使用“拒绝网络对这台计算机的访问”和“拒绝通过远程桌面服务的登录”组政策来限制对您虚拟机的访问。
在资源林拓扑中，利用选择性身份验证进一步限制其他林中允许登录到您的虚拟机的一组用户。您可以通过使Google Cloud 和 Active Directory 资源结构保持一致来简化对选择性身份验证权限的管理：如果 Active Directory 组织单位映射到 Google Cloud 项目，您可以授予用户在与 Google Cloud 项目匹配的级层进行身份验证的权限。
如果选择性身份验证和组政策都不适用，请创建一个单独的服务账号，导出服务账号密钥，将其保存到虚拟机实例的本地磁盘或文件共享中，并使用 NTFS ACL 保护它们，以便只有获得授权的 Active Directory 用户才能读取和使用这些密钥。
将专用项目用于网域控制器
网域控制器在 Active Directory 域的安全性中起着至关重要的作用，单个网域控制器被入侵可能会导致整个 Active Directory 林被入侵。
为了限制未经授权的访问导致的风险，请使用单独的 Google Cloud 项目部署网域控制器，并根据最小权限原则授予对该项目的访问权限。创建项目时，请注意，某些权限可能是从父文件夹继承的。为避免无意中通过继承授予访问权限，请考虑在您的常规文件夹层次结构之外创建该项目。
在为该项目配置 IAM 政策时，应特别注意限制对虚拟机实例、包含 ntds.dit 数据库的永久性磁盘以及可能包含备份的任何存储位置的访问权限。
除了使用 IAM 政策限制对项目的访问权限外，还要防止项目被意外删除。
使用单独的虚拟机和项目管理 Active Directory
要管理 Active Directory，您需要能够使用“Active Directory 用户和计算机”或“Active Directory 管理中心”等工具。这些工具要求您使用具有特权的网域账号登录，这使得运行这些工具的机器很容易成为凭据盗窃和键盘记录的目标。
为了最大程度地降低攻击者获得特权网域凭据的风险，请使用专用的虚拟机实例进行网域管理，并将这些虚拟机按特权访问工作站处理：
使用组政策确保只有一部分选定的用户有权登录管理虚拟机。如果您实施了分层管理，则此组用户对应于层级 0。
与网域控制器一样，项目成员创建本地管理员账号、通过串行控制台登录或篡改其永久性磁盘均可能会给管理虚拟机带来风险。为了限制未经授权的访问导致的风险，请为管理虚拟机使用单独的 Google Cloud 项目，并根据最小权限原则授予对该项目的访问权限。
如果您打算使用混合连接从本地网络访问管理虚拟机，则将管理虚拟机部署到专用 VPC 子网中。专用于管理虚拟机的子网可让您在配置本地防火墙时更好地区分管理虚拟机和其他虚拟机。如果您使用共享 VPC，请使用子网级层权限确保仅允许具有特权的管理员将虚拟机实例部署到管理子网中。如果本地防火墙对管理虚拟机应用与其他虚拟机不同的规则，这种做法有助于确保用户无法通过将非管理虚拟机放入管理子网来规避防火墙规则。
此外，请考虑将管理管理虚拟机登录限制的组政策限制在管理子网。这种做法可以使登录限制（基于组政策）和防火墙规则（基于子网/IP 地址）保持一致。
除了使用 IAM 政策限制对项目的访问权限外，还要防止项目被意外删除。
使用防火墙规则保护网域控制器和服务器
网域控制器公开了许多服务，包括 LDAP、DNS、Kerberos、RPC。根据您的用例，部署在 Google Cloud 上的虚拟机以及本地运行的机器可能需要访问这些服务的不同子集以利用 Active Directory。
使用托管式 Microsoft AD 时，AD 网域控制器部署在专用的租户项目中。系统使用强化的 AD 专用防火墙规则自动保护托管 AD 网域控制器的网络。
为了缩小网域控制器和虚拟机的受攻击面，请使用防火墙禁止任何并必要的网络通信。有关从 VPC 或本地网络访问 Active Directory 所需的防火墙配置的详细信息，请参阅我们关于跨防火墙使用 Active Directory的指南。
将 Active Directory 资源和用户组织到管理层级中
就 Active Directory 的整体安全性而言，Active Directory 林中的某些机器比其他机器更为重要。网域控制器和管理虚拟机就是两种特别重要的机器，因此对潜在的攻击特别敏感。
要确定每台机器的重要性，请使用层级分类。适当的层数取决于您的特定设置，但您可以从区分三个层级开始：
层级 0（非常重要）：此层级包括对 Active Directory 林的安全性至关重要的所有机器。只要有一个层级 0 机器被入侵，您就必须假定整个林都已被入侵。
层级 1（重要）：此层级包括您环境中的大多数服务器，例如应用服务器和数据库服务器。被入侵的层级 1 服务器可能会对业务产生重大影响，但不会对整个林造成直接威胁。
层级 2（普通）：此层级包括工作站或其他通用机器。一般认为层级 2 机器被入侵对业务和整体安全性的影响有限。
尽管被入侵的层级 2 机器的直接影响似乎有限，但是存在连锁效应的风险：当具有层级 0 或层级 1 机器管理员权限的用户被诱使登录到被入侵的层级 2 机器时，他们就可能成为键盘记录器或其他形式的凭证盗窃的受害者。然后，被捕获的凭据可能会被用于攻击更高层级的机器，从而导致总体影响升级。
为避免这种连锁反应，请确保不仅对机器，同时也对用户账号进行分类，并限制这些用户可以访问的机器：
层级 0（非常重要）：有权访问层级 0 机器的用户。
层级 1（重要）：有权访问层级 1 机器的用户。
层级 2（普通）：有权访问层级 2 机器的用户。
以下表为准则设置哪些用户应有权访问哪些资源：
| 组 | 层级 | 网域访问权限 | 层级 0 计算机访问权限 | 层级 1 计算机访问权限 | 层级 2 计算机访问权限 |
|---|---|---|---|---|---|
| Active Directory 管理员 | 0 | 管理员 | 受限用户 | 已屏蔽 | 已屏蔽 |
| 管理服务器管理员 | 0 | 受限用户 | 管理员 | 已屏蔽 | 已屏蔽 |
| 服务器管理员 | 1 | 受限用户 | 已屏蔽 | 管理员 | 已屏蔽 |
| VDI 工作站管理员 | 2 | 受限用户 | 已屏蔽 | 已屏蔽 | 管理员 |
| VDI 工作站用户 | 2 | 受限用户 | 已屏蔽 | 已屏蔽 | 受限用户 |
有关在 Active Directory 中实施管理层级模型的详细信息和最佳做法，请参阅 Microsoft 文档。
在 Active Directory 林中使用管理层级模型时，请确保林信任关系不会破坏其完整性。如果可信林也使用分层管理模型，请使用选择性身份验证来确保仅允许来自可信林的用户访问同一层级中的资源：
如果可信林未实施分层管理，则将可信林映射到一个特定层级，并使用选择性身份验证来确保仅允许来自可信林的用户访问该特定层级的资源。
为本地主机使用 VPC Service Controls 和专用 Google 访问通道
托管式 Microsoft AD API 允许重置管理员密码和执行其他敏感操作。对于关键的生产部署，我们建议为本地主机启用 VPC Service Controls 并使用专用 Google 访问通道，以提高安全性。
管理
以下部分详细介绍与 Active Directory 管理相关的最佳做法。
使 Google Cloud 和 Active Directory 资源结构保持一致
当您在 Google Cloud 上部署新的 Active Directory 域或林时，必须定义组织单位 (OU) 结构以使用 Active Directory 域来整理资源。你可以创建一个与您的 Google Cloud 资源层次结构一致的组织单位结构，而不是设计全新的结构或应用您在本地环境中使用的结构：
如果您使用分层管理模型，则顶级组织单位必须反映您的管理层级。
对于每个层级，为用户和组创建组织单位。如果您计划管理大量用户和组，请根据需要创建子组织单位。
为每个层级创建一个
Projects组织单位，并为每个包含 Active Directory 资源的 Google Cloud 项目创建子组织单位。使用项目专用的子组织单位管理与该项目的 Google Cloud 资源对应的计算机账号、服务账号或其他 Active Directory 资源。确保组织单位和项目之间是 1:1 映射。
下图显示了遵循这些原则的示例层次结构：
如果包含 Active Directory 资源的项目数量适中，您可以在 Projects 组织单位下创建扁平的组织单位结构。如果您预计需要管理大量项目，并且已将 Google Cloud 资源层次结构设计为使用多层文件夹，请考虑在 Projects 组织单位下反映此文件夹结构。
使 Active Directory 组织单位结构与 Google Cloud 资源层次结构保持一致具有以下优点：
使用 IAM 政策将管理员权限委派给 Google Cloud 项目时，您可能还需要授予项目用户某些 Active Directory 权限。例如，Compute Engine 管理员可能需要能够将机器加入到某个组织单位下的网域。通过使组织单位与 Google Cloud 项目保持一致，您可以在 Active Directory 中以与在 Google Cloud 中相同的粒度水平授予权限。
如果您计划使用组策略对象 (GPO) 来管理计算机，则反映 Google Cloud 资源层次结构的组织单位结构可帮助您确保 GPO 一致地应用于给定项目或文件夹的所有虚拟机。
如果您将跨林信任与条件身份验证结合使用，则可以使用与 Google Cloud 项目对应的组织部门来按项目授予允许进行身份验证权限。
在 Google Cloud 中删除项目时，您只需删除关联的组织单位，从而降低将过时的资源保留在目录中的风险。
如果您认为组织单位结构需要不同于项目结构，这可能表明您的项目结构的粒度太细或太粗。
使用 Google 时间服务器
Kerberos 身份验证依赖于时间戳作为其协议的一部分。为了使身份验证成功，客户端和服务器机器的时钟必须在一定的误差范围内保持同步。默认情况下，Active Directory 允许的差异不超过 5 分钟。
在本地 Active Directory 环境中，以下是用于同步时间的默认配置：
- 已加入网域的机器会将其时间与网域控制器同步。
- 网域控制器将其时间与网域的 PDC 模拟器同步。
- 所有网域的 PDC 模拟器都会将其时间与林根网域的 PDC 模拟器同步。
在此配置中，林根网域的 PDC 模拟器是 Active Directory 的最终时间源，并且通常会将此机器配置为使用外部 NTP 服务器作为时间源。
在 Compute Engine 上，Windows 虚拟机的默认配置是使用元数据服务器 (metadata.google.internal) 作为 NTP 服务器，而该服务器又依赖 Google 的 NTP 服务器来获取正确的时间。将虚拟机加入 Active Directory 域不会更改此默认配置。
除非您的林根网域的 PDC 模拟器部署在 Google Cloud 外部，否则请保留 Compute Engine 的默认配置。
如果您的 PDC 模拟器部署在 Google Cloud 外部，请将其配置为使用 time.google.com 作为 NTP 来源。或者，您可以通过重新配置 Compute Engine 虚拟机以使用 DOMHIER NTP 源并配置防火墙规则以允许 NTP 入站流量 (UDP/123) 进入您的域控制器来恢复与 PDC 模拟器同步时间的默认 Active Directory 行为。
整合和监控审核日志
当您在 Google Cloud 上部署 Active Directory 时，您的 Active Directory 林和 Google Cloud 项目的安全性是相互关联的：与 Google Cloud 中的可疑活动可能会使您的 Active Directory 面临风险一样，Active Directory 和 Windows 中的可疑活动可能会危及某些其他资源的安全性。
一致的审核日志是一项重要的工具，可用于及早发现威胁或配置错误，并使您能够重建和检查过去的活动。借助 Cloud Audit Logging，您可以捕获和分析管理员活动日志和数据访问日志。同样，您可以使用防火墙规则记录和VPC 流日志来分析网络流量。但是，这些平台服务无法察觉 Active Directory 中发生的与安全性相关的事件。要建立覆盖平台相关审核事件和 Active Directory 相关审核事件的一致审核跟踪，请在网域控制器和加入网域的机器上安装 Cloud Logging 代理，以将 Windows 安全性事件日志导出到 Cloud Logging。
默认情况下，Windows 安全性事件日志可能不会捕获您的审核目的所需的所有事件。请参阅 Microsoft 关于配置审核政策和监控 Active Directory 入侵迹象的建议，以确保捕获所有相关的审核事件。
在处理大量事件时，很容易遗漏重要事件。为避免遗漏重要事件，请为可能特别重要或可疑的事件创建基于日志的指标，并考虑配置提醒以在事件比率发生变化或超过可接受阈值时收到通知。
后续步骤
确定哪种在混合环境中使用 Active Directory 的模式最适合您的情况。
试用其他 Google Cloud 功能。查看我们的教程。