轻松上云，使用 ADMT 将本地域迁移到 AWS Managed Microsoft AD

客户经常向我们询问如何将其本地 Active Directory（AD）域迁移到 AWS，从 AD 基础设施的运营管理中解放出来。他们往往不知道如何让迁移变得简单易行。使用 CSVDE 实用工具的常见方法不会迁移用户密码等属性。这就给迁移带来了困难，而且迁移的大部分工作都需要人工完成，在迁移到新目录时可能会带来操作和安全方面的挑战。那么发生了什么变化？

现在，您可以使用 Active Directory Migration Toolkit（ADMT）和 Password Export Service（PES），将自主管理型 AD 迁移到 AWS Directory Service for Microsoft Active Directory（也称为 AWS Managed Microsoft AD）。这让您可以更轻松地为用户迁移 AD 对象和加密密码。

AWS Managed Microsoft AD 是一项基于 Microsoft Active Directory 的托管服务。AWS 提供域控制器的运行管理，您可以使用标准的 AD 工具来管理用户、组和计算机。AWS Managed Microsoft AD 使您能够利用内置的 Active Directory 功能（如组策略、信任和单点登录），并有助于您轻松地将依赖于 AD 的工作负载迁移到 AWS Cloud 中。使用 AWS Managed Microsoft AD，您可以将 Amazon EC2 和 Amazon RDS for SQL Server 实例加入域，并将 AWS 企业 IT 应用程序（如 Amazon WorkSpaces 和 AWS IAM Identity Center）与 Active Directory 用户和组一起使用。

在这篇博客中，我们将向您展示如何将现有的 AD 对象迁移到 AWS Managed Microsoft AD。对象的来源可以是在 EC2 上运行的自主管理型 AD，也可以是本地、共用位置，甚至是其他云提供商。我们将演示如何使用 ADMT 和 PES 迁移对象，包括用户（及其密码）、组和计算机。

本文假设您熟悉 AD 以及如何使用远程桌面协议客户端签署和使用 EC2 Windows 实例。

背景

在这篇博客中，我们会将用户和计算机对象以及密码迁移到新的 AWS Managed Microsoft AD 目录中。来源将是本地域。

此迁移示例将针对一个相当简单的使用案例。拥有复杂源域或林的大型客户可能需要更复杂的流程，来将用户、组和计算机映射到 AWS Managed Microsoft AD 的单一 OU 结构。例如，您可能希望一次迁移一个 OU。拥有单一域林的客户的迁移步骤可能更少。同样，您在 ADMT 中可能选择的选项也会根据您要实现的目标而有所不同。

要执行迁移，我们将使用 AWS Managed Microsoft AD 中的 Admin 用户账户。AWS 为 AWS Managed Microsoft AD 域中的一个组织单位（OU，organizational unit）创建 Admin 用户账户，并将管理权限委托给该账户。该账户拥有管理域所需的大部分权限，以及完成此迁移所需的所有权限。

在这个示例中，我们有一个名为 source.local 的源域，该域运行在 10.0.0.0/16 的网络范围内，我们要将用户、组和计算机迁移到 AWS Managed Microsoft AD 中名为 destination.local 的目标域，该目标域运行在 192.168.0.0/16 的网络范围内。

要将用户从 source.local 迁移到 destination.local，我们需要一台迁移计算机，将其加入到 destination.local 域，并在该域上运行 ADMT。我们还使用这台计算机在 AWS Managed Microsoft AD 上执行管理任务。作为 ADMT 的先决条件，我们必须在迁移计算机上安装 Microsoft SQL Express 2019。我们还需要一个在源和目标 AD 域中都具有权限的管理账户。为此，我们将使用 AD 信任，并将 AWS Managed Microsoft AD 管理账户从 destination.local 添加到 source.local 域。接下来，我们将在迁移计算机上安装 ADMT，并在一个 source.local 域控制器上运行 PES。最后，我们将迁移用户和计算机。

注意：如果使用 ADMT 和 PES 迁移用户密码，并且在客户端计算机上禁用了支持的 Kerberos 加密类型 RC4_HMAC_MD5，则用户的 Kerberos 身份验证会失败，直到他们重置密码。出现这种情况的原因是 PES 工具的设计及其用于同步密码的方法。我们建议用户在迁移后重置密码。

在此示例中，我们将迁移一些用户、组和计算机，如这些屏幕截图中的源域所示：

图 1：源用户示例

图 2：客户端计算机示例

在这篇博文的余下部分，我们将向您展示如何分 5 个主要步骤进行迁移：

准备域林、迁移计算机和管理账户。
在迁移计算机上安装 SQL Express 和 ADMT。
配置 ADMT 和 PES。
迁移用户和组。
迁移计算机。

