导读：让AD更安全！是的，每个管理员都希望如此，但是要尽可能高地实现这个目标，您还是需要花上一点力气的，本文通过5个步骤，帮您理解如何来切实增强AD基础设施的安全。
活动目录（AD）中保存着能够对AD进行访问的重要密钥，如果不能恰当地增强AD的安全性，那么它很容易受到攻击。坦率地讲，增强AD的安全性并不简单，但是通过一些基本的步骤，您确实可以提高它的安全性。请注意我这里所说的是“基本”步骤。安全无止境，您总是可以找到提高安全性的方法，但是这些方法往往需要付出相应的代价。这些代价可表现为实际的花费，或者灵活性或功能性方面的损失。让我在这里向您展示5个步骤，实施这些步骤的代价并不算高，但它们却可以帮助您切实增强AD基础设施的安全性。
步骤1. 遵循管理员方面的最佳做法
您可以通过将手工操作（例如，安装域控制器）自动化的方法来增强AD的安全性，但是目前还没有出现能够将人类行为自动化的程序设计语言。因此，这就是您需要为管理员如何管理AD建立指南的原因。您需要确信您的管理员遵循了如下的最佳做法：
区分管理账号（administrative accounts）的使用。区分管理账号的使用已经成为许多组织的一个标准做法，但它仍然值得一提。如果管理员的机器不小心感染了病毒，那么潜在的威胁将会非常大，因为获得管理权限（right）后，病毒可运行程序或脚本。因此，对于日常操作，管理员应使用非特权账号（例如，用户账号）；对于和AD有关的操作，管理员应使用一个独立的管理账号。当您通过一个非管理账号登录后，您可以使用Runas命令这类工具以管理员的身份打开程序。如需了解有关如何使用Runas命令的信息，请参阅Windows的帮助文件。
确保管理员机器的安全性。虽然要求您的管理员以非管理账号登录和使用Runas命令打开AD管理程序能够带来很多益处，但是如果运行这些工具的硬件系统不安全的话，您仍然处于危险之中。如果您不能确保管理员机器的安全性，那么您需要建立一个独立并且安全的管理员机器，并让管理员使用终端服务来访问它。为了确保该机器的安全，您可以将它放在一个特定的组织单元中，并在组织单元上使用严格的组策略设置。您还需要注意机器的物理安全性。如果管理员的机器被盗，那么机器上的所有东西都将受到威胁。
定期检查管理组（administrative group）的成员。攻击者获得更高特权（privilege）的手段之一就是将它们的账号添加到AD的管理组当中，例如Domain Admins、Administrators或Enterprise Admins。因此，您需要密切关注AD管理组中的成员。遗憾的是AD不具备当某个组的成员发生改变时发送提示信息的内建机制，但是编写一个遍历组成员的脚本并使脚本每天至少运行一次并不复杂。在这些组上面启用审核（Enabling Auditing）也是一个很好的主意，因为每次改变都会在事件日志中有一条对应的记录。
限制可以访问管理员账号（Administrator account）密码的人员。如果某个攻击者获得了管理员账号的密码，他将获得森林中的巨大特权，并且很难对他的操作进行跟踪。因此，您通常不应使用管理员账号来执行管理AD的任务。相反，您应该创建可替代的管理账号（alternative administrative accounts），将这些账号添加到Domain Admins或Enterprise Admins组中，然后再使用这些账号来分别执行每个管理功能。管理员账号仅应作为最后一个可选择的手段。因为它的使用应该受到严格的限制，同时知道管理员密码的用户数量也应受到限制。另外，由于任何管理员均可修改管理员账号的密码，您或许还需要对该账号的所有登录请求进行监视。
准备一个快速修改管理员账号密码的方法。即使当您限制了可以访问管理员账号的人数，您仍然需要准备一个快速修改该账号密码的方法。每月对密码进行一次修改是一个很好的方法，但是如果某个知道密码（或具有修改密码权限）的管理员离开了组织，您需要迅速对密码进行修改。该指南同样适用于当您在升级域控制器时设置的目录服务恢复模式（Directory Service Restore Mode，以下简称DSRM）密码和任何具有管理权力的服务账号。DSRM密码是以恢复模式启动时用来进行登录的密码。您可以使用Windows Server 2003中的Ntdsutil命令行工具来修改这个密码。
当修改密码时，您应该使用尽量长的（超过20个字符）随机密码。对于管理员而言这种密码很难记忆。设置完密码后，您可将它交给某个管理人员，并由他来决定谁可以使用该密码。
准备一个快速禁用管理员账号的方法。对于绝大多数使用AD的组织，最大的安全威胁来自于管理员，尤其是那些对雇主怀恨在心的前管理员。即使您和那些自愿或不自愿离开公司的管理员是好朋友，您仍然需要迅速禁用账号上的管理访问权限。
步骤2. 遵循域控制器方面的最佳做法
在确信遵循了与管理员有关的最佳做法后，我们将注意力转移到域控制器（Domain Controller，以下简称DC）上面来，因为它们是许多AD实现中最容易受到攻击的目标。如果某个攻击者成功进入DC，那么整个森林将受到威胁。因此，您需要遵循如下最佳做法：
确保DC的物理安全性。DC的物理安全性是部署AD时需要考虑的最重要问题之一。如果某个攻击者获得了DC的物理访问权，他将有可能对几乎所有其它的安全措施进行破坏。当您将DC放置在数据中心时，DC的安全性并不存在问题；当在分支机构部署DC时，DC的物理安全性很可能存在问题。在分支机构中，DC经常存放在可以被非IT人员访问的带锁房间内。在一些情况下，这种方式不可避免，但是不管情况如何，只有被充分信任的人员才能够对DC进行访问。
自动化安装的过程。通常自动化任务的执行要比手工执行的安全性高。当安装或升级DC时尤其如此。安装和配置操作系统过程的自动化程度越高，DC的不确定因素就越少。当手工安装服务器时，对每台服务器人们的操作均存在细微的差别。即使完整地记录下所有过程，每台服务器的配置仍然会有所区别。通过安装和配置过程的自动化，您有理由确信所有DC均以同样的方式被配置并设置安全性。对于已经安装好的DC，您可以使用组策略这类工具来确保它们之间配置的一致性。
迅速安装重要的更新。在Windows NT时代，除非绝对需要，绝大多数管理员不会安装热修复程序（hotfix）或安全更新。更新经常存在缺陷并会导致进一步的问题。今天，我们就没有那么奢侈了。幸运的是微软提供的更新程序质量有了很大提高。因为DC是非常显眼的目标，所以您需要密切关注出现的每一个安全更新。您可以通过访问地址http://www.microsoft.com/security/bulletins/alerts.mspx来订阅并收到有关最新安全更新的Email通知。您可以通过自动更新（Automatic Updates）迅速地对安全更新进行安装，或者通过微软的Software Update Services（SUS）在测试后有选择地对其进行安装。
创建一个保留文件。在Windows Server 2003以前的操作系统中，如果用户具备在某个容器中创建对象的权限，那么将无法限制用户创建对象的数量。缺乏限制可以导致攻击者不断地创建对象以至耗尽DC硬盘空间。您可以通过在每个DC的硬盘上创建一个10M至20M的保留文件，以便在某种程度上降低这类风险的发生。如果DC的空间用完了，您可以删除上述保留文件，并在找到解决方案前留下一些解决问题的空间。
运行病毒扫描软件。在DC上运行病毒扫描软件比在大多数服务器上运行该软件更为迫切，因为DC间不仅要复制目录信息，还要通过文件复制服务（File Replication Service，以下简称FRS）复制文件内容。不幸的是FRS为病毒提供了在一组服务器之间进行传播的简单途径。并且FRS通常还会对登录脚本进行复制，因此还会潜在地威胁到客户端的安全。运行病毒扫描软件可以大幅降低病毒复制到服务器和客户端的威胁。
步骤3. 遵循委派方面的最佳做法
错误地对保护AD内容的访问控制列表（ACL）进行配置将会使AD易于受到攻击。此外，如果委派实施得越复杂，那么AD的维护和问题解决工作就越难。因此我喜欢应用简洁的设计哲学。委派实施得越简单，您的麻烦就会越少，在安全方面尤为如此。事实上，上述哲学同样适用于AD的设计，在附文“设计决定安全”中将进行详细讨论。为了保持委派的简洁，我强烈建议您阅读“Best Practices for Delegating Active Directory Administration”一文（http://tinyurl.com/vzlg）。
不要将权限分配给用户账号。进行委派的基本原则之一就是除非有充分的理由，否则始终将权限分配给组而不是用户。当某个被您分配权限的用户离开公司或工作职能发生改变而再不需要某些访问权限时，您需要执行哪些操作？找到某个账号被赋予的权限，取消这些权限，然后再将它们赋予另外一个用户，要比将旧账号从某个组中删掉，再将一个新账号加入到该组中的工作量大得多。即使您认为赋予特定用户的权限永远不会被赋予其他用户，我还是建议您创建一个组，将用户加入到这个组中，然后再将权限分配给这个组。
不要将权限分配给单独的对象。当您直接将权限分配给单独的对象时（例如一个用户或一个组对象），事情将会变得复杂起来。上述权限需要更多的维护，并且很容易在随后被忽视。为了避免问题的发生，您应该将权限尽量多地分配给组织单元或容器。
记录下使用的模型。在进行权限委派时，您需要完成的重要工作之一就是记录下使用的模型。您是否建立了一个基于角色的模型？请求访问权限的过程是什么？模型是否具有特例？所有这些重要问题都应该被记录，它不仅会使维护工作变得简单，而且将确保每个人都清楚权限应该如何被分配，并可以识别出没有按照模型进行分配的权限（它将使AD易于受到攻击）。记录模型的文档格式并不重要，但应能够方便管理员查找。
熟悉Dsrevoke的使用。您可通过Active Directory用户和计算机程序来运行控制委派向导（Delegation of Control wizard），它能够很好地完成初始的访问委派工作。但是使用这个向导或其他图形工具来完成委派取消工作（例如从ACL中删除分配给某个账号的所有权限）却非常麻烦。幸运的是微软发布了Dsrevoke工具，它允许您遍历域中的所有ACL，并能够删除掉您指定账号的所有访问权限。您应该熟悉这个工具，因为它能够提高委派的效率。您可以通过网址http://www.microsoft.com/downloads/details.aspx?familyid=77744807-c403-4bda-b0e4-c2093b8d6383&displaylang=en免费地下载该工具。
步骤4. 监视并审核您的AD
因为AD包含许多组件，所以确定何时有人对系统进行破坏比较困难。目前您仅能够遵循上述提到的最佳做法，但是您如何知道有人正在偷偷溜进您的系统呢？答案是监视和审核。
您至少需要监视DC的可用性（availability）。您也许已经在进行主机可用性的监视了，并用它来确保AD基础设施的可用性。但是从安全的角度而言，知道DC何时非正常停机更为重要，这样您就可以立即对原因进行相应的分析。也许远程站点的一台DC被盗或某个黑客取得了物理访问权并且正在关闭机器以便安装一个木马程序！
除了监视DC的可用性，您还可以使用性能监视器对许多AD的度量（measure）进行监视，这些度量包括轻量目录访问协议（Lightweight Directory Access Protocol，以下简称LDAP）查询的次数和复制数据的数量等内容。您可以为每个感兴趣的计数器设定一个阀值，然后对它们进行监视。如果您注意到，例如每秒钟LDAP查询请求次数或身份验证请求次数在一段时间内明显上升，这也许就是某种攻击的一个提示信息。为了获取更广泛的监视（甚至是警告）信息，您可以使用Microsoft Operation Manager这类工具。
Windows操作系统和AD提供的审核功能允许您将某些事件记录到安全事件日志中。您可以记录从操作系统配置更新到AD内部修改等任何事件。但是在启用审核时您需要谨慎考虑。如果审核的对象过多，那么安全日志中将会充斥过多的信息以至于很难找到您所需要的内容。为了获取审核对象方面的指导，请参阅“Best Practice Guide for Securing Active Directory Installations”一文（http://tinyurl.com/3c928）。
步骤5. 做最坏打算
也许安全规划最重要的方面就是建立一个如何应对成功攻击的预案。实施上述最佳做法并不能绝对确保安全。您也许已经建立起一个非常安全的AD基础设施，但是如果攻击者进行一次从未见过的AD攻击，您也许就会束手无策，因为您对它还不了解。这就是为什么做最坏打算显得如此重要的原因。如果您发现正处在这种情形下，您已经知道该如何应对了。如果您发现整个森林均受到威胁并且需要进行一次彻底的恢复，您将会因为事先考虑过这个过程而节省下宝贵的时间。
执行最佳做法
在本文中我们讨论了提高AD安全性的一些基本步骤，而且实施这些步骤的代价也很低。虽然讨论的内容仅仅涉及一些皮毛，但是如果您遵循上述步骤，您的AD将会变得更加安全。 项目概览
问题：增强AD的安全性并不容易，但是通过执行一些基本的步骤，您确实可以提高它的安全性。 您需要：Ntdsutil, Dsrevoke 难度系数：3/5
项目步骤：
遵循管理员方面的最佳做法
遵循域控制器方面的最佳做法
遵循委派方面的最佳做法
监视并审核您的AD
做最坏打算
设计决定安全
病毒、蠕虫、垃圾邮件以及拒绝服务攻击是互联网用户每天都需要面对的安全威胁。互联网之所以很容易受到攻击，是因为当初设计它的时候并没有考虑到安全性。它被设计成了一个开放的系统，并鼓励用户自由地交流和交换思想。互联网的建立者从未想到某一天它会取得商业上的巨大成功。从此互联网社群一直在设法增强一个不安全设计的安全性。
上述例子说明了某项技术的实现将最终决定如何来增强它的安全性，AD也不例外。如果您设计了一个开放的委派模型并将用户不需要的访问权限也分配给他们，或者您将域控制器部署到不安全的位置，那么您将需要花费很多时间用来增强整个实现的安全性。
我喜欢应用简洁的设计哲学。AD设计得越简单，您的麻烦就会越少，在安全性方面尤为如此。复杂的设计往往导致更多需要管理的内容，接下来就是对更多的内容进行安全方面的增强。我喜欢应用的一个基本原则就是“越少越好”。域越少，域控制器就越少。域控制器越少，管理员就越少。组织单元越少，需要委派的对象就越少。
关于作者
Robbie Allen，Cisco Systems公司IT部门的系统架构师和程序工程师，《Managing Enterprise Active Directory Services》（Addison-Wesley）一书的作者之一。您可以通过
[email protected]和他联系。