迁移 Active Directory - AWS 规范性指导
评测动员迁移

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

迁移 Active Directory

Active Directory 是适用于许多企业环境的典型身份和访问管理解决方案。DNS、用户和机器管理的耦合使得 Active Directory 成为 Microsoft 和 Linux 工作负载进行集中用户身份验证的理想选择。在规划您的云转型或 AWS 之旅时，您所面临的选择是，要将 Active Directory 扩展到 AWS，还是要使用托管服务来减轻目录服务基础设施的管理负担。我们建议您在为组织确定正确的方法时，了解每个选项的风险和优势。

Active Directory 迁移的正确策略是适合您组织的需求并使您能够充分利用 AWS Cloud 的策略。这不仅需要考虑目录服务本身，还需要考虑它们与其他 AWS 服务交互的方式。此外，您还必须考虑管理 Active Directory 的团队的长期目标。

除了 Active Directory 迁移之外，您还必须决定 Active Directory 所在位置的账户结构、您的 AWS 账户的网络拓扑以及您计划使用哪些需要 Active Directory 的 DNS 集成和其他潜在的 AWS 服务。有关设计您的账户拓扑和其他迁移策略注意事项的信息，请参阅本指南的基础最佳实践部分。

评测

要成功实施迁移，评测现有基础设施并了解您的环境所需的关键功能是非常重要的。我们建议您在选择迁移方式之前，先查看以下几个方面：

  • 查看现有的 AWS 基础设施设计 – 请遵循本指南的 Windows 环境发现部分中的指导进行操作，如果您还不知道现有 Active Directory 基础设施的占用空间和基础设施要求，请使用评测方法来帮助查看现有的 Active Directory 基础设施。我们建议您在 AWS 中对 Active Directory 基础设施使用 Microsoft 提供的规定大小调整功能。如果您要将 Active Directory 基础设施扩展到 AWS，则可能只需要在 AWS 中占用部分 Active Directory 身份验证空间。因此，除非您要将 Active Directory 占用空间完全迁移到 AWS，否则请避免过度扩大您的环境。有关更多信息，请参阅 Microsoft 文档中的 Capacity planning for Active Directory Domain Services。

  • 查看现有的本地 Active Directory 设计 – 查看本地（自行管理的）Active Directory 的当前利用率。如果您要将 Active Directory 环境扩展到 AWS，则我们建议您在 AWS 中的多个域控制器上运行 Active Directory，即使将其作为本地环境的扩展也是如此。这种方式符合 AWS Well-Architected Framework，即通过在多个可用区中部署实例来针对潜在故障进行设计。

  • 确定应用程序和网络中的依赖项 – 在选择最佳迁移策略之前，您必须充分了解贵组织需要的 Active Directory 的所有功能才能实现相应功能。这意味着，当在托管服务或自托管之间进行选择时，了解每种服务的选项很重要。在决定哪种迁移适合您时，请考虑以下项目：

    • 访问权限要求 – 控制 Active Directory 的访问权限要求将为您规定正确的迁移路径。如果您需要针对 Active Directory 域控制器的完全访问权限才能安装任何类型的代理以符合合规性法规要求，则 AWS Managed Microsoft AD 可能不是适合您的解决方案。相反，您可研究 Active Directory 从域控制器到 AWS 账户中的 Amazon EC2 的扩展。

    • 迁移时间表 – 如果您的迁移时间较长，但没有明确的完成日期，请确认您是否有应急措施来管理云端和本地环境中的实例。身份验证是应对 Microsoft 工作负载的关键组件，可避免出现管理问题。我们建议您在迁移初期就规划迁移 Active Directory。

  • 备份策略 – 如果您使用现有 Windows 备份来捕获 Active Directory 域控制器的系统状态，则可以继续使用 AWS 中的现有备份策略。此外，AWS 还提供技术选项来帮助您备份实例。例如，AWS Data Lifecycle Manager、AWS Backup 和 AWS Elastic Disaster Recovery 是用于备份 Active Directory 域控制器的受支持技术。为避免出现问题，最好不要依赖于 Active Directory 的还原。建议的最佳实践是构建一个弹性架构，但如果需要恢复，则制定备份方法是至关重要的。

  • 灾难恢复（DR）需求 – 如果要将 Active Directory 迁移到 AWS，则必须针对发生灾难时的恢复能力进行设计。如果要将现有 Active Directory 移至 AWS，则可以使用辅助 AWS 区域，并使用 Transit Gateway 将两个区域连接起来，以允许进行复制。这通常是首选方法。有些组织对在隔离环境中测试失效转移有多种要求，在隔离环境中，您需要将主站点和辅助站点之间的连接切断数天以测试可靠性。如果贵组织要求这样做，则可能需要一些时间来清理 Active Directory 中的脑裂问题。您或许可以将 AWS Elastic Disaster Recovery 用作主动/被动实施，在这种实施中，您将灾难恢复站点作为失效转移环境，并且必须在隔离环境中定期测试灾难恢复策略。评测向 AWS 的迁移时，针对您组织的恢复时间目标（RTO）和恢复点目标（RPO）要求进行规划是一个重要因素。请确保您已定义您的要求并制定测试和失效转移计划，以验证实施。

