使用 Active Directory 的 AdminCount 属性查找特权帐户

具有提升权限的 Active Directory 帐户会带来严重的安全风险：它们是攻击者的首要目标，因为它们提供对系统和数据的管理访问权限，并且它们也可能被其所有者有意或无意地滥用。因此，IT 团队密切跟踪具有提升权限的帐户至关重要。

一种常见策略是监视 Active Directory AdminCount 属性的值。所有 AD 用户、组和计算机对象都具有此属性。默认情况下，其值为“”。但是，当对象被（直接或间接）添加到某些受保护组时，该值将更新为“1”。因此，检查此属性似乎是识别具有管理权限的对象的好方法。

然而，事情并不是那么简单。让我们更深入地了解 Active Directory AdminCount 属性的工作原理，并探讨其在跟踪特权用户方面的局限性。

AdminCount 和受保护的对象

下表列出了 Active Directory 的默认受保护对象集，包括可能导致其成员的 AdminCount 属性更新的组：

您可能还注意到我说“可能会导致 AdminCount 属性的更新”。这是因为有许多变量会影响受保护对象集中的成员资格。让我们从上标注释开始：

1. 默认受保护对象集因不同的 Active Directory 功能级别而异。这会导致组中存在差异，从而可能会更新其成员的 AdminCount 属性。

2. 默认受保护对象集包括四个可以手动从保护中排除的组：帐户操作员、备份操作员、打印操作员和服务器 此行为是在 Windows Server 2000 和 Windows Server 2003 的修补程序中引入的，并在后续版本中保留（这可能有助于解释为什么该过程本身有点复杂）。控制此行为的机制位于 CN=Directory Service,CN=Windows NT,CN=Services, 对象的 dsHeuristics 属性中。此属性的值是一个 Unicode 字符串，其中每个字符代表单个林范围的配置设置。与此讨论相关的字符是第 16 个字符，如果存在，则代表“dwAdminSDExMask”。它的值以十六进制字符表示，但如果我们查看其二进制等价物，会更容易理解其行为。二进制表示中的每一位表示一个特定的组。如果与任何特定组关联的位不为0，则该组将从保护对象集中排除。

3. 默认的保护对象集包括两个用户对象：Administrator 和krbtgt。这些对象受到显式保护，但它们不会引起其他对象的 AdminCount 更新，因为您无法使用户、组或计算机成为用户对象的成员。

4. 默认受保护对象集包括两个不向其成员授予受保护状态的组：域控制器和只读域控制器。虽然在将主机提升为域控制器时 DCPROMO 命令会将关联的计算机对象添加到相应的域控制器组，但它不会导致该对象被添加到受保护对象集中。

5. 默认受保护对象集的成员使用其 objectSID 进行标识。虽然许多默认受保护对象集的成员都配置了 systemFlag 值，以防止它们被重命名或移动，但 Active Directory 依赖这些对象的众所周知的 objectSID 值来确保它们始终被正确识别。

简而言之，有许多行为使了解任何特定域中的哪些组将导致成员的 AdminCount 更新的过程变得复杂。

AdminSDHolder 和 SDPROP

现在我们来谈谈控制 AdminCount 属性行为的机制。

AdminSDHolder 对象

每个 AD 对象都有一个安全描述符，其中包含有关该对象的所有权、其主要组、允许或拒绝访问该对象的用户和组（自由访问控制列表 [DACL]）以及将发生的可审核事件的信息。在安全事件日志（系统访问控制列表 [SACL]）中生成一条记录。它们还包含可以修改安全描述符行为的控制位。

为了帮助保护已知拥有提升管理权限的对象，Active Directory 将称为“权威安全描述符”的严格安全描述符应用于域受保护对象集的每个成员。权威安全描述符在 AdminSDHolder 对象中定义，该对象位于每个 Active Directory 域的默认命名上下文的系统容器中（例如，CN=AdminSDHolder,CN=System,）。

权威安全描述符旨在通过以下方式保护受保护对象：

• 将对象的 DACL 限制为一组受限制的访问控制条目 (ACE)。这些 ACE 将修改对象的能力限制为 NT AUTHORITYSystem 帐户以及管理员、域管理员和企业管理员组的成员。
• 启用对象的 SE_DACL_PROTECTED 安全描述符控制位。这将禁用安全继承并防止受保护对象的 DACL 被任何受保护对象的父对象所拥有的可继承 ACE 修改。
• 将受保护对象的所有权限制为域管理员组。这限制了非特权帐户获取受保护对象所有权的可能性，这将授予非特权帐户对受保护对象的修改权限并允许非特权帐户授予自己对受保护对象的完全控制权。

为了有效，此行为要求 Active Directory 可以确保受保护对象集的每个成员的安全描述符与权威安全描述符 匹配，并且将继续匹配它。它还要求 Active Directory 可以确保当对象成为默认受保护对象集的成员（直接或间接）时，将权威安全描述符应用于对象。

安全描述符传播器 (SDPROP) 任务

Active Directory 通过称为安全描述符传播器 (SDPROP) 的任务来满足这些需求。默认情况下，拥有 PDC 模拟器 FSMO 角色的域控制器上的本地安全机构子系统服务每 60 分钟执行一次此任务。该期限用于限制对高特权对象的安全描述符的修改（无论是恶意的还是意外的）可能持续的时间长度，同时承认 SDPROP 执行的计算成本相对较高。

