Active Directory 委派最佳实践

据 The IBM X-Force 2025 Threat Intelligence Index 统计，约 30% 的入侵始于对有效账户的滥用。由于 Active Directory 内置的特权组会为其中的每个账户授予整个域的读写权限，因此这些凭据的危险性被显著放大。

如果将负责日常密码重置的帮助台技术人员加入 Domain Admins，那么无论其实际工作内容是什么，此人都将拥有与维护 AD 基础设施的工程师相同的访问权限。

Active Directory 委派通过在 OU（组织单位）级别分配与任务相关的权限来弥合这种不匹配，而不是通过特权组成员身份来实现。

本指南涵盖如何构建 AD 委派模型、如何使用“Delegation of Control Wizard（委派控制向导）”应用委派权限，以及如何通过运营实践防止委派权限逐步累积为未经审查的访问。

什么是 Active Directory 委派？

Active Directory 委派允许管理员在不将用户或组添加到诸如 Domain Admins 或 Account Operators 之类的特权组的情况下，向用户或组授予与任务相关的提升权限。

这些组拥有完整的、覆盖整个域的权限：只要账号属于 Domain Admins，就可以读取和写入目录中的所有对象，而不管实际工作需求有多么狭窄。

Active Directory 委派 会将访问控制项（ACE）应用到特定组织单元（OU）或对象类，从而将权限范围严格限定为该角色所需的内容。

被委派在某个 OU 内重置密码的帮助台技术人员，只在该范围内获得该权限。该权限不会扩展到其他 OU，且该帐户不会出现在任何特权组中。

如何制定 AD 委派模型

委派模型定义了环境中的管理角色、每个角色拥有的权限，以及用于限定这些权限范围的 OU 结构。没有这样的模型，委派权限会非正式地不断累积，最终变得无法审计。

步骤 1：创建角色

首先定义两层 管理员角色：服务管理员和数据管理员。

1. 服务管理员负责管理 Active Directory 基础设施本身。该层包括 Enterprise Admins、Domain Admins，以及任何负责维护 AD 复制、域服务或关键系统所使用的服务账号的账户。该层的每位成员都可能影响域中的所有对象，因此请将其规模控制在环境所允许的最小范围内。
2. 数据管理员在不触及底层基础设施的情况下管理目录中的对象。请按范围对该层进行组织：

• 第 1 层（区域管理员）： 在指定的地理区域或业务单元内管理用户和组对象。
• 第 2 层（部门管理员）： 在特定部门或职能范围内管理用户帐户。
• 第 3 层（服务台）： 在指定的 OU 内执行有限的操作，例如重置密码和解锁账户。

保持角色数量较少。每新增一个角色，都会产生一组必须进行记录、分配和复核的权限。角色激增是成熟 AD 环境中无法管控的访问不断累积的主要原因。

步骤 2：分配职责

对每个角色，记录其适用哪些权限、适用于哪些对象类别，以及适用于哪些 OU。将每项分配映射到三个维度：

1. 频率：该角色执行该任务的频次；这决定复核节奏以及是否需要使用自动化工具。
2. 重要性：该任务是业务关键还是例行的管理工作，会影响首次授权所需的审批门槛。
3. 难度：该任务是否需要技术判断，还是可以由通才完成；这会影响培训和入职（onboarding）的要求。

对常见操作使用标准的 Active Directory 访问控制列表（ACL），对例如 Force Change Password 或 Apply Group Policy 之类的操作使用“扩展权限（Extended Rights）”。在进行委派时，记录每一项授权；未记录的权限在访问审查和审计中将不可见。

步骤 3：定义 OU 安全模型

在应用任何权限之前，先设计一个 OU 层级结构，以反映你的委派边界。将特权账户和管理账户放在与它们所管理的对象分开的 OU 中：例如，将 Domain Admin 账户存储在与其所管理用户相同的 OU 中，可能会通过 OU 级别的 privilege escalation 被瞄准。

在顶层创建与您的管理模型相匹配的 OU，无论其是按地域、组织还是功能来划分。在每个顶层 OU 内，再创建与数据管理范围相对应的子 OU。

为每个范围创建专用的安全组，并将委派权限应用到该组，而不是应用到单个账号。

这种结构能够限制基于继承的权限升级：在子 OU 级别委派的管理员，除非在该级别明确授予了权限，否则无法影响父级或同级 OU 中的对象。组织模型发生变化时，请随时审查 OU 结构。

如何在 Active Directory 中委派控制权限

Active Directory Users and Computers (ADUC) 中的 Delegation of Control Wizard 是应用委派权限的主要工具。它会将 ACL 条目直接写入你选择的 OU 或容器，并创建一个权限分配，之后可通过该 OU 的 Security（安全）选项卡进行查看。

