您是否因为 Active Directory 的问题而彻夜不眠？对此大家都非常能够理解。Active Directory 大概是您企业中规模最大、最重要的分布式系统了。与

灾难恢复一起，Active Directory^® 安全被称为是让管理员寝食难安的头号难题。

但是目前仍然有许多方法可以提高 Active Directory 的安全，您可能已经采取了一些措施。下面列出了一些提示，利用这些提示有助于确保您的 Active Directory 安装更加安全。首先我想谈一下管理安全，然后谈谈密码和组安全，最后是有关域控制器安全方面的一些提示。

首先您要做的是对 Active Directory 的配置信息进行文档记录。这项工作的趣味性并不强，但是如果您对自己的目前情况不了解，就可能会感到茫然。最好从高级结构开始这项工作，例如林配置和域配置、组织单位 (OU) 结构、顶级目录安全和现有信任关系。记录站点拓扑的方式是列出各个站点、每个站点的配置设置、站点链接及其设置、子网列表及其设置，以及所有手动创建的连接对象及其设置。记录组策略对象 (GPO) 需要使用组策略工具，例如组策略管理控制台 (GPMC)，您可以从 Microsoft 下载该工具，它还包含在 Windows Server™ 2003 R2 中。您所创建的文档应该包含密码和审核策略，同时不要忘记将 GPO 链接的内容以及谁对这些内容享有权限都记录在文档中。确保列出您对 Active Directory 架构做出的全部更改，最好使用轻量目录交换格式 (LDIF) 文件进行记录。您还可以在下载中找到一个 GPMC 脚本，它能够帮助您着手实施。该脚本位于 %programfiles%\gpmc\scripts 目录下，名为 GetReportsForAllGPOs.wsf。

在进行操作时，请同时列出您的域控制器及其名称、操作系统版本、病毒扫描软件及其版本。记录您使用的备份方法、备份频率和备份文件的保存时间。如果使用的是基于磁盘的备份，请记下您保存备份文件的安全位置。如果使用的是 Windows^® DNS，请使用 DNSCMD 和 DNSLINT 记录其配置。请注意您的备份方法是否与 Active Directory 集成，是否使用应用程序分区以及这些分区是如何配置。

要保证 Active Directory 的安全，首先要从最上层的管理模型着手。要保护林的安全，最重要的、也可能是最困难的一步是对您的管理进行控制。每个人都希望拥有对 Active Directory 的权限，但是要保证林模型的充分安全是不允许这样做的。如果您的公司采取与大多数公司一样的安装过程，并且已经设置了逻辑 Active Directory 设计，则须在其约束下工作。否则，那么您有机会从头构建 Active Directory。

在 Active Directory 中，林是唯一真正安全的边界。域应该用于改善您公司的 IT 支持基础结构并加快复制过程，而 OU 则用于在域中进行管理功能的委托。如果您公司的两个部门之间存在严格的安全约束，请考虑另外部署一个林。有关建议，请参阅“在 Windows 2000 和 Windows Server 2003 中实现多个林的注意事项”。必要时，请添加一个经过安全过滤的林信任，以便能与您的第一个林进行通信（有关详细信息，请参阅“在 Windows Server 2003 中设计并部署联合林”）。如果您使用不同的组对域进行管理，请注意，对林中任何域控制器的管理访问都会危及整个林的安全。因此，您需要与其他域的管理团队密切合作，才能保证在整个林中建立一个统一域控制器 (DC) 管理模型。有关该主题的详细信息，请参阅“在 Active Directory 中设计管理委托时的注意事项”。

