通过

Implementing Least-Privilege Administrative Models（实施最小特权管理模式）

  • 项目

适用范围：Windows Server 2022、Windows Server 2019、Windows Server 2016、Windows Server 2012 R2、Windows Server 2012

以下内容节选自 1999 年 4 月 1 日首次发布的 Administrator 帐户安全规划指南：

“大多数与安全相关的培训课程和文档都讨论了最小特权原则的实现过程，但组织却很少遵循这一过程。 原则很简单，正确应用它可大大提高安全性并降低风险。 该原则规定，所有用户都应使用拥有完成当前任务所需的绝对最低权限（不包含其他任何权限）的用户帐户进行登录。 这样可预防恶意代码及其他攻击。 此原则适用于计算机以及这些计算机的用户。 “这个原则如此有效的原因之一是它会强制你进行一些内部研究。 例如，必须确定计算机或用户真正需要的访问特权，然后实现这些特权。 对于许多组织来说，此任务最初可能看起来是一项艰巨的工作，但这是成功保护网络环境的必要步骤。” 应根据最小特权的概念向所有域管理员用户授予其域特权。 例如，如果管理员使用特权帐户登录并无意中运行了病毒程序，则病毒具有对本地计算机和整个域的管理访问权限。 如果管理员改为使用非特权（非管理）帐户登录，则病毒的损害范围将仅限于本地计算机，因为它是以本地计算机用户身份运行的。 “在另一个示例中，即使林之间存在信任关系，授予域级别管理员权限的帐户也不得在另一个林中具有提升的权限。 如果攻击者设法破坏一个受管理林，此策略有助于防止大范围损害。 组织应定期审核其网络，以防止未经授权的特权升级。”

以下内容节选自 2005 年首次发布的 Microsoft Windows 安全中心资源工具包：

“始终从授予执行任务所需的最小特权的角度考虑安全性。 如果具有过多特权的应用程序遭到入侵，则攻击者能够将攻击扩展到该应用程序具有尽可能小的特权时的攻击范围之外。 例如，了解网络管理员在无意中打开引发病毒的电子邮件附件所产生的后果。 如果管理员使用域 Administrator 帐户进行登录，则该病毒将具有对域中所有计算机的管理员特权，从而可以不受限制地访问网络上几乎所有的数据。 如果管理员使用本地 Administrator 帐户进行登录，则病毒将在本地计算机上具有管理员特权，从而能够访问计算机上的任何数据，并在计算机上安装恶意软件（如击键记录软件）。 如果管理员使用普通用户帐户进行登录，则病毒将只能访问管理员的数据，并且无法安装恶意软件。 在此示例中，以必要的最小特权来阅读电子邮件，遭到入侵的潜在范围大大缩小。”

特权问题

上述摘录中所述的原则没有改变，但在评估 Active Directory 安装时，我们往往发现，有过多的帐户被授予了远超执行日常工作所需的权利和权限。 环境的大小会影响特权过大帐户的原始数量，但不会影响比例 - 中型目录在最高特权组中可能有数十个帐户，而大型安装可能有数百甚至数千个帐户。 除了少数例外，无论攻击者的技术有多娴熟、工具有多复杂，攻击者通常都会选择阻力最小的路径。 只有当较简单的攻击机制失败或被防御者阻挠时，他们才会增加其攻击工具和攻击方法的复杂性。

遗憾的是，事实证明在许多环境中，阻力最小的路径是过度使用具有广泛和深度特权的帐户的结果。 广泛特权是允许帐户在大范围的环境中执行特定活动的权利和权限 - 例如，支持人员可能被授予使他们能够对许多用户帐户重置密码的权限。

深度特权是应用于有限群体的强大特权，例如授予工程师对服务器的管理员权限，以便他们可以执行修复。 广泛特权和深度特权并不一定是危险的，但当域中的许多帐户被永久性地授予广泛和深度特权时，只要有一个帐户遭到入侵，那么该帐户可以快速用于重新配置环境以达到攻击者的目的，甚至是摧毁大部分基础结构。

哈希传递攻击是一种凭据盗窃攻击，这些攻击无处不在，因为执行这些攻击的工具可以免费获得且易于使用，而且许多环境都容易受到这样的攻击。 但是，哈希传递攻击并不是问题的关键。 问题的关键在两方面：

  1. 攻击者通常可以很容易地在一台计算机上获取深度特权，然后将该特权广泛传播到其他计算机。
  2. 在整个计算环境中，通常有太多具有较高特权级别的永久帐户。

即使消除了哈希传递攻击，攻击者也只会使用不同的方法，而不是使用不同的策略。 他们不会植入包含凭据窃取工具的恶意软件，而是可能植入记录击键的恶意软件，或者利用任何其他方法来捕获整个环境中功能强大的凭据。 无论方法如何，攻击目标都保持不变：具有广泛而深度特权的帐户。

授予的特权过高不仅在受到入侵的环境中的 Active Directory 中被发现。 当组织养成了授予超过所需权限的习惯时，通常会在整个基础架构中发现这种情况，如以下部分所述。

在 Active Directory 中