（通过将 AdminSDProtectFrequency 条目添加到拥有域的 PDC 模拟器 FSMO 角色的域控制器上的 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters 注册表项，可以在域级别覆盖默认的 SDPROP 执行周期。AdminSDProtectFrequency 将接受 60 到 7200 秒范围内的值。但是，覆盖不建议增加默认执行周期，预计会导致 PDC 仿真器上 CPU 利用率大幅增加，而降低执行频率会延长修改受保护对象的安全描述符的时间。坚持。）

执行 SDPROP 时，它会识别域的默认受保护对象集，然后递归地遍历每个对象的成员资格树，以识别受保护对象集的完整成员资格。 SDPROP将每个对象的安全描述符与权威安全描述符进行比较；如果不匹配，则对象的安全描述符将替换为权威安全描述符，并且对象的 AdminCount 属性的值将设置为 1。

事实上，专门创建专门的任务来执行这些检查似乎没有必要，但 Active Directory 的安全描述符传播并不是真正为解决此行为而设置的。虽然对对象的安全描述符或其可分辨名称的更新会导致 Active Directory 几乎立即传播任何关联的可继承访问控制列表更改（除非可分辨名称更改导致对象的新父级成为域的已删除对象容器），但组成员身份更改不会不要启动该过程。这意味着将对象添加到受保护组不会触发该过程，并且不能用于将权威安全描述符应用于受组成员身份更新影响的对象。

AdminCount 的限制

让我们回顾一下 AdminCount 属性的主要限制以及它们可能造成的误解。

SDPROP 按计划执行。

如上所述，默认情况下 SDPROP 任务每小时仅执行一次。因此，已添加到受保护组的帐户最多可能需要一个小时才能被 SDPROP 识别为受保护对象集的成员。这意味着，如果一个对象成为受保护对象的成员（直接或传递），并且在执行 SDPROP 之前删除该成员身份，则该对象将不会被标识为受保护对象，并且该对象的 AdminCount 属性的值将保持不变。

当 SDPROP 修改对象的安全描述符时，它会更新 AdminCount 属性。

这有什么大不了的？好吧，SDPROP 并不关心对象的 AdminCount 属性的值。如果 SDPROP 更新受保护对象的安全描述符，它会将 AdminCount 属性的值设置为 1。如果受保护对象的安全描述符与权威安全描述符匹配，则 SDPROP 将使受保护对象的 AdminCount 属性保持不变，无论其值如何。因此，更改或删除受保护对象的 AdminCount 属性的值可以有效地在简单的报告扫描中隐藏受保护对象。

SDPROP 仅查看受保护对象集的活动成员。

SDPROP 扫描从默认受保护对象集的成员开始，并迭代其成员资格。但是，SDPROP 会忽略不属于默认受保护对象集成员的高特权对象，并且它们的 AdminCount 属性值将保留为 。因此，不能依赖 AdminCount 属性来识别域中的所有高特权对象。

此外，一旦受保护对象从其继承受保护状态的组中删除，它随后将被 SDPROP 忽略，同时继续看起来与受保护对象完全相同。这是因为当对象成为受保护对象集的成员时，Active Directory 缺乏撤消 SDPROP 所做更改的机制；其 AdminCount 属性保持设置为 1（或其组成员身份更改之前的任何值）。更重要的是，对象的安全描述符也将保持不变，并将继续阻止来自对象父对象的安全继承。

SDPROP 不区分组类型。

Active Directory 组有两种类型：安全组和通讯组。安全组可以将权限传递给其成员，而通讯组则不能。虽然通过通讯组保护作为默认受保护对象的传递成员的对象可能看起来很奇怪（因此不会从默认受保护对象继承任何权限），但组的类别是可以更改的。由于更改组的类型会改变其向其成员授予特权的能力，因此 SDPROP 完全忽略组类别以防止这种行为被滥用。

概括

归根结底，AdminCount 属性只是一个标志。为了了解该标志可以告诉您什么，您还需要了解它无法告诉您什么。

您似乎可以通过运行以下命令来获取受 SDPROP 保护的对象的列表：

Get-ADObject -LDAPFilter "(adminCount=1)"

然而，此命令实际上告诉您的是哪些对象具有值为 1 的 AdminCount 属性。

准确识别受保护对象的唯一可靠方法是准确执行 SDPROP 的操作：识别域的默认受保护对象集并识别每个对象的完整成员资格。

Netwrix 如何提供帮助？

使用 Netwrix Active Directory 安全解决方案从头到尾保护您的 Active Directory。它将使您能够：

• 发现 Active Directory 中的安全风险并优先考虑缓解措施。
• 强化整个 IT 基础设施的安全配置。
• 及时检测并遏制高级威胁，例如 DCSync 和金票攻击。
• 使用自动响应选项立即响应已知威胁。
• 通过快速 Active Directory 恢复最大限度地减少业务中断。

常问问题

Active Directory 中的 AdminCount 属性是什么？

AdminCount 属性显示对象的 ACL 已被系统修改为更安全的设置，因为它属于管理组之一。

当我从受保护组中删除用户时，为什么 AdminCount 没有更改为 0 或“未设置”？

在 Windows 2000 开发早期，一项用户调查显示，一旦用户帐户的高权限被撤销，他们更愿意销毁该帐户，因为该帐户可能在其权限被删除之前构建了明确的后门。由于认为该帐户将被终止或禁用，因此 DC 不会删除 AdminCount 属性。