Active Directory 迁移 – 安全迁移的 5 种方法

“别担心，”你的经理说。 “请充分利用 Active Directory 迁移所需的时间。 ”

你停下来想知道他们是否感觉还好。

之前进行任何其他 Active Directory 迁移时，您从未获得过足够多的时间。为什么这个会有所不同？你有一长串你一直想以正确的方式做但从来没有时间正确做的事情。

但是，如果您的老板对您很坦诚，那么您就有机会几乎从头开始并认真对待 Active Directory 安全性。对于任何 IT 管理员来说，这都是一个诱人的前景。您开始在心里记下您希望新的 Active Directory 如何比现在的 Active Directory 更安全。

不过，您还是想向老板澄清一件小事：

“我可以写下来吗？ ”

Active Directory 迁移的 5 个级别

不，你不能把它写成书面形式，不，你的老板并没有真正说你可以花所有你需要的时间。但是，如果您确实有足够的时间来执行迁移呢？你会做哪些你通常没有时间做的事情？

Joe Sharmer 和我在今年的专家会议上发表了主题为“Active Directory 迁移期间的安全注意事项”的演讲。 ” 我们在五个不同级别上检查了 Active Directory 迁移安全性：

1) 身份
2) 团体
3) 应用
4) 数据
5) 设备

我们设身处地为您着想，向您解释为什么 Active Directory 迁移是改善安全状况的最佳时机。在这篇文章中，我将详细介绍这些原因，以及您可以在下次迁移时列入清单的具体提示。

首先，为什么要迁移？

大多数迁移分为三类：

并购。你的公司收购了另一家公司，所以速度是悬而未决的。管理层希望您尽快将两个不同的组织合并在一起。 “计算机完成了所有工作，”他们说。 “IT 部分需要多长时间？ ”

安全性。您、您的新老板或新 CIO 进来并追溯现有目录的历史记录到 Windows NT 4.0。 Active Directory 迁移是刷新 AD 安全状况并防止旧工件使其易受攻击的好机会。

简单。一些组织决定他们宁愿管理一个林或一个域，也不愿管理多个林或域。他们以现代化的名义迁移。

无论迁移的原因是什么，您都可以确定攻击不会消失，因此请重点关注五个级别的 Active Directory 安全性。

1. 身份——用户可以做什么？用户可以访问什么？

身份是身份验证的核心，然后是授权。身份与 NTFS 权限、SharePoint、SQL Server 以及对 Active Directory 域中所有资源的访问权限相关联。

清洁来源原则要求所有安全依赖项（例如身份）应该与您要保护的任何对象（服务器、域、设备）一样值得信赖。在 Active Directory 迁移中，您必须首先考虑谁有权访问该对象。这是因为，如果这些权限集在 Active Directory 迁移期间移动到目标，那么访问权限也会随之迁移。

提示：如果您要进行迁移以改善安全状况，请考虑将 Active Directory 迁移到全新状态。这样，您就不会将旧的或未知的依赖项带到新的 AD 中。
密码是身份的重要组成部分，在迁移之前了解谁可以在源环境中访问密码非常重要。如图 1 所示，Active Directory 域级别的权限集包括复制全部目录更改 — 位于此处的三个条目中。

图 1：Active Directory 域级别的权限设置

复制目录更改全部权限是获取密码哈希所需的权限。拥有该权限的人都可以使用它来获取 krbtgt 哈希值，这是尝试创建黄金票证时最难获取的信息。您可能拥有创建该权限的旧 Blackberry 帐户或自助密码管理器实用程序。

提示：找出源环境中谁有权获取密码哈希值。具有该权限的用户和对象可能有足够的信息来创建黄金票证，您不希望在不知不觉中将其迁移到新环境。

您最近多久更改过 krbtgt 密码？如果您检查其属性，您会看到类似于图 2 中的 pwdLastSet 属性的内容吗？

图 2：krbtgt 属性

更改 krbtgt 密码是阻止源环境中可能存在的黄金票据的好方法。

提示：计划每年至少更改两次 krbtgt 密码。您可以使用 Microsoft 的脚本来自动执行该过程，并且在迁移之前运行它是一个好主意。但请注意不要连续快速更改两次，因为这将使环境中存在的所有 Kerberos 票证失效。仅当您受到威胁并且需要重新控制环境时，您才应该在短时间内更改两次。

Active Directory 迁移是重新审视系统帐户和用户帐户密码策略的最佳时机。您需要多少个字符？允许使用特殊字符吗？用户必须多久更改一次密码？密码必须有多强？

提示：要求您的用户在迁移之前更改密码。与盲目迁移可能泄露的密码所带来的安全漏洞相比，这只是一个小小的不便。

2. 群组——删除过时的群组

团体有利于安全，但事实并非如此。创建组很方便，这样您就可以在一个地方管理权限。但是跟踪它的生命周期怎么样？当它像千年虫组织一样达到其目的时，就将其消灭。

假设您的用户创建通讯组列表，而 Microsoft Exchange 在 Active Directory 中创建动态通讯组以加快电子邮件和其他信息的批量发送。如果您从未检查和删除过时的组，那么 Active Directory 迁移是关注此问题的理想机会 - 前提是您有时间和工具。