步骤 1：打开 Delegation of Control Wizard

在 ADUC 中，如果 View 菜单下的 Advanced Features 尚未启用，请先启用它。导航到你要应用委派的 OU，右键单击该 OU，然后选择 "Delegate Control"。向导只会将权限应用到所选 OU 及其包含的内容；其父级 OU 不会受到影响。

步骤 2：选择用户或组

在 Users or Groups（用户或组）窗格中，添加表示接收委派权限的管理员角色的 security group。

基于组的分配允许你通过修改成员身份来添加或移除访问权限，而不是直接修改 OU 的 ACL，从而保持权限结构可审计且可回滚。

分配给单个账户的权限会创建 ACE，这些 ACE 会在角色变更和离职之后持续存在，除非有人手动将其移除。

第 3 步：选择要委派的任务

对于创建或删除用户帐户、重置密码、读取用户信息或管理组成员身份等标准操作，选择 "委派以下常用任务"。

对于不在预定义列表中的权限（包括 Force Change Password 或 Apply Group Policy 等扩展权限），请选择 "创建要委派的自定义任务"。

第 4 步：指定委派范围

对于自定义任务，请定义委派适用于哪些对象类（用户对象、计算机对象或组对象），以及权限是应用到 OU 本身、OU 内部的对象，还是两者都适用。将范围限制到角色的文档化职责所要求的最小程度。

第 5 步：完成并验证

向导完成后，通过在 ADUC 中右键单击 OU，选择“属性”，并打开“安全”选项卡来验证结果。确认预期的 ACE 已以正确的权限和范围列出。

通过以委派组的成员身份登录，并尝试被允许和被排除的操作来进行测试，以确认委派完全按预期工作。

Active Directory 委派的最佳实践

委派模型以及 Delegation of Control Wizard 提供了技术基础。随着环境和组织不断发展，这些做法能够维护该基础的安全性。

在分配时记录每一次委派

在每次运行 Delegation of Control Wizard 之后、在使用该访问权限之前，将 OU、接收权限的组、授予的具体权限以及业务理由记录到集中式访问注册表中。

该向导不会生成自己的日志；它会在不记录操作、审批人或授予背后的理由的情况下，将 ACE 应用到 OU 的安全描述符。未记录的 ACE 在访问审查和审计期间会变得“看不见”，而在人员变动之后，它们也会失去唯一的上下文来源。

电子表格、ITSM 工单或专用的 IAM 系统都可以用于此目的。关键在于：在访问开始使用之前应已具备相应文档，并且文档应涵盖业务理由，而不仅仅是技术范围。

将委派权限分配给安全组，而不是单个账户

当权限被分配给单个账户时，即使该人员离开组织、变更角色或禁用其账户，权限仍会在 OU 的 ACL 中保持不变。

ACE 仍会与账户的 SID 保持绑定状态，不会在标准的离职/离场（offboarding）步骤中自动清除。

分配给安全组的权限会在 offboarding 过程中通过将账户从该组中移除来撤销。这符合标准的 IAM 工作流，能够形成清晰的审计追踪，并且随着团队的成长或变动具备可扩展性。

组成员身份的变更会在 Security 日志中生成事件；如果要在 OUs 上直接修改 ACE，则需要特定的审计策略设置，才能产生等效的证据。

将最小特权原则应用于每一次委派

只授予每个角色完成其已记录任务所需的权限：使用最小的 OU 范围，并选择工作所需的最具体的权限集。

应用于委派的 principle of least privilege 意味着将权限范围限定为相关的子 OU，而不是父 OU；并选择特定的扩展权限，而不是广泛的写入访问权限。它还要求将复合任务拆分为独立的委派，而不是授予更宽泛的权限来覆盖多种情况。

应用委派后，通过以委派组的成员身份登录进行测试：确认只有预期的操作成功，而被排除的操作失败。

至少每季度审查一次已委派的权限

安排定期的访问审查：枚举敏感 OU 上的 ACE，并确认每一条记录是否仍然符合当前的业务需求。

在目标 OU 上打开“安全(Security)”选项卡（仅当在 ADUC 中启用了“高级功能(Advanced Features)”时才会显示），并检查显式和继承的条目。删除任何属于没有活动成员或没有文档化用途的组的 ACE。

在 Active Directory 中检测已委派的权限 在大规模场景下需要使用 PowerShell 或专门构建的工具；原生 ADUC 界面只能显示当前的权限状态，但不会记录 ACE 何时创建以及由谁创建。

按季度进行审查可以在权限漂移累积成未文档化的访问积压之前发现问题，从而避免环境变得难以审计。

对特权操作使用单独的账号