动员

满足贵组织和运营需求的正确策略是将 Active Directory 迁移或扩展到 AWS 时的重要因素。选择与 AWS 服务的集成方式对于采用 AWS 至关重要。请确保选择符合您业务要求的 Active Directory 或 AWS Managed Microsoft AD 的方法扩展。像 Amazon RDS 这样的服务中有一些功能依赖于使用 AWS Managed Microsoft AD。请确保评估 AWS 服务限制，以确定 Amazon EC2 和 AWS Managed Microsoft AD 上的 Active Directory 是否存在兼容性限制。我们建议您在规划流程中考虑以下集成点。

请考虑在 AWS 中使用 Active Directory 的以下原因：

  • 让 AWS 应用程序与 Active Directory 配合使用

  • 使用 Active Directory 登录 AWS 管理控制台

让 AWS 应用程序与 Active Directory 配合使用

您可以启用多个 AWS 应用程序和服务，例如 A WS Client VPN、AWS 管理控制台、AWS IAM 身份中心（AWS Single Sign-On 的继任者）、Amazon Ch ime、A mazon C onnect、适用于 Windows 文件服务器的 QuickSight Amazon FSx、亚马逊、 WorkDocs亚马 WorkMail逊、Amazon 和 Amazon 使用你的 AWS 托管 WorkSpaces微软 AD 目录。当您启用目录中的一个 AWS 应用程序或服务时，您的用户可使用其 Active Directory 凭证访问此应用程序或服务。您可以使用熟悉的 Active Directory 管理工具来应用 Active Directory 组策略对象（GPO），以通过将您的实例加入 AWS Managed Microsoft AD 目录来集中管理 Amazon EC2 for Windows 或 Amazon EC2 for Linux 实例。

您的用户可以使用其 Active Directory 凭证登录您的实例。从而无需使用单独的实例凭证或分配私钥 (PEM) 文件。这使您能够通过使用您已使用的 Active Directory 用户管理工具，更轻松地立即授予或撤销用户的访问权限。

使用 Active Directory 登录 AWS 管理控制台

AWS Managed Microsoft AD 允许您向目录的成员授予对 AWS 管理控制台的访问权限。默认情况下，目录成员无权访问任何 AWS 资源。可将 AWS Identity and Access Management（IAM）角色分配给目录成员，以便向其授予对各种 AWS 服务和资源的访问权限。IAM 角色定义目录成员所拥有的服务、资源和访问权限级别。

例如，您可以允许您的用户使用其 Active Directory 凭证登录 AWS 管理控制台。为此，请在您的目录中将 AWS 管理控制台作为应用程序启用，然后为您的 Active Directory 用户和组分配 IAM 角色。当您的用户登录 AWS 管理控制台时，他们将担任 IAM 角色来管理 AWS 资源。这使您可以轻松为您的用户授予对 AWS 管理控制台的访问权限，而无需配置和管理单独的 SAML 基础设施。有关更多信息，请参阅 AWS Security Blog 中的 How AWS IAM Identity Center Active Directory sync enhances AWS application experiences。您可以向目录或本地 Active Directory 中的用户账户授予访问权限。这使用户能够使用其现有凭证和权限登录 AWS 管理控制台或通过 AWS 命令行界面（AWS CLI）登录，以通过将 IAM 角色直接分配给现有用户账户来管理 AWS 资源。

目录必须首先具有访问 URL，然后您才能向目录成员授予控制台访问权限。有关如何查看目录详细信息和获取访问 URL 的更多信息，请参阅《AWS Directory Service Administration Guide》中的 View directory information。有关如何创建访问 URL 的更多信息，请参阅《AWS Directory Service Administration Guide》中的 Creating an access URL。有关如何创建 IAM 角色并将其分配给目录成员的更多信息，请参阅《AWS Directory Service Administration Guide》中的 Grant users and groups access to AWS resources。

请考虑 Active Directory 的以下迁移选项：

  • 扩展 Active Directory

  • 迁移到 AWS Managed Microsoft AD

  • 使用信任将 Active Directory 与 AWS Managed Microsoft AD 连接

  • 将 Active Directory DNS 与 Amazon Route 53 集成

扩展 Active Directory