在 Active Directory 中，通常会发现 EA、DA 和 BA 组包含过多的帐户。 最常见的情况是，组织的 EA 组包含的成员最少，DA 组中包含的用户数通常为 EA 组中用户数的几倍，而管理员组包含的成员通常比其他组的总和还要多。 这通常是因为人们认为管理员的特权在某种程度上比 DA 或 EA“低”。 虽然授予这些组的权利和权限各不相同，但它们实际上应该被看作是同等强大的组，因为一个组的成员可以使自己成为另两个组的成员。

在成员服务器上

在许多环境中检索成员服务器上本地管理员组的成员资格时，我们发现成员资格范围从少数本地帐户和域帐户到数十个嵌套组，这些嵌套组在扩展时会显示数百甚至数千个在服务器上具有本地管理员特权的帐户。 在许多情况下，具有大型成员资格的域组嵌套在成员服务器的本地管理员组中，而不考虑以下事实：任何可以在域中修改这些组的成员资格的用户都可以获得对组已嵌套在本地管理员组中的所有系统的管理控制权。

在工作站上

尽管工作站的本地管理员组中的成员通常比成员服务器少得多，但在许多环境中，用户会在其个人计算机上被授予本地管理员组的成员资格。 发生这种情况时，即使启用了 UAC，这些用户也会对其工作站的完整性带来更高的风险。

重要

应仔细考虑用户是否需要对其工作站的管理权限，如果需要，更好的方法是在作为管理员组成员的计算机上创建单独的本地帐户。 当用户需要提升权限时，他们可以提供该本地帐户的凭据来进行提升，但由于该帐户是本地帐户，因此它不能用于入侵其他计算机或访问域资源。 但是，与任何本地帐户一样，本地特权帐户的凭据应是唯一的；如果在多个工作站上创建具有相同凭据的本地帐户，则会将计算机暴露在哈希传递攻击之下。

在应用程序中

在以组织的知识产权为目标的攻击中，在应用程序中被授予强大特权的帐户可能成为目标，从而造成数据外泄。 尽管有权访问敏感数据的帐户可能未在域或操作系统中被授予提升的权限，但可以操作应用程序的配置或对应用程序所提供信息的访问权限的帐户存在风险。

在数据存储库中

与其他目标一样，寻求以文档和其他文件形式访问知识产权的攻击者能够以这些帐户为目标：控制对文件存储的访问权限的帐户、可以直接访问文件的帐户，以及有权访问文件的组或角色。 例如，如果使用文件服务器来存储合同文档，并且通过使用 Active Directory 组授予对文档的访问权限，则可以修改组成员资格的攻击者可以将已泄露的帐户添加到组并访问合同文档。 在 SharePoint 等应用程序提供对文档的访问权限的情况下，攻击者可以如前所述以应用程序为目标。

降低特权

环境越大，越复杂，就越难管理和保护。 在小型组织中，审查和减少特权可能是一个相对简单的提议，但组织中使用的每个附加服务器、工作站、用户帐户和应用程序都会增加另一个必须保护的对象。 由于要妥善保护组织 IT 基础结构的各个方面难度较高或者近乎不可能，因此应首先将精力集中在特权带来重大风险的帐户上，这些帐户通常是 Active Directory 中的内置特权帐户和组，以及工作站和成员服务器上的特权本地帐户。

保护工作站和成员服务器上的本地 Administrator 帐户

尽管本文档重点介绍如何保护 Active Directory（如前所述），但针对该目录的大多数攻击都是从针对单个主机的攻击开始的。 无法提供有关在成员系统上保护本地组的完整指南，但以下建议可用于帮助保护工作站和成员服务器上的本地 Administrator 帐户。

保护本地 Administrator 帐户

在目前主流支持的所有 Windows 版本上，默认禁用了本地 Administrator 帐户，这使得该帐户无法用于“哈希传递”及其他凭据盗窃攻击。 但在包含旧操作系统或已启用本地 Administrator 帐户的域中，如前所述，这些帐户可用于跨成员服务器和工作站传播入侵。 出于此原因，建议对加入域的系统上的所有本地 Administrator 帐户使用以下控制。

附录 H：保护本地 Administrator 帐户和组中提供了有关实现这些控制的详细说明。 但是，在实现这些设置之前，请确保环境中当前未使用本地 Administrator 帐户来在计算机上运行服务或执行不应使用这些帐户的其他活动。 在生产环境中实现这些设置之前，请对其进行全面测试。

用于本地 Administrator 帐户的控制措施

内置 Administrator 帐户绝不应该用作成员服务器上的服务帐户，也不应该将其用于登录本地计算机（除非在安全模式下，即使禁用该帐户也允许使用安全模式）。 除非首先撤销保护性控制，实现此处所述的设置旨在防止每台计算机的本地 Administrator 帐户可用。 通过实现这些控制并监视 Administrator 帐户的更改，可以显著降低针对本地 Administrator 帐户的攻击成功的可能性。

配置 GPO 以限制加入域的系统上的 Administrator 帐户