要求管理员在执行委派任务时使用专用的管理员账号，并且该账号应与他们用于电子邮件和日常工作的账号分开。

标准账号负责处理日常活动，并承担普通用户凭据的风险特征；管理员账号仅在需要执行高权限操作时才启用，并且不应拥有对电子邮件、网页浏览或任何处理不受信任内容的工作站的访问权限。

privileged account management 策略将管理员账号与日常使用的凭据分离，是对基于凭据的横向移动最有效的控制措施之一。

权限范围隔离能够限制攻击者通过攻破单个凭据所能获得的能力，并使特权账号活动能够与日常用户行为分离进行审计。

为高权限委派迁移到按需/即时（just-in-time）的访问方式

对于最高权限的角色，彻底取消长期委派访问，并用 just-in-time access 替代：仅在已批准的任务执行期间授予更高权限；任务结束后系统会自动撤销权限。

长期委派访问意味着：无论该账号实际多么少被使用，只要它拥有这些权限，就会因凭据盗用、网络钓鱼或横向移动而始终处于暴露状态。

按需/即时（just-in-time）的访问方式会压缩“被泄露的凭据可利用委派权限”的时间窗口；同时减少季度审查必须覆盖的 ACE 影响范围，并生成审批与会话记录，从而增强受监管环境中的审计证据。

委派特定权限时的注意事项

以下每种权限类型都可能带来安全影响，而“Delegation of Control Wizard”并不会显示这些影响。

重置密码和解锁账号

首先检查 OU 边界。被委派在包含 Domain Admin 账户或 服务帐户 的 OU 中重置密码的角色，可能存在通往 tier-zero 访问的凭据重置路径；权限范围在技术上是正确的，但 OU 范围并不正确。在应用委派之前，请验证该 OU 仅包含标准用户账户。

组成员管理

在应用此委派之前，先审计适用于受保护成员（Domain Admins、Enterprise Admins、Account Operators）的组。

Active Directory 的 SDProp 进程每 60 分钟会将 AdminSDHolder ACE 重新应用到这些帐户上，从而悄无声息地覆盖自定义委派。

对这些帐户应用的任何委派都不会生效；仅仅尝试应用它就是需要调查的信号。

组策略对象（Group Policy Object）权限

组策略委派分为三种权限（创建、编辑和链接），默认情况下不应将链接权限与其他权限一并授予。

将 GPO 进行链接操作后，其设置会立即应用到目标 OU 及其所有子对象。请将“链接权限”视为一项独立的、需要提升权限并获得自身批准的授权。

计算机账户管理

在委派计算机账户管理之前，将 ms-DS-MachineAccountQuota 设置为零。其默认值为 10，这会让任何已认证用户在无需任何委派的情况下将计算机加入域。

另外请注意，标准的计算机账户委派包含对 SPN 的写入权限；除非该角色明确需要，否则不要把该权限包含在授权中。因为拥有 SPN 写入权限会带来 Kerberoasting 风险。

Kerberos 身份验证委派设置

Kerberos 委派是一个独立的属性，不同于 Active Directory 的“控制权委派”；它不会通过“Delegation of Control Wizard”设置，因此在进行委派审查时很容易被忽略。

在审计委派账户时，检查是否有任何账户同时具有“unconstrained Kerberos delegation（非约束性 Kerberos 委派）”。如果是，请无论该账户所属 OU 为何，都将其视为 Tier 0，因为一旦使用非约束性委派的服务被攻破，它就会暴露域控制器传递给它的每一个 TGT。

Netwrix 如何帮助进行 Active Directory 委派

Active Directory 委派会将控制权分散到整个环境中；如果这些分散的权限未经审查或未被记录，就可能形成潜在漏洞。

角色会随着时间积累权限，组会逐渐获得它们不应持有的成员，而为特定项目应用的 ACE 会在该项目结束很久之后仍保留在对应的 OU 上。

如果无法持续洞察权限变更，安全团队就无法维持委派模型应当强制执行的访问态势。

治理委派访问需要：实时检测权限变更、在其变得可被利用之前识别偏差（drift），并为访问审查与合规审计生成可辩护的证据。

Netwrix Auditor 实时监控 AD 权限变更，并生成支持访问审查与监管证据的“变更前后”审计追踪记录。

Netwrix Access Analyzer 通过嵌套组和 OU 继承来映射实际访问权限，从而在其成为审计发现之前暴露过度或已过期的委派权限。

二者合力为安全团队提供持续的可视性：既能了解正在发生的变更，也能掌握这些变更所带来的访问状态。

请求演示 了解 Netwrix 如何帮助您管理 Active Directory 委派，检测权限漂移（permission drift），并维护可辩护的审计追踪（audit trail）。