如果您已有一个 Active Directory 基础设施并且要在将 Active Directory 感知型工作负载迁移至 AWS Cloud 时使用它，则 AWS Managed Microsoft AD 可起到帮助作用。您可以使用信任将 AWS Managed Microsoft AD 连接到现有 Active Directory。这意味着您的用户可以使用其本地 Active Directory 凭证访问 Active Directory 感知型应用程序和 AWS 应用程序，而无需您同步用户、组或密码。例如，您的用户可以使用他们现有的 Active Directory 用户名和 WorkSpaces 密码登录 AWS 管理控制台。此外，当您使用 AWS 托管 Microsoft AD 等支持 SharePoint AWS Directory 的应用程序时，登录的 Windows 用户无需再次输入凭证即可访问这些应用程序。

除了使用信任之外，您还可以通过将 Active Directory 部署为在 AWS 中的 EC2 实例上运行来扩展 Active Directory。您可以自行完成此操作，也可以与 AWS 合作来帮助您完成此流程。我们建议您在将 Active Directory 扩展到 AWS 时，在不同的可用区中至少部署两个域控制器。根据您在 AWS 中拥有的用户和计算机数量，您可能需要部署两个以上的域控制器，但出于恢复能力考虑，我们建议的最低数量为两个。您还可以通过使用 Active Directory 迁移工具包（ADMT）和密码导出服务器（PES）来执行迁移，将本地 Active Directory 域迁移到 AWS，以免除 Active Directory 基础设施的运营负担。您还可以使用 Active Directory 启动向导在 AWS 上部署 Active Directory。

迁移到 AWS Managed Microsoft AD

您可以应用两种机制在 AWS 中使用 Active Directory。一种方法是采用 AWS Managed Microsoft AD 将您的 Active Directory 对象迁移到 AWS。这包括用户、计算机、组策略等。第二种机制是手动方法，即导出所有用户和对象，然后通过使用 Active Directory 迁移工具手动导入用户和对象。

迁移到 AWS Managed Microsoft Active Directory 还有其他原因：

您可以跨多个 AWS 账户共享 AWS Managed Microsoft AD。这使您能够管理 Amazon EC2 等 AWS 服务，而无需为每个账户和每个 Amazon Virtual Private Cloud（Amazon VPC）操作目录。您可以使用任何 AWS 账户中的目录以及 AWS 区域内的任何 Amazon VPC 中的目录。此功能可让您跨多个账户和 VPC，使用单个目录更轻松且更经济高效地管理可感知目录的工作负载。例如，您现在可以使用单个 AWS Managed Microsoft AD 目录，跨多个账户和 Amazon VPC 轻松管理部署在 EC2 实例中的 Microsoft 工作负载。当您与其他 AWS 账户共享 AWS Managed Microsoft AD 目录时，您可以使用 Amazon EC2 控制台或 AWS Systems Manager 从账户和 AWS 区域中的任意 Amazon VPC 无缝加入实例。

您可以通过消除手动将实例加入域或者在各个账户和 Amazon VPC 中部署目录的需求，从而在 EC2 实例上快速部署目录感知型工作负载。有关更多信息，请参阅《AWS Directory Service Administration Guide》中的 Share your directory。请记住，共享 AWS Managed Microsoft AD 环境是有成本的。您可以通过使用 Amazon VPC 对等或 Transit Gateway 对等，从其他网络或账户与 AWS Managed Microsoft AD 环境进行通信，因此可能不需要共享。如果您打算将目录与以下服务一起使用，则必须共享域：Amazon Aurora MySQL、Amazon Aurora PostgreSQL、Amazon FSx、Amazon RDS for MariaDB、Amazon RDS for MySQL、Amazon RDS for Oracle、Amazon RDS for PostgreSQL 和 Amazon RDS for SQL Server。

对 AWS Managed Microsoft AD 使用信任

要向现有目录中的用户授予对 AWS 资源的访问权限，您可以对您的 AWS Managed Microsoft AD 实施使用信任。也可以在 AWS Managed Microsoft AD 环境之间创建信任。有关更多信息，请参阅 AWS Security Blog 中的 Everything you wanted to know about trusts with AWS Managed Microsoft AD。

将 Active Directory DNS 与 Amazon Route 53 集成

迁移到 AWS 时，您可以使用 Route 53 解析器将 DNS 集成到您的环境中，以允许（通过使用其 DNS 名称）访问您的服务器。我们建议您使用 Route 53 解析器端点来完成此操作，而不是修改 DHCP 选项集。与修改 DHCP 选项集相比，这是管理您的 DNS 配置的一种更集中的方法。此外，您可以充分利用各种解析器规则。有关更多信息，请参阅 Networking & Content Delivery Blog 中的 Integrating your Directory Service’s DNS resolution with Amazon Route 53 Resolvers，以及 AWS Prescriptive Guidance 文档中的 Set up DNS resolution for hybrid networks in a multi-account AWS environment。