提示：使用 dsquery 帮助您识别过时的组并确保您不会迁移它们。 Dsquery 要求安装 Active Directory 域服务 (AD DS) 服务器角色，并且您必须从提升的命令提示符运行它。如图 3 所示，命令 dsquery * -filter “(objectCategory=group)” -attr cn whenChanged whenCreated 生成更改日期和创建日期的列表。

图 3：组上的 dsquery

考虑源环境中与目标环境中的组同名的组，例如工程组或设施组。您如何知道他们具有相同类型的成员和权限？

这是一个例子。想象一下源环境中的一个文件服务器，其中包含一个包含每个人工资信息的目录。该文件夹受人力资源组保护，该组有三名成员，所有成员都需要访问该信息。现在，由于合并，您迁移到一个也有人力资源团队的新环境。但他们以不同的方式使用该组：除了人力资源用户之外，其成员还包括财务和 IT 人员。如果将用户从源组迁移到目标组，人们将意外地能够查看他们以前看不到的文件。

提示：在合并重复组之前先研究它们。您可能会无意中扩大权限范围并授予对信息的意外访问权限。

3. 应用程序 — 身份验证和 GPO

您的哪些应用程序将受到 Active Directory 迁移的影响？大多数情况下，答案与您的应用程序所需的身份验证有关。

PetitPotam NTLM 中继攻击发生后，身份验证成为首要考虑因素。许多公司仍然使用 NTLM (NT LAN Manager) 版本 1 进行身份验证，但如果您出于安全原因进行迁移，您可能不希望在目标环境中使用该版本。

在针对 PetitPotam 的其他缓解措施中，微软建议您“在 Windows 域控制器上禁用 NTLM 身份验证”，但如果您的应用程序依赖于此，这将无济于事。

提示：当您将对象迁移到新环境时，请尝试启用 NTLM 版本 2 并禁用 NTLM 版本 1。或者，要确保 Kerberos 是唯一允许的身份验证协议，请禁用 NTLM 并仅允许 Kerberos 。然后查看您的应用程序是否损坏。

碰巧 Active Directory 迁移也是重新审视身份验证方法的好时机 — 也许您可以禁用 NTLM 并使用 Kerberos。测试这一点的一个好方法是通过受保护的用户帐户（参见图 4）。

图 4：受保护的用户帐户

提示：将受保护用户组配置为使用 NTLM 身份验证并强制成员使用 Kerberos。然后，在验收测试期间将每个部门的一名成员放入组中。如果这些成员仍然可以使用 Kerberos 访问应用程序，那么您可以为他们禁用 NTLM。 （请注意，当用户成为受保护用户组的成员时，会有四个小时的身份验证延迟。）

如果您长期依赖组策略对象 (GPO)，则无法知道它们处于什么状态。盲目地将它们迁移到新的 AD 是另一种给原始的 AD 带来过时风险和潜在漏洞的方法环境。您可能有很多 GPO 需要检查，但现在修剪掉无用的内容比未经检查就进行迁移要好。

4. 数据——谁拥有许可？

您的目录充满了数据，每当您有数据时，您就会考虑权限。请记住，在大多数数据泄露的情况下，攻击者通过已有的帐户获得对对象的访问权限。

图 5 显示了应收帐款目录的权限。

图 5：应收帐款目录对象

财务数据和应收帐款组有权访问此目录中的数据是有道理的，但为什么是两个人呢？就此而言，如图 6 所示，Sam Smith 属于应收帐款组，因此他不需要对该目录的显式权限。

图 6：应收帐款组属性

提示：消除对包含敏感数据的数据集和目录的个人访问。这样，当稍后删除这些个人时，您的 Active Directory 中将不会有未解析的 SID（安全标识符）。仅允许组拥有数据访问权限。

提示：审核哪些用户有权访问数据以及他们使用数据的频率。随着时间的推移检查使用情况，您可以通过组来管理访问。让企业主定期证明每个用户需要持续访问。

5. 设备 — 迁移前加固

您使用哪些工具进行 Active Directory 迁移？他们是否要求您在迁移期间暂时禁用防火墙（参见图 7）或启用远程注册表（参见图 8）？

图 7：Windows Defender 防火墙设置

图 8：远程注册表属性

较旧的工具具有远程连接的先决条件。但是，如果您出于安全原因进行迁移，您是否真的想削弱您的安全态势（即使是暂时的），以便可以迁移到新环境？

提示：使用 Active Directory 迁移工具不会强制您在迁移项目期间禁用源服务器或目标服务器上的安全属性。没有必要为了迁移到更安全的环境而削弱服务器和配置。

结论

关键是，匆忙进行 Active Directory 迁移并不是一个好主意。

在 Active Directory 迁移或整合项目期间，许多机会都会打开。如果攻击者知道您正在迁移——或者即使他们只是运气好——从长远来看，您的公司也会遭受损失，因为您将整合已经受损的系统。

您的老板可能不会让您花费所有需要的时间来确保安全迁移。但迁移速度越快，某种漏洞未被发现的风险就越大。如果您想降低目标 AD 中的该风险，请在迁移之前在源 AD 中消除该风险。