在所创建并链接到每个域中工作站和成员服务器 OU 的一个或多个 GPO 中，将 Administrator 帐户添加到 Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\User Rights Assignments 中的以下用户权限：

  • 拒绝通过网络访问该计算机
  • 拒绝以批处理作业身份登录
  • 拒绝以服务登录
  • 拒绝通过远程桌面服务登录

向这些用户权限添加 Administrator 帐户时，请通过标记帐户的方式指定是添加本地 Administrator 帐户还是域的 Administrator 帐户。 例如，若要向这些拒绝权限添加 NWTRADERS 域的 Administrator 帐户，需以 NWTRADERS\Administrator 形式键入该帐户，或浏览到 NWTRADERS 域的 Administrator 帐户。 若要确保限制本地 Administrator 帐户，请在“组策略对象编辑器”中的这些用户权限设置中键入“Administrator”。

注意

即使重命名了本地 Administrator 帐户，这些策略仍适用。

这些设置将确保计算机的 Administrator 帐户不能用于连接到其他计算机（即使是无意中或恶意启用了该帐户）。 不能完全禁用使用本地 Administrator 帐户的本地登录，也不应尝试这样做，因为计算机的本地 Administrator 帐户旨在用于灾难恢复场景。

如果成员服务器或工作站脱离域，且没有其他本地帐户被授予管理权限，则计算机可以启动到安全模式，可以启用 Administrator 帐户，然后可以使用该帐户对计算机执行修复。 修复完成后，应再次禁用 Administrator 帐户。

保护 Active Directory 中的本地特权帐户和组

第六法则：计算机的安全程度取决于管理员是否值得信赖。 - 安全性的十项不变法则（版本 2.0）

此处提供的信息旨在提供有关保护 Active Directory 中最高特权内置帐户和组的一般准则。 附录 D：保护 Active Directory 中的内置 Administrator 帐户、附录 E：保护 Active Directory 中的企业管理员组、附录 F：保护 Active Directory 中的域管理员组以及附录 G：保护 Active Directory 中的管理员组中也提供了详细的分步说明。

在实现其中任何设置之前，还应全面测试所有设置，以确定它们是否适合你的环境。 并非所有组织都可以实现这些设置。

保护 Active Directory 中的内置 Administrator 帐户

在 Active Directory 的每个域中，都会在创建域的过程中创建一个 Administrator 帐户。 默认情况下，此帐户是域中域管理员组和管理员组的成员，如果该域是目录林根级域，则该帐户也是企业管理员组的成员。 域的本地 Administrator 帐户应仅供初始生成活动以及可能的灾难恢复场景使用。 为了确保在不能使用其他帐户的情况下可以使用内置 Administrator 帐户进行修复，不应更改林中任何域中 Administrator 帐户的默认成员。 应改为按照准则来帮助保护林中每个域中的 Administrator 帐户。 附录 D：保护 Active Directory 中的内置 Administrator 帐户中提供了实现这些控制的详细说明。

内置 Administrator 帐户的控制

除非撤消了许多控制，实现此处所述的设置旨在防止每个域的 Administrator 帐户（不是组）可用。 通过实现这些控制并监视 Administrator 帐户的更改，可以通过利用域的 Administrator 帐户显著降低成功攻击的可能性。 对于林中每个域中的 Administrator 帐户，应配置以下设置。

在帐户上启用“敏感帐户，不能被委派”标志

默认情况下，可以委派 Active Directory 中的所有帐户。 通过委派，计算机或服务可以向其他计算机提供已向计算机或服务进行身份验证的帐户的凭据，以代表该帐户获取服务。 在基于域的帐户上启用“敏感帐户，不能被委派”属性时，该帐户的凭据无法提供给网络上的其他计算机或服务，这会限制利用委派在其他系统上使用该帐户凭据的攻击。

在帐户上启用“交互式登录必须使用智能卡”标志

在帐户上启用“交互式登录必须使用智能卡”属性时，Windows 会将帐户的密码重置为 120 个字符的随机值。 通过在内置 Administrator 帐户上设置此标志，确保帐户的密码不仅长且复杂，而且不为任何用户所知。 在启用此属性之前，在技术上没有必要为帐户创建智能卡，但应尽可能在配置帐户限制之前为每个 Administrator 帐户创建智能卡，并且智能卡应存储在安全位置。

尽管设置“交互式登录必须使用智能卡”标志会重置帐户密码，但它不会阻止有权重置帐户密码的用户将帐户设置为已知值，并使用帐户名和新密码访问网络上的资源。 因此，应在帐户上实现以下附加控制。

配置 GPO 以限制加入域的系统上的域 Administrator 帐户

尽管禁用域中的 Administrator 帐户会使帐户实际上不可用，但你应该对帐户实现其他限制，以防帐户被无意或恶意启用。 尽管 Administrator 帐户最终可以撤消这些控制，但目标是创建控制以减缓攻击者的进度并限制帐户可能造成的损害。

在创建并链接到每个域中的工作站和成员服务器 OU 的一个或多个 GPO 中，将每个域的 Administrator 帐户添加到“计算机配置”\“策略”\“Windows 设置”\“安全设置”\“本地策略”\“用户权限分配”中的以下用户权限：

  • 拒绝通过网络访问该计算机
  • 拒绝以批处理作业身份登录
  • 拒绝以服务登录
  • 拒绝通过远程桌面服务登录