第 1 步：准备域林、迁移计算机和管理账户

要将用户和密码从源域迁移到 AWS Managed Microsoft AD，必须具备双向林信任。通过从源域到 AWS Managed Microsoft AD 的信任，可以将 AWS Managed Microsoft AD 中的管理账户添加到源域。这是必要的，这样您就可以在源 AD 目录中授予 AWS Managed Microsoft AD Admin 账户权限，使其可以读取要迁移的属性。我们已经在这些域之间建立了双向林信任。您也应该按照本指南进行操作。建立了您的信任后，在 AWS 管理控制台中应该会显示已验证。

ADMT 工具应安装在目标域 destination.local 中不是域控制器的计算机上。为此，我们将在与域控制器相同的 VPC 中启动一个 EC2 实例，并使用 EC2 无缝域加入功能将其添加到 destination.local 域中。此实例将充当 ADMT 传输计算机。

启动 Microsoft Windows Server 2019 实例。
完成到目标域 destination.local 的域加入。您可以手动完成此操作，也可以使用 AWS Systems Manager 完成无缝域加入，如此处所述。
使用 RDP 登录实例，然后使用 Active Directory Users and Computers（ADUC），将 AWS Managed Microsoft AD 管理用户从 destination.local 域添加到 source.local 域的内置管理员组（无法将 Admin 用户添加为域管理员）。有关如何设置此实例来使用 ADUC 的信息，请参阅此文档。

图 3：“管理员的属性”对话框

第 2 步：在迁移计算机上安装 SQL Express 和 ADMT

接下来，我们需要按照以下步骤在迁移计算机上安装 SQL Express 和 ADMT。

在迁移计算机上安装 Microsoft SQL Express 2019（基本安装）。
从 Microsoft 下载 ADMT v3.2。
运行安装程序，在设置工具时，在向导的数据库选择页面的数据库（服务器/实例）中，键入我们之前为与 ADMT 配合使用而安装的 Microsoft SQL Express 本地实例。

$图 4：指定“数据库（服务器\实例）”$

图 4：指定“数据库（服务器\实例）”
在向导的数据库导入页面上，选择否，不从现有数据库导入数据（默认）。

图 5：“数据库导入”对话框
使用所有默认选项完成其余安装过程。

第 3 步：配置 ADMT 和 PES

我们将使用 PES 进行加密密码同步。在配置之前，我们需要创建一个加密密钥，用于在此过程中对密码迁移进行加密。

在 ADMT 传输计算机上，打开提升的命令提示符，并使用以下格式创建加密密钥。
```
admt key /option:create /sourcedomain:<SourceDomain> /keyfile:<KeyFilePath> /keypassword:{<password>|*}
```
如下示例：
```
admt key /option:create /sourcedomain:source.local /keyfile:c:\ /keypassword:password123
```
注意：如果出现找不到命令的错误提示，请关闭并重新打开命令提示符，刷新 ADMT 可执行文件的路径位置，然后重试。
将输出的密钥文件复制到其中一个 source.local 域控制器上。
在一个 source.local 域控制器上下载 Password Export Server。
开始安装，然后在 ADMT 密码迁移 DLL 设置窗口中，浏览到您在上一步中创建的加密文件。
出现提示时，输入 ADMT 加密命令中使用的密码。
使用本地系统账户运行 PES。请注意，这将提示您重新启动正在安装 PES 的域控制器。
域控制器重启后，打开 services.msc，启动 Password Export Server Service，该服务当前设置为手动。如果您的 DC 有可能在迁移结束前再次重启，您可以选择将其设置为自动。

图 6：启动 Password Export Server Service
您现在可以打开 Active Directory 迁移工具：控制面板 > 系统和安全 > 管理工具 > Active Directory 迁移工具。
右键单击 Active Directory 迁移工具来查看迁移选项：

图 7：迁移选项列表

第 4 步：迁移用户和组

在域选择页面中，选择或键入源域和目标域，然后选择下一步。
在用户选择页面上，选择要迁移的用户。如果域较大，可以使用包含文件。选择下一步。
在组织单位选择页面上，选择要将用户迁移到的目标 OU，然后选择下一步。AWS Managed Microsoft AD 为您提供了一个托管 OU，您可以在其中创建 OU 树结构。在此示例中，我们将它们放置在用户 OU 中：
```
LDAP://destination.local/OU=Users,OU=destination,DC=destination,DC=local
```
在密码选项页面上，选择迁移密码，然后选择下一步。这将联系在源域控制器上运行的 PES。
在账户过渡页面上，决定如何处理用户对象的迁移。在此示例中，我们将从源域复制状态。在进行长时间的分阶段迁移时，用户可能需要在迁移完成前访问源域和目标域中的资源，这时迁移 SID 历史记录就非常有用。目前，AWS Managed Microsoft AD 不支持迁移用户 SID。我们选择目标与源相同，然后选择下一步。同样，您的选择也可能不同。