迁移

在您开始迁移到 AWS 时，我们建议您考虑使用配置和工具选项来帮助您迁移。同样重要的是，要考虑环境的长期安全和运营方面。

请考虑以下选项：

  • 云原生安全性

  • 用于将 Active Directory 迁移到 AWS 的工具

云原生安全性

  • Active Directory 控制器的安全组配置 – 如果您使用的是 AWS Managed Microsoft AD，则域控制器附带 VPC 安全配置，用于限制对域控制器的访问。您可能需要修改安全组规则，以允许访问某些潜在使用案例。有关安全组配置的更多信息，请参阅《AWS Directory Service Administration Guide》中的 Enhance your AWS Managed Microsoft AD network security configuration。我们建议您不要允许用户修改这些群组或将其用于任何其他 AWS 服务。如果用户修改它们以阻止必要的通信，则允许其他用户使用它们可能会导致 Active Directory 环境的服务中断。

  • 与 Amazon CloudWatch Logs 集成，获取活动目录事件日志 — 如果您运行的是 AWS 托管 Microsoft AD 或使用自我管理的 Active Directory，则可以利用亚马逊 CloudWatch 日志来集中您的活动目录日志。您可以使用 CloudWatch 日志将身份验证、安全和其他日志复制到 CloudWatch。这为您提供了一种在一个位置搜索日志的简便方法，并且可以帮助满足某些合规性要求。我们建议与 CloudWatch Logs 集成，因为它可以帮助您更好地应对环境中未来发生的事件。有关更多信息，请参阅《AWS Directory Service 管理指南》中的 “为 AWS 托管活动目录启用亚马逊 CloudWatch CloudWatch 日志” 和 AWS 知识中心的 “适用于 Windows 事件日志的亚马逊日志”。

用于将 Active Directory 迁移到 AWS 的工具

我们建议您使用 Active Directory 迁移工具（ADMT）和密码导出服务器（PES）来执行迁移。这样您就能够轻松地将用户和计算机从一个域迁移到另一个域。如果您使用 PES 或从一个托管 Active Directory 域迁移到另一个域，请记住以下注意事项：

  • 适用于用户、组和计算机的 Active Directory 迁移工具（ADMT） – 您可以使用 ADMT 将用户从自行管理的 Active Directory 迁移到 AWS Managed Microsoft AD。一个重要的考虑因素是迁移时间表和安全标识符（SID）历史记录的重要性。迁移期间不会转移 SID 历史记录。如果迫切需要支持 SID 历史记录，则考虑在 Amazon EC2 上使用自行管理的 Active Directory 而不是 ADMT，这样您就可以维护 SID 历史记录。

  • 密码导出服务器（PES）– PES 可用于将密码迁移到 AWS Managed Microsoft AD 中，但不能将其迁移出 AWS Managed Microsoft AD。有关如何从目录中迁移用户和密码的信息，请参阅 AWS Security Blog 中的 How to migrate your on-premises domain to AWS Managed Microsoft AD using ADMT 和 Microsoft 文档中的 Password Export Server version 3.1 (x64)。

  • LDIF – LDAP 数据交换格式（LDIF）是一种用于扩展 AWS Managed Microsoft AD 目录架构的文件格式。LDIF 文件包含向目录中添加新对象和属性的必要信息。文件必须符合 LDAP 语法标准，并且必须包含文件添加的每个对象的有效对象定义。创建 LDIF 文件后，必须将该文件上传到目录以扩展其架构。有关使用 LDIF 文件扩展 AWS Managed Microsoft AD 目录的架构的更多信息，请参阅《AWS Directory Service Administration Guide》中的 Extending the schema of AWS Managed AD。

  • CSVDE – 在某些情况下，您可能需要在不创建信任和使用 ADMT 的情况下将用户导出和导入到目录中。尽管并不理想，但您可以使用 Csvde（命令行工具）将 Active Directory 用户从一个域迁移到另一个域。要使用 Csvde，您必须创建一个包含用户信息（例如用户名、密码和组成员资格）的 CSV 文件。然后，您可以使用 csvde 命令将用户导入到新域中。您也可以使用此命令从源域中导出现有用户。如果您要从其他目录源（例如 SAMBA 域服务）迁移到 Microsoft Active Directory，则这可能会很有帮助。有关更多信息，请参阅 AWS Security Blog 中的 How to Migrate Your Microsoft Active Directory Users to Simple AD or AWS Managed Microsoft AD。

其他 资源