注意

将本地 Administrator 帐户添加到此设置时，必须指定是要配置本地 Administrator 帐户还是域 Administrator 帐户。 例如，若要向这些拒绝权限添加 NWTRADERS 域的本地 Administrator 帐户，必须以 NWTRADERS\Administrator 形式键入该帐户，或浏览到 NWTRADERS 域的本地 Administrator 帐户。 如果在组策略对象编辑器中的这些用户权限设置中键入“Administrator”，将会限制应用 GPO 的每台计算机上的本地 Administrator 帐户。

建议使用与基于域的 Administrator 帐户相同的方式限制成员服务器和工作站上的本地 Administrator 帐户。 因此，通常应将林中每个域的 Administrator 帐户和本地计算机的 Administrator 帐户添加到这些用户权限设置。

配置 GPO 以限制在域控制器上的 Administrator 帐户

在林中的每个域中，应修改默认域控制器策略或链接到域控制器 OU 的策略，以将每个域的 Administrator 帐户添加到“计算机配置”\“策略”\“Windows 设置”\“安全设置”\“本地策略”\“用户权限分配”中的以下用户权限：

  • 拒绝通过网络访问该计算机
  • 拒绝以批处理作业身份登录
  • 拒绝以服务登录
  • 拒绝通过远程桌面服务登录

注意

这些设置将确保本地 Administrator 帐户不能用于连接到域控制器，尽管该帐户（如果启用）可以在本地登录到域控制器。 由于仅应在灾难恢复场景中启用并使用此帐户，因此预计至少有一个域控制器的物理访问权限可用，或者可以使用其他有权远程访问域控制器的帐户。

配置内置 Administrator 帐户的审核

保护每个域的 Administrator 帐户并将其禁用后，应配置审核以监视帐户的更改情况。 如果帐户已启用、进行了密码重置或对帐户进行了任何其他修改，则除了将警报发送给组织中的事件响应团队外，还应发送给负责管理 AD DS 的用户或团队。

保护管理员组、域管理员组和企业管理员组

保护企业管理员组

位于目录林根级域中的企业管理员组在日常工作中不应包含任何用户，域的本地 Administrator 帐户可能除外，前提是已按前文和附录 D：保护 Active Directory 中的内置 Administrator 帐户的安全中的说明保护该帐户。

当需要 EA 访问权限时，其帐户需要 EA 权利和权限的用户应暂时置于企业管理员组中。 尽管用户使用的是高特权帐户，但应审核其活动，最好是让一个用户执行更改，另一个用户观察更改，以最大程度地降低意外滥用或配置错误的可能性。 活动完成后，应从 EA 组中删除帐户。 这可以通过手动过程和记录的过程、第三方特权标识/访问管理 (PIM/PAM) 软件来实现，也可以同时通过这两者来实现。 凭据容易被盗的帐户中提供了有关创建可用于控制 Active Directory 中特权组成员资格的帐户的指南，附录 I：为 Active Directory 中受保护的帐户和组创建管理帐户中提供了详细说明。

默认情况下，企业管理员是林中每个域的内置管理员组成员。 从每个域的管理员组中删除企业管理员组不是正确的修改方式，因为在发生林灾难恢复的情况下，可能需要 EA 权限。 如果企业管理员组已从林中的管理员组中删除，则应将其添加到每个域中的管理员组，并应实现以下附加控制：

  • 如前所述，企业管理员组在日常工作中不应包含任何用户，目录林根级域的 Administrator 帐户可能除外，该帐户应按照附录 D：保护 Active Directory 中内置 Administrator 帐户所述进行保护。
  • 在链接到每个域中包含成员服务器和工作站的 OU 的 GPO 中，EA 组应添加到以下用户权限：
    • 拒绝通过网络访问该计算机
    • 拒绝以批处理作业身份登录
    • 拒绝以服务身份登录
    • 拒绝本地登录
    • 拒绝通过远程桌面服务登录。

这将阻止 EA 组的成员登录到成员服务器和工作站。 如果使用跳转服务器来管理域控制器和 Active Directory，请确保跳转服务器位于限制性 GPO 未链接到的 OU 中。

  • 审核应配置为在对 EA 组的属性或成员资格进行任何修改时发送警报。 这些警报至少应发送给负责 Active Directory 管理和事件响应的用户或团队。 还应定义临时填充 EA 组的流程和过程，包括执行组的合法填充时的通知过程。

保护域管理员组

与企业管理员组的情况一样，只有在生成或灾难恢复场景中才需要域管理员组中的成员资格。 DA 组中不应有任何日常用户帐户，但域的本地 Administrator 帐户除外，前提是已按照附录 D：保护 Active Directory 中的内置 Administrator 帐户中所述进行了保护。