您需要尽可能地限制林中管理员的数量。虽然 Active Directory 安全模型的功能比 Windows NT^® 4.0 中的强大得多，但是它仍存在不足之处：在没有获得域管理员身份之前，您无法完全对域控制器进行管理。也就是说，在一个基本的 Active Directory 实施中，包含 DC 的区域内的计算机操作员通常是域管理员组的成员，因此他们可以对这些服务器执行全部的安全维护功能。千万不要这样做！因为这样做相当于把 Active Directory 林的安全钥匙交给了一大批背景不明、不知是否获得安全认证的员工。相反，您应该按照经过实践验证的步骤进行操作，首先确定员工的工作要求，然后根据这些要求创建一个解决方案。按照操作管理的要求，明确员工需要在 DC 上执行哪些任务。然后综合运用组策略和第三方工具设计出一套解决方案，在不授予域管理员权限的前提下，让员工享有尽可能多的权限。

最后，您的管理员团队必须承担那些出于安全原因无法委托员工进行操作的任务。但是这处理起来也非常棘手，因为您免除了操作员的责任，自己要承担信息安全的责任。

借此机会，我想详细谈谈组策略的问题。组策略是您控制林安全所使用的最强大的工具。但是，正是由于组策略的功能如此强大，因此在实施这些策略之前，您需要在一个受控的环境中对它们进行测试。您可以使用复用测试环境，物理的或虚拟的（使用诸如 Virtual Server 2006 的虚拟软件）均可。您可以在各个阶段实施这些策略，方法是先将新建的侧重安全性的 GPO 与单个 OU 相连，然后再与整个域连接。

在对管理员数量进行限制以后，如果您需要提升员工权限才能完成某些操作，请确保这些员工使用单独的管理帐户。这些帐户的命名约定应该与标准帐户有所不同，并且应该位于自己的 OU 中，这样您才能够对它们应用唯一的 GPO。您可以按照帐户的角色对其进行分组，然后将权限分配给这些帐户组，而非单个帐户。例如，负责帐户管理的支持人员应该在名为“<域名> 帐户管理”的组内拥有自己的管理帐户，并且该组应加入到“帐户操作员”内置组。

如果您能按照我刚才提出的建议设计您的安全模型，就可以相对容易地将所有提升的内置组放入组策略的限制组功能中。该功能可确保限制组的成员每隔五分钟受到一次限制，降低了恶意管理员向该组添加帐户的几率。使用限制组能够保持“架构管理员”组中成员数为零，而“企业管理员”中只有少量成员。

服务管理员（负责运行核心 Active Directory 服务，例如 DC、站点和架构）不应使用他们的桌面机，而应借助专用的远程服务器管理点 (TSAP) 来执行所有的任务。这种更加安全的做法最大程度地降低了桌面机恶意软件的传播，能够更轻松地使用单独的管理帐户进行工作，并且提供了一个锁定的自定义管理点。将这些 TSAP 保留在它们各自的 OU 中，并使用 GPO 阻止 Internet 访问，将本地登录权限仅授予管理帐户，增加审核过程并部署一个受密码保护的屏幕保护程序。将您的 TSAP 升级到 Windows Server 2003，可使其 Active Directory 管理工具对其本身与您的 Windows Server 2003 DC 之间的轻型目录访问协议 (LDAP) 传输进行签名和加密。

保证帐户安全的基本措施是禁用来宾帐户并重命名管理员帐户。也许您已经这样做了。但是不管您采取哪种措施，切记要将这些帐户的默认说明一起删除，因为恶意破坏者能够轻易找到这些说明。大多数程序性攻击利用管理员帐户众所周知的安全标识符 (SID)，而非帐户名称，因此对管理员帐户进行重命名起到的作用比较有限。但是它确实显示您正在使用审慎调查进行安全审核。您也可以使用重命名策略来创建一个 Honeypot 管理员帐户。这是一种名为“管理员”的帐户（在您对真正的帐户进行重命名以后），它启用了一种高级审核功能。如果有人试图通过猜测密码来登录该帐户，登录企图将被记录下来。如果您有事件日志监控工具，还可以触发警报。