图 8：“账户过渡选项”对话框
现在，让我们来自定义传输情况。下面的屏幕截图显示了用户账户迁移向导的用户选项页面上的常用选项：

图 9：常用用户选项

迁移过程可能不止一次，因此选择如何处理现有对象非常重要。对我们来说，这将是一次运行，但默认行为是，如果对象已经存在，则不迁移（见下面冲突管理页面的图片）。如果要进行多次迁移，则需要考虑合并冲突对象的选项。您选择的方法将取决于您的使用案例。如果您不知道从哪里开始，请阅读这篇文章。

图 10：“冲突管理”对话框

在我们的示例中，您可以看到我们的 3 个用户和他们所属的任何组都已迁移。

图 11：“迁移进度”窗口

我们可以通过检查用户是否存在于我们的 destination.local 域来验证这一点：

图 12：检查用户是否存在于 destination.local 域中

第 5 步：迁移计算机

现在，我们来看看计算机对象。

打开 Active Directory 迁移工具：控制面板 > 系统和安全 > 管理工具 > Active Directory 迁移工具。
右键单击 Active Directory 迁移工具，选择计算机迁移向导。
选择要迁移到新域的计算机。我们将选择四台计算机进行迁移。

图 13：四台将要迁移的计算机
在翻译对象页面上，选择要在迁移期间重新应用的访问控制，然后选择下一步。

图 14：“转换对象”对话框

迁移过程将显示已完成，但我们需要确保整个过程有效。
要验证迁移是否成功，请选择关闭，迁移工具将打开一个新窗口，其中包含迁移日志链接。检查日志文件，查看是否已开始迁移这四台计算机的过程：
2017-08-11 04:09:01 The Active Directory Migration Tool Agent will be installed on WIN-56SQFFFJCR1.source.local

2017-08-11 04:09:01 The Active Directory Migration Tool Agent will be installed on WIN-IG2V2NAN1MU.source.local

2017-08-11 04:09:01 The Active Directory Migration Tool Agent will be installed on WIN-QKQEJHUEV27.source.local

2017-08-11 04:09:01 The Active Directory Migration Tool Agent will be installed on WIN-SE98KE4Q9CR.source.local

如果管理员用户无法访问源域共享中计算机上的 C$ 或 admin$ 共享，则代理安装将失败，如下所示：

2017-08-11 04:09:29 ERR2:7006 Failed to install agent on \\WIN-IG2V2NAN1MU.source.local, rc=5 Access is denied.

安装代理后，将从 source.local 执行域分离，并加入 desintation.local。成功后，日志文件将更新：

2017-08-11 04:13:29 Post-check passed on the computer ‘WIN-SE98KE4Q9CR.source.local’.The new computer name is ‘WIN-SE98KE4Q9CR.destination.local’.

2017-08-11 04:13:29 Post-check passed on the computer ‘WIN-QKQEJHUEV27.source.local’.The new computer name is ‘WIN-QKQEJHUEV27.destination.local’.

2017-08-11 04:13:29 Post-check passed on the computer ‘WIN-56SQFFFJCR1.source.local’.The new computer name is ‘WIN-56SQFFFJCR1.destination.local’.

然后，您可以查看目标域中的新计算机对象。
登录一台旧的 source.local 计算机，查看计算机的系统属性，确认该计算机现在是新的 destination.local 域的成员。

图 15：确认计算机是 destination.local 域的成员

总结

在这个简单的示例中，我们展示了如何将用户及其密码、组和计算机对象从 Active Directory 的本地部署迁移到 AWS Managed Microsoft AD。我们创建了一个管理实例，在该实例上运行 SQL Express 和 ADMT；我们建立了一个林信任，为一个账户授予使用 ADMT 迁移用户的权限；我们配置了 ADMT 和 PES 工具，然后使用 ADMT 逐步完成迁移。

ADMT 工具为我们提供了一种迁移到托管的 Microsoft AD 服务的好方法，该工具允许对迁移进行强大的自定义，并通过加密密码同步以更安全的方式完成迁移。如果您环境的复杂性要求对其中某些步骤采取不同的方法，您可能需要进行额外的调查和规划。

如果您对这篇博客有疑问，请在 AWS Directory Service 论坛上发表新帖子，或联系 AWS Support。

亚马逊AWS官方博客