当需要 DA 访问权限时，需要此访问权限级别的帐户应暂时放在相关域的 DA 组中。 尽管用户使用的是高特权帐户，但应审核活动，最好是让一个用户执行更改，另一个用户观察更改，以最大程度地降低意外滥用或配置错误的可能性。 活动完成后，应从域管理员组中删除帐户。 这可以通过手动过程和记录的过程、第三方特权标识/访问管理 (PIM/PAM) 软件来实现，也可以同时通过这两者来实现。 附录 I：为 Active Directory 中受保护的帐户和组创建管理帐户中提供了有关创建可用于控制 Active Directory 中特权组成员资格的帐户的指南。

默认情况下，Domain Admins 是其各自域中所有成员服务器和工作站上的本地 Administrators 组的成员。 不应修改此默认嵌套，因为它会影响可支持性和灾难恢复选项。 如果域管理员组已从成员服务器上的本地管理员组中删除，则应通过链接的 GPO 中的受限组设置将其添加到域中每个成员服务器和工作站上的管理员组。 还应实现附录 F：保护 Active Directory 中的域管理员组中详细介绍的以下常规控制。

对于林中每个域中的 Domain Admins 组：

  1. 删除 DA 组中的所有成员，域的内置 Administrator 帐户可能除外，前提是已按照附录 D：保护 Active Directory 中的内置 Administrator 帐户中所述进行了保护。

  2. 在链接到每个域中包含成员服务器和工作站的 OU 的 GPO 中，DA 组应添加到以下用户权限：

    • 拒绝通过网络访问该计算机
    • 拒绝以批处理作业身份登录
    • 拒绝以服务身份登录
    • 拒绝本地登录
    • 拒绝通过远程桌面服务登录

    这将阻止 DA 组的成员登录到成员服务器和工作站。 如果使用跳转服务器来管理域控制器和 Active Directory，请确保跳转服务器位于限制性 GPO 未链接到的 OU 中。

  3. 审核应配置为在对 DA 组的属性或成员资格进行任何修改时发送警报。 这些警报至少应发送给负责 AD DS 管理和事件响应的用户或团队。 还应定义临时填充 DA 组的流程和过程，包括执行组的合法填充时的通知过程。

保护 Active Directory 中的 Administrators 组

与 EA 组和 DA 组的情况一样，只有在生成或灾难恢复场景中才需要管理员 (BA) 组中的成员资格。 管理员组中不应有任何日常用户帐户，但域的本地 Administrator 帐户除外，前提是已按照附录 D：保护 Active Directory 中的内置 Administrator 帐户中所述进行了保护。

当需要管理员访问权限时，需要此访问权限级别的帐户应暂时放在相关域的管理员组中。 尽管用户使用的是高特权帐户，但应审核活动，最好是让一个用户执行更改，另一个用户观察更改，以最大程度地降低意外滥用或配置错误的可能性。 活动完成后，应立即从管理员组中删除帐户。 这可以通过手动过程和记录的过程、第三方特权标识/访问管理 (PIM/PAM) 软件来实现，也可以同时通过这两者来实现。

默认情况下，管理员是其各自域中大多数 AD DS 对象的所有者。 在需要拥有或能够获取对象所有权的生成和灾难恢复场景中，可能需要此组中的成员资格。 此外，DA 和 EA 会凭借其在管理员组中的默认成员资格继承他们的许多权利和权限。 不应修改 Active Directory 中特权组的默认组嵌套，并且应按照附录 G：保护 Active Directory 中的管理员组和以下常规说明中所述保护每个域的管理员组。

  1. 删除管理员组中的所有成员，域的本地 Administrator 帐户可能除外，前提是已按照附录 D：保护 Active Directory 中的内置 Administrator 帐户中所述进行了保护。

  2. 域的管理员组的成员始终不需要登录到成员服务器或工作站。 在链接到每个域中的工作站和成员服务器 OU 的一个或多个 GPO 中，管理员组应添加到以下用户权限：

    • 拒绝从网络访问此计算机
    • 拒绝以批处理作业登录
    • 拒绝以服务身份登录
    • 这可防止管理员组的成员被用于登录或连接到成员服务器或工作站（除非先破坏了多个控制），他们的凭据可能会被缓存在这些服务器或工作站中，因此遭到泄露。 绝不要使用特权帐户登录到特权较低的系统，并且强制执行这些控制措施可以防范许多攻击。

  3. 在林中每个域的域控制器 OU 中，应向管理员组授予以下用户权限（如果他们还没有这些权限），这些权限可让管理员组的成员执行林范围的灾难恢复场景所必要的功能：

    • 从网络访问此计算机
    • 允许本地登录
    • 允许通过远程桌面服务登录

  4. 审核应配置为在对管理员组的属性或成员身份进行任何修改时发送警报。 这些警报至少应发送给负责 AD DS 管理的团队成员。 同时还应向安全团队成员发送警报，并定义用于修改管理员组成员资格的过程。 具体来说，这些流程应包括一个过程，通过该过程，当管理员组要进行修改时，安全团队会收到通知，以便在发送警报时，这些警报都在预期内，并且不会引发警报。 此外，应实现在使用完管理员组且已从组中删除所用帐户时通知安全团队的过程。

注意