您应该严格控制能够访问真正的管理员帐户和获得密码的人数。为了获得最高级别的安全，请考虑 nuclear 密码选项：两个（或两个以上）管理员相互产生两个（或两个以上）八位随机强密码，然后每个管理员分别将密码输入密码字段。（有关功能强大的密码生成器的信息，请参阅 www.winguides.com/security/password.php。）现在，帐户获得了一个长度为 16 位或更长的密码，至少需要两个管理员一起登录，缺一不可。

一个经常被忽视但十分重要的密码是域控制器上的目录服务还原模式 (DSRM) 密码。每个 DC 具有唯一的 DSRM 密码，该密码用于登录一个通过重启进入 DSRM 模式的 DC，以便能够以脱机方式获取 Active Directory 副本。您需要经常对 DSRM 密码进行更新，因为本地操作员可以使用该密码从服务器上复制 NTDS.DIT（Active Directory 数据库）并重新启动服务器，而不被人发现。在 Windows 2000 的早期版本中，更改密码的唯一方法是登录系统后手动更改密码，而当您拥有两个以上的 DC 时，这样做是行不通的。Windows 2000 Service Pack 2 引入了 SETPWD 命令（请参阅知识库文章“配置服务器向导设置空恢复模式密码”）来远程更新 DSRM 密码。Windows 2003 中的 NTDSUTIL 命令能够对密码进行远程更改（请参阅“如何在 Windows Server 2003 中重置目录服务还原模式的管理员帐户密码”）。您应该创建一个脚本对 DC 执行此项操作，并且定期执行此操作。

到目前为止，大家都知道强密码的好处，但是请不要对用户自愿使用这种密码抱有过高期望。为了帮助他们使用强密码，您切实有必要在域内强制实施强密码规则（请参阅“在 Windows 2000 中启用强密码功能”）。您可以向用户建议一些有帮助的策略，例如使用密码，而不是混用字母/数字/字符组合。

众多周知，服务帐户是另一个令人棘手的问题。服务帐户用于在应用程序服务器上提供应用程序服务，它的特点是使影响较小的密码改动变得非常困难，因此该密码通常被设置为永不过期。因为服务帐户控制着一项重要的服务（许多服务器上经常会使用），您肯定不希望该帐户的密码被泄漏。

虽然解决密码更改问题较为困难，但是您可以采取一些措施来减轻遭受攻击的风险或突如其来的变化。您应该为这些帐户设定一个命名约定，以便将其识别为服务帐户并建议它们的用途。将所有这些帐户分入一个名如“服务帐户”的组中，并对您的应用程序服务器应用一个策略来拒绝“本地登录”策略，但允许“作为服务登录”。把这些帐户保存在各自的 OU 中，从而能够按照它们的独特要求应用 GPO。

域控制器构成了 Active Directory 的物理方面。分布在您企业各个角落的每个 DC 都包含一份属于自己的 Active Directory 数据库副本 NTDS.DIT。这意味着在考虑安全性时，尤其需要对每个 DC 的物理安全性给予高度重视。如果这些 DC 中的任何一个不翼而飞，窃贼就能够对目录信息树 (DIT) 进行物理访问，并对这些信息树运行破解程序来获取用户命和密码。因此，您必须准备一套应急措施，一旦 DC 被盗，可以立即对域内所有的密码进行更改。

即将推出的 Windows Server 新版本（代号为“Longhorn”）中提议了一项功能，该功能借助一种 DIT 中不包含用户密码的只读域控制器 (RODC)，旨在极大地降低这种情况带来的风险。用户通过从完整 DC 中引用一个 Kerberos 来登录，您可以对 RODC 进行配置，使其缓存用于身份验证的用户密码。对于分支机构来说，RODC 只缓存属于分支机构用户的密码，因此如果密码泄漏，只需立即对这些用户的密码进行更改即可。RODC 能够灵活地对配置进行缓存，它甚至还能提供一种方法来判断哪些人的密码被缓存。但是如同所有对预发布软件的讨论一样，这一功能可能随时发生变化。

Windows Server 2003 SP1 安全配置向导能够引导您通过逐步操作锁定 DC，从而增强对 DC 的安全保护。

您需要提防一种拒绝服务的攻击，它会填满 DC 上所有可用的磁盘空间。该攻击的执行途径有两种。第一种是尝试造成 Active Directory 大量溢出对象。因为 Active Directory 具有很强的扩展性，所以这种方法不可能使 Active Directory 崩溃。但 Active Directory 大量溢出对象会导致数据库膨胀，并最终填满磁盘分区。除了要保证 DIT 所在分区具有大量空闲空间以外，请考虑通过 DSMOD PARTITION 或 DSMOD QUOTA 实施目录配额。这样做能够防止任何一个安全主体向目录添加过多的对象。

另外一种拒绝服务攻击能够造成 SYSVOL 文件夹大量溢出文件，导致启动分区被填满，最终导致 DC 崩溃。在这种情况下您不能使用配额系统，但却可以创建一个或多个简单的保留文件来占用当前空闲的磁盘空间。当您遭遇此类磁盘被填满的情况时，只需逐一擦除这些保留文件，就可以在查明根本原因之前保持一定大小的空闲磁盘空间。您可以使用 FSUTIL FILE CREATENEW 命令轻松地创建保留文件。

由于 Active Directory 依赖于 Kerberos，因此它对 DC 之间的时间变化非常敏感。尤其对于林之间的信任关系更是如此。因为这些林所依赖的时间结构可能各自不同。默认情况下，林中其他所有 DC 要获得正确时间，都需要以根域内的 PDC 操作主机为参照。那么该 DC 获取正确时间的时间源又是什么？该时间源是否安全？

您必须在域级 GPO 中启用审核功能并禁止改写，从而确保域中的每个系统都能够时刻保持对重要事件的跟踪。您需要对失败的登录、成功和失败的帐户管理、对象访问以及策略变更进行审核。因为审核事件越来越多，所以您需要使用相同的 GPO 来增大安全日志的大小。

由于实现 IPsec 需要建立复杂的规则，因此许多组织在部署 IPsec 的道路上步履维艰。但如果您仅要求在 DC 间进行通信，那么相对而言就比较容易实现。要实现从 DC 到客户端之间的通信，有许多方案可供选择。默认情况下，Windows Server 2003 的 DC 启用了 SMB 签名功能，这意味着它们能够将所有通信签名发送给客户端，从而避免了欺骗。其策略被列为“Microsoft 网络服务器：数字签名的通信（总是）”。在升级时请注意此项更改，如果不是必要请不要禁用它。

您应尽量避免保留 LM (Lan Manager) 密码的哈希；许多密码破解器能够攻击弱 LM 哈希，然后推导更强的 NTLM 哈希。您需要的策略是“不要在下次更改密码时存储 LAN Manager 的哈希值”。另外请考虑启动“仅发送 NTLMv2 响应，拒绝 LM 和 NTLM”。大多数下层客户端可以配置为使用 NTLMv2。但是对于在工厂环境中安装 Active Directory 或使用嵌入式 Windows 的其他安装方式，可能无法实现这一功能。请谨慎地测试这些设置，因为它们可能会造成下层客户端瘫痪。需要记住的重要一点是，这些客户端不仅包括 Windows NT 4.0 和 Windows Me，而且还包括其他启用了服务器消息块 (SMB) 的网络客户端，例如网络附加存储 (NAS) 设备、运行 Samba 的 UNIX 客户端或诸如工厂工作站控制器的嵌入式 Windows 设备。知识库文章“修改安全设置和用户权限分配时可能出现的客户端、服务和程序不兼容问题”中列出了对于绝大多数 DC 进行安全设置和分配用户权限的建议。

在面临以下问题时解决紧急事件和记录流程，如密码泄漏、常见 Active Directory 攻击和 Active Directory 灾难恢复。在这方面，Microsoft 为您做了大量工作，具体内容请参阅“保护 Active Directory 安装安全的最佳实践指南”和“最佳实践：Active Directory 林恢复”。

本文中的预发布信息可能随时更改。