如何为 Dell Security Server 执行 Active Directory 域迁移

• Dell Security Management Server（以前称为 Dell Data Protection |Enterprise Edition）已安装并加入域。
• 现有域已添加到 WebUI 控制台下的“domain”部分。
• 端点已针对服务器激活。
• 需要迁移域。
• 我们也计划迁移 AD 对象的 SID 历史记录。
• 在启动域迁移之前，端点具有与服务器的完全连接并且可以检索旧域上的策略。
• 端点上的加密数据完全可访问，端点已激活，并且可以停用并重新激活它们。我们可以使用任何端点的快速 WSDeactivate 确认激活完成且没有任何问题。

整体步骤并不复杂，但您需要了解，如果整个过程未正确执行，数据可能会丢失或需要恢复计算机。最后，虽然此过程可以在任何版本的 Dell Security Management Server 和客户端上执行，但 Dell Technologies 建议至少安装 8.3.0 客户端和 8.5 服务器，因为在这些版本之后进行了多项改进，使得 Dell Security Management Server 端上的整体迁移过程更加轻松。下文概述了整个过程的工作原理以及最需要关注的一些问题。

第一步是了解是否需要进行域迁移。例如，如果公司要迁移到 Office 365，添加别名并将其设置为 AD 用户的主 UPN 就可以了。这不是真正的域迁移，除了将新别名添加到 Settings -> Domain Alias List 部分下的域别名列表，无需在 Dell Data Protection | Enterprise Edition Server 上执行任何其他操作。如果创建了新域，并且必须将 AD 对象从旧的已停用域迁移到新域，则必须计划域迁移。

计划域迁移时，第一步是考虑也迁移 SID 历史记录。要使 Dell Security Management Server 端上的域迁移成功，需要保留 SID 历史记录，否则 AD 对象会被视为 Dell Security Management Server 的新对象。然后，在重新激活后，我们将无法利用相同的加密密钥。戴尔要求迁移 SID 历史记录。我们不会花时间介绍如何执行域迁移，因为这不是 Dell Data Protection | Encryption 任务，但有几个工具（例如来自 Microsoft 的 ADMT）可以帮助组织将域 A 迁移到域 B。如上所述，我们需要进行 SID 历史记录迁移，才能持久保留密钥。迁移 SID 历史记录意味着我们将添加到旧用户 SID 预迁移的 AD 中的 SID 历史记录属性，从而保证迁移对象的连续性。

按照 AD 端的规则：

• 重命名任何对象时，objectSID 属性的值 (SID) 不会更改。当您将对象从一个域移到另一个域时，对象 SID 必须更改，因为它的一部分特定于域，并且旧 SID 会添加到 SIDHistory 属性（假设已迁移）。您可以使用 ADSI Edit 查看 SIDHistory （您可以在十六进制或十进制格式下进行查看）。如果没有值，则表示没有 SID 历史记录或对象从未从另一个域迁移。
• SIDhistory 仅在域或林之间迁移账户时可用。

下面是使用属性编辑器确定 SIDHistory 是否已迁移的屏幕截图：

确认迁移用户和计算机的 SIDHistory 也已迁移后，我们可以开始进行 Dell Security Management Server 配置。如果需要有关如何执行域迁移以及如何保留 SID 历史记录的更多信息，请参阅以下 Microsoft 文档：

• https://www.microsoft.com/en-us/download/details.aspx?id=19188
• https://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx
• https://technet.microsoft.com/en-us/library/cc974384(v=ws.10).aspx

以下是域迁移期间 Dell Security Management Server 端发生的情况。

1. 在客户端：
   • 我们将用户 UPN 解析为 SID。我们在存储区文件中查找他们的 SID。我们找不到它。
   • 我们判断这是新用户，然后联系安全服务器，将 UPN 密码作为典型的激活请求传递上去。
2. 在服务器端：
   • 我们收到激活请求。我们联系 Active Directory 并查找 UPN。然后我们对用户进行分类，在分类过程中，我们注意到实体表中的 SID 与 AD 中的 SID 不匹配。我们检查 SIDHistory 以查找我们的实体表中的 SID。如果找不到它，我们会抛出异常，由于已经有该 SCID，因此激活将会失败。如果找到了 SID，我们会使用新的 SID 更新实体表（在 UID 部分，第一部分是域，我们会更新它并更新端点域部分）。
   • 然后，我们将旧密钥、策略、DCID 等传递给客户端（就像是重新激活一样）。
3. 返回客户端：
   • 端点接收此信息，并在 credsys.vlt 文件中添加一个条目，其中显示用户已激活，并且该用户在该时间点正常登录。

Dell Security Management Server 端的一个关键点是了解是否必须在 WebUI 下添加新域，以便在激活或重新激活时让新用户和旧用户正常工作。

在域迁移中，如果旧域和新迁移域的根域父级存在，我们不会将新域添加到 Dell Security Management Server 控制台。在“Settings”“Domain Alias List”部分下以别名形式添加新域就足够了。（我们假定父域与新子域之间存在双向信任。）根域的服务帐户应该在父域中设置。另一种情况是，如果我们要将域 A.local 迁移到 B.local，并且这两个域不是同一根域的子域，或者它们属于另一个林，我们需要在控制台下添加一个新域，因为我们必须将任何现有端点绑定到新域和新服务账户。

了解关于正确配置 Dell Security Management Server 的上述内容是一个关键点，否则我们将在迁移后遇到几个问题。了解这些域与其根域（如果有）之间的信任类型以及它们当前在 Dell Security Management Server 控制台下的域列表也至关重要。规则很简单，如果父/子之间有某种信任，则在 Dell Data Protection | Enterprise Edition Server 下有根域和别名就可以了。否则，我们必须在 Dell Security Management Server 下添加与其真实子域一样多的子域，此规则也适用于域迁移。

最后，一般而言，我们*绝*不应同时添加子域和父域，因为这可能导致在两个级别都显示相同的用户，这会引发故障。在 Dell Security Management Server 端，删除域（还）不是完全受支持的任务。

如果客户端为 v8.2.1 或更早版本并且服务器为 v8.3.1 或更早版本，则 WSDeactivate 是必要步骤，因为我们没有在服务器端自动重命名端点域部分。对于 Dell Security Management Server 或端点的最新内部版本，这不是必要步骤。

无法手动或使用控制台从 Dell Security Management Server 数据库中删除旧域。这是因为 Dell Security Management Server 会查找用户或组，然后确定它的域成员身份。因此，删除域时，还应删除属于该域的所有对象。此阶段不支持这两个选项。戴尔正在研究在未来的 Dell Security Management Server 内部版本中更改此行为，但在此阶段，这不是一项受支持或可行的任务。另请注意，如果我们选择（手动）将域标记为已在数据库中删除，则对于所有关联的孤立用户和组，我们将每 15 分钟在服务器日志中收到一个抛出的错误。

如果在迁移的端点上卸载 Shield，则需要执行针对相同 Shield ID 的正常（非域）重新激活所需的相同步骤。在常见的加密文件中，我们必须在注册表中强制实施相同的 DCID，然后再让端点针对 Dell Data Protection | Enterprise Edition Server 或 Dell Security Management Server 重新激活。如有任何疑问，请联系技术支持团队以获得更多帮助。

否，从 Dell Data Protection | Enterprise Edition Server 8.x 开始，不需要新的域许可证。在较旧版本的 Dell Data Protection | Enterprise Edition Server 上，仍然需要新的许可证。有关详细信息，请联系技术支持团队。