在 GPO 中对管理员组实现限制时，除了域的管理员组外，Windows 还会将设置应用于计算机的本地管理员组的成员。 因此，在对管理员组实现限制时，应特别注意。 尽管建议在可行的情况下禁止管理员组成员的网络、批处理和服务登录，但不要限制本地登录或通过远程桌面服务登录。 阻止这些登录类型可能会导致本地管理员组的成员无法对计算机进行合法管理。 以下屏幕截图显示了阻止滥用内置本地和域管理员帐户以及内置本地或域管理员组的配置设置。 请注意，“拒绝通过远程桌面服务登录”用户权限不包括管理员组，因为将其包含在此设置中也会阻止作为本地计算机管理员组成员的帐户的这些登录。 如果计算机上的服务配置为在本部分所述的任何特权组的上下文中运行，则实现这些设置可能会导致服务和应用程序失败。 因此，与本部分中的所有建议一样，应全面测试设置在环境中的适用性。

least privilege admin models

Active Directory 的基于角色的访问控制 (RBAC)

一般而言，基于角色的访问控制 (RBAC) 是一种根据业务规则对用户进行分组并提供对资源的访问权限的机制。 对于 Active Directory，实现 AD DS 的 RBAC 是创建向其委派权利和权限的角色的过程，让角色的成员可以在不对其授予过多特权的情况下执行日常管理任务。 Active Directory 的 RBAC 可以通过本机工具和接口进行设计和实现，方法是利用你可能已经拥有的软件、购买第三方产品或这些方法的任意组合。 本部分不提供实现 Active Directory 的 RBAC 的分步说明，而是讨论在 AD DS 安装中选择实现 RBAC 的方法时应考虑的因素。

Active Directory 的 RBAC 的本机方法

在最简单的 RBAC 实现中，可以将角色实现为 AD DS 组，并将权利和权限委派给组，使他们能够在指定的角色范围内执行日常管理。

在某些情况下，Active Directory 中的现有安全组可用于授予适用于作业功能的权利和权限。 例如，如果 IT 组织中的特定员工负责 DNS 区域和记录的管理和维护，则委派这些职责就跟为每个 DNS 管理员创建一个帐户并将其添加到 Active Directory 中的 DNS 管理员组一样简单。 与特权更高的组不同，DNS 管理员组在 Active Directory 中几乎没有强大的权利（尽管该组的成员已经被委派了可管理 DNS 的权限），仍然容易遭到入侵，并且滥用可能导致特权提升。

在其他情况下，可能需要创建安全组并将权利和权限委派给 Active Directory 对象、文件系统对象和注册表对象，以允许组成员执行指定的管理任务。 例如，如果技术支持操作员负责重置忘记的密码、帮助用户解决连接问题以及排查应用程序设置问题，则你可能需要将 Active Directory 中用户对象的委派设置与允许技术支持用户远程连接到用户计算机以查看或修改用户配置设置的权限相结合。 对于定义的每个角色，应确定：

  1. 角色成员每天执行哪些任务，哪些任务执行频率较低。
  2. 应在哪些系统和哪些应用程序中向角色成员授予权利和权限。
  3. 应向哪些用户授予角色成员资格。
  4. 如何执行角色成员资格的管理。

在许多环境中，手动创建基于角色的访问控制来管理 Active Directory 环境可能难以实现和维护。 如果已明确定义管理 IT 基础结构的角色和职责，则可能需要利用其他工具来帮助创建可管理的本机 RBAC 部署。 例如，如果在环境中使用了 Forefront Identity Manager (FIM)，则可以使用 FIM 自动创建和填充管理角色，从而简化正在进行的管理。 如果使用 Microsoft Endpoint Configuration Manager 和 System Center Operations Manager (SCOM)，则可以使用特定于应用程序的角色来委派管理和监视功能，还可以在域中跨系统强制执行一致的配置和审核。 如果已实现公钥基础结构 (PKI)，则可以为负责管理环境的 IT 人员发放智能卡并要求其使用智能卡。 使用 FIM 凭据管理 (FIM CM)，你甚至可以为管理人员组合管理角色和凭据。

在其他情况下，组织最好考虑部署提供“即装即用”功能的第三方 RBAC 软件。 许多供应商提供了适用于 Active Directory、Windows 和非 Windows 目录和操作系统的 RBAC 的商业现成 (COTS) 解决方案。 在本机解决方案和第三方产品之间进行选择时，应考虑以下因素：

  1. 预算：通过使用你可能已经拥有的软件和工具投资开发 RBAC，可以降低部署解决方案所涉及的软件成本。 但是，除非你有在创建和部署本机 RBAC 解决方案方面经验丰富的员工，否则可能需要使用咨询资源来开发解决方案。 应仔细权衡自定义开发解决方案的预期成本与部署“即装即用”解决方案的成本，尤其是在预算有限的情况下。
  2. IT 环境的构成：如果环境主要由 Windows 系统组成，或者如果你已经利用 Active Directory 来管理非 Windows 系统和帐户，则自定义本机解决方案可针对你的需求提供最佳解决方案。 如果基础结构包含许多未运行 Windows 且不受 Active Directory 管理的系统，则可能需要考虑将非 Windows 系统与 Active Directory 环境分开管理的选项。
  3. 解决方案中的特权模型：如果产品依赖于将其服务帐户置于 Active Directory 中的高特权组中，并且不提供不需要向 RBAC 软件授予过多特权的选项，则你并没有真正减少 Active Directory 攻击面，只是更改了目录中最高特权组的组成。 除非应用程序供应商可以为服务帐户提供控制，以最大程度地降低帐户被入侵和恶意使用的可能性，否则可能需要考虑其他选项。

Privileged Identity Management

特权标识管理 (PIM) 有时称为特权帐户管理 (PAM) 或特权凭据管理 (PCM)，是基础结构中管理特权帐户的方法的设计、构造和实现。 一般来说，PIM 提供了一些机制，通过这些机制向帐户授予执行生成或中断修复功能所需的临时权利和权限，而不是将特权永久附加到帐户。 无论 PIM 功能是手动创建的还是通过部署第三方软件实现的，都可以使用以下一项或多项功能：

  • 凭据“保管库”，其中特权帐户的密码“签出”并分配了初始密码，然后在活动完成后“签入”，此时将再次重置帐户的密码。
  • 使用特权凭据的时间限制
  • 一次性凭据
  • 工作流生成的特权授予，对执行的活动进行监视和报告，并在活动完成或分配的时间过期时自动删除特权
  • 将硬编码凭据（如脚本中的用户名和密码）替换为应用程序编程接口 (API)，以便根据需要从保管库检索凭据
  • 自动管理服务帐户凭据

创建无特权帐户以管理特权帐户

管理特权帐户的难点之一是，默认情况下，可以管理特权和受保护帐户和组的帐户是特权和受保护帐户。 如果为 Active Directory 安装实现适当的 RBAC 和 PIM 解决方案，则解决方案可能包括一些方法，使你能够有效地取消填充目录中最高特权组的成员资格，仅在需要时暂时填充这些组。

但是，如果实现本机 RBAC 和 PIM，则应考虑创建没有特权且唯一功能为在需要时在 Active Directory 中填充和取消填充特权组的帐户。 附录 I：在 Active Directory 中为受保护的帐户和组创建管理帐户提供了可用于为此目的创建帐户的分步说明。

实现可靠的身份验证控制

第六法则：确实有人在试图猜测你的密码。 - 安全管理的 10 项不变法则

哈希传递和其他凭据盗窃攻击并非特定于 Windows 操作系统的攻击，也不是新出现的攻击。 首次哈希传递攻击出现在 1997 年。 但是，从历史上看，这些攻击需要自定义工具，攻击是否成功是随机的，并且需要攻击者具有相对较高的技能。 近年来，由于引入了免费可用、易于使用的以本机方式提取凭据的工具，凭据盗窃攻击的数量和成功率呈指数级增长。 但是，凭据盗窃攻击绝不是凭据被攻击和泄露的唯一机制。

尽管应实现控制来帮助防范凭据盗窃攻击，但还应确定环境中最有可能成为攻击者目标的帐户，并对这些帐户实现可靠的身份验证控制。 如果最高特权帐户使用单因素身份验证，如用户名和密码（两者都是“你知道的内容”，这是一个身份验证因素），那么这些帐户受到的保护较弱。 攻击者只需要了解与帐户关联的用户名和密码，在不需要进行哈希传递攻击的情况下即可以用户身份向接受单因素凭据的任何系统进行身份验证。

尽管实现多重身份验证并不能保护你免受哈希传递攻击，但将多重身份验证与受保护的系统结合使用可以保护你免受攻击。 有关实现受保护系统的详细信息，请参阅实现安全管理主机，身份验证选项在以下部分进行了讨论。

常规身份验证控制

如果尚未实现多重身份验证（如智能卡），请考虑这样做。 智能卡可以在公钥/私钥对中实现硬件强制执行的私钥保护，从而保护用户私钥不受访问和使用，除非用户向智能卡提供正确的 PIN、密码或生物特征识别码。 即使用户的 PIN 或密码在遭到入侵的计算机上由按键记录程序截获，攻击者还必须要得到真实的智能卡才能重复使用 PIN 或密码。

对于复杂的长密码由于用户抵制而被证明难以实现的情况，智能卡提供了一种使用户能够实现相对简单的 PIN 或密码且让凭据不易受到暴力攻击或彩虹表攻击的机制。 尽管凭据哈希可能仍存储在智能卡用于身份验证的计算机上使用 LSASS 保护的内存中，但智能卡 PIN 并未存储在 Active Directory 或本地 SAM 数据库中。

VIP 帐户的其他控制

实现智能卡或其他基于证书的身份验证机制的另一个优势是能够利用身份验证机制保证来保护 VIP 用户可以访问的敏感数据。 身份验证机制保证在功能级别设置为 Windows Server 2012 或 Windows Server 2008 R2 的域中可用。 启用后，当使用基于证书的登录方法在登录期间对用户的凭据进行身份验证时，身份验证机制保证会将管理员指定的全局组成员资格添加到用户的 Kerberos 令牌中。

这样，资源管理员可以根据用户是否使用基于证书的登录方法登录，以及所使用的证书类型来控制对资源（如文件、文件夹和打印机）的访问。 例如，当用户使用智能卡登录时，用户对网络资源的访问可以指定为不同于用户不使用智能卡时（即用户通过输入用户名和密码登录时）的访问。 有关身份验证机制保证的详细信息，请参阅 Windows Server 2008 R2 中 AD DS 身份验证机制保证分步指南。

配置特权帐户身份验证

在所有管理帐户的 Active Directory 中，启用“交互式登录需要智能卡”属性，并审核（至少）对帐户管理用户对象的“帐户”选项卡上的任何属性（例如 cn、name、sAMAccountName、userPrincipalName 和 userAccountControl）的更改。

尽管在帐户上设置“交互式登录需要智能卡”会将帐户密码重置为 120 个字符的随机值，并且要求对交互式登录使用智能卡，但该属性仍然可由具有允许他们更改帐户密码的权限的用户覆盖，然后可以使用这些帐户建立仅使用用户名和密码的非交互式登录。

在其他情况下，根据 Active Directory 中的帐户配置以及 Active Directory 证书服务 (AD CS) 或第三方 PKI 中的证书设置，管理帐户或 VIP 帐户的用户主体名称 (UPN) 属性会成为特定类型攻击的目标，如此处所述。

用于证书欺骗的 UPN 劫持

尽管本文档没有对公钥基础结构 (PKI) 攻击进行全面介绍，但自 2008 年以来，针对公共和专用 PKI 的攻击呈指数级增长。 对公共 PKI 的破坏已经广为人知，但是对组织内部 PKI 的攻击可能更加频繁。 此类攻击利用 Active Directory 和证书让攻击者能够以难以检测的方式欺骗其他帐户的凭据。

当提供证书向加入域的系统进行身份验证时，证书中“使用者”或“使用者可选名称”(SAN) 属性的内容用于将证书映射到 Active Directory 中的用户对象。 根据证书的类型及其构造方式，证书中的“使用者”属性通常包含用户的公用名 (CN)，如以下屏幕截图所示。

Screenshot that shows the Subject attribute in a certificate typically contains a user's common name.

默认情况下，Active Directory 通过连接帐户的名字 +“ ”+ 姓氏来构造用户的 CN。 但是，Active Directory 中用户对象的 CN 组件不是必需的，也不保证其是唯一的，将用户帐户移动到目录中的其他位置会更改帐户的可分辨名称 (DN)，该名称是目录中对象的完整路径，如上一屏幕截图的底部窗格中所示。

由于不能保证证书使用者名称是静态的或唯一的，因此使用者可选名称的内容通常用于在 Active Directory 中查找用户对象。 企业证书颁发机构（Active Directory 集成 CA）颁发给用户的证书的 SAN 属性通常包含用户的 UPN 或电子邮件地址。 由于 UPN 在 AD DS 林中保证是唯一的，因此通过 UPN 查找用户对象通常在身份验证过程执行，无论在身份验证过程中是否涉及证书。

攻击者可以通过在身份验证证书的 SAN 属性中使用 UPN 来获取欺诈性证书。 如果攻击者入侵了能够在用户对象上读取和写入 UPN 的帐户，则会按如下方式实现攻击：

用户对象（如 VIP 用户）的 UPN 属性临时更改为其他的值。 此时还可以更改 SAM 帐户名称属性和 CN（尽管由于前面所述的原因，通常不需要这样做）。

更改目标帐户的 UPN 属性后，已启用的旧用户帐户或新创建的用户帐户的 UPN 属性将更改为最初分配给目标帐户的值。 已启用的旧用户帐户是长时间未登录但尚未被禁用的帐户。 打算“藏在眼皮底下”的攻击者会以这些帐户为目标，原因如下：

  1. 由于该帐户已启用，但最近没有使用过，因此使用该帐户不太可能像启用已禁用的用户帐户那样触发警报。
  2. 使用现有帐户不需要创建管理员可能会注意到的新用户帐户。
  3. 仍处于启用状态的旧用户帐户通常是各种安全组的成员，并被授予对网络资源的访问权限，从而简化访问并“融入”现有用户群。

现在已配置目标 UPN 的用户帐户用于从 Active Directory 证书服务请求一个或多个证书。

为攻击者的帐户获取证书后，“新”帐户和目标帐户上的 UPN 将返回到其原始值。

攻击者现在拥有一个或多个证书，这些证书可用于向资源和应用程序进行身份验证，就好像该用户是帐户被临时修改过的 VIP 用户一样。 尽管本文档没有全面讨论攻击者以证书和 PKI 为目标的所有攻击方式，但提供此攻击机制是为了说明为何应监视 AD DS 中的特权帐户和 VIP 帐户的更改，特别是对于帐户的“帐户”选项卡上的任何属性（例如，cn、name、sAMAccountName、userPrincipalName 和 userAccountControl）更改。 除了监视帐户外，还应将可以修改帐户的人员限制为尽可能少的一组管理用户。 同样，应保护管理用户的帐户，并监视其未经授权的更改。