最近遇到一个很典型的 AD 权限问题：
- 在某个 OU 上，给一个安全组委派了“重置密码”权限；
- 委派范围选择的是“后代用户对象”；
- 组里的账号去给其他用户改密码时，发现有些用户能改，有些用户不能改；
- 检查 OU 上的委派设置，看起来没有问题。
这类问题最容易让人怀疑“委派是不是没生效”，但实际排查下来，很多时候不是委派写错了，而是目标用户对象本身处于 AD 的特殊保护机制之下。
本文记录一下完整排查思路和处理方法。
一、现象：同一个委派组，有的用户能改密码，有的不行
同一个组、同一个 OU、同一套委派，结果却不一样，说明差异不在“组”上，而在“目标对象”上。先把范围缩小到具体用户，再看这些用户有什么共同点。
二、先别猜，直接看目标用户的“有效权限”
排查 AD 权限问题时，不要只看 OU 上委派了什么，而要看目标对象上实际生效了什么。
操作步骤：
- 打开“Active Directory 用户和计算机”；
- 开启“高级功能”；
- 找到无法改密码的用户，打开属性；
- 进入“安全” → “高级” → “有效权限”；
- 选择你委派的那个组或账号；
- 查看“重置密码”是否被勾选。
如果“重置密码”没有生效，继续检查两件事：
- 该用户的“安全” → “高级”中，“包括可从该对象的父项继承的权限”是否被取消勾选；
- 是否存在显式的 “拒绝” 权限条目，覆盖了允许权限。
如果继承被中断，那么你在 OU 上委派的“后代用户对象”权限，自然无法传递到这个用户身上。
三、最常见根因：用户被 AdminSDHolder 保护了
如果你发现不能改密码的用户有一个共同特征，那大概率是 AdminSDHolder 保护机制在起作用。
AD 中有一组“受保护账户”，包括但不限于：
- Domain Admins
- Enterprise Admins
- Schema Admins
- Account Operators
- Backup Operators
- Print Operators
- Server Operators
- Domain Controllers
- 内置 Administrator 账户等
注意：嵌套组成员也会受影响。即使用户不是直接成员，只要通过组嵌套间接属于受保护组，也可能被保护。
当账户受到保护时，会发生两件事：
- 权限继承被禁用：你在 OU 上委派的权限不会继承到该用户对象；
- SDProp 定期覆盖权限：PDC 模拟器上的后台任务默认约每 60 分钟运行一次，用
AdminSDHolder容器上的 ACL 覆盖受保护对象的权限。
委派权限沿 OU 向下继承，但在被保护的对象上会被截断。
判断方法：
打开用户属性 → “属性编辑器” → 查看 adminCount 属性。
如果值为 1，说明该账户当前或曾经处于受保护状态。
四、为什么移除了 Domain Admins，还是不能改密码？
这是很多人会踩的坑。
把用户从 Domain Admins 中移除后，账户的 adminCount 不会自动清零，权限继承也不会自动恢复。
原因在于：adminCount 更像一个“曾经是特权账户”的历史标记。SDProp 负责施加保护，但不会因为你移除了特权组就自动解除保护。微软的设计就是如此：清除 adminCount 和恢复继承都需要手动操作。
所以会出现这种情况：
- 用户已经不在 Domain Admins 里；
- 但
adminCount仍然是 1； - 用户对象上的继承仍然是禁用状态；
- OU 上的委派权限仍然到不了这个用户；
- 所以还是不能改密码。
五、正确处理步骤
第一步：确认账户已彻底脱离所有受保护组
除了 Domain Admins，还要检查是否通过嵌套成员身份间接属于其他受保护组。
如果账户仍然在某个受保护组里，即使你清除了 adminCount，下一次 SDProp 运行后也会重新设回 1，并再次禁用继承。
第二步：清除 adminCount
图形界面：
- 开启 ADUC 的“高级功能”；
- 打开用户属性；
- 进入“属性编辑器”；
- 找到
adminCount； - 点击“清除”，确定。
PowerShell：
Set-ADUser -Identity "用户名" -Clear adminCount查看当前值：
Get-ADUser -Identity "用户名" -Properties adminCount |
Select-Object Name, adminCount第三步：重新启用权限继承
打开该用户属性 → “安全” → “高级” → 勾选：
包括可从该对象的父项继承的权限
保存后，OU 上委派的“重置密码”权限才会重新通过继承生效。
第四步：验证并测试
再次打开“有效权限”，选择委派组，确认“重置密码”已经勾选。然后用委派组中的账号实际测试改密码。
六、如果目标用户不是受保护账户
如果 adminCount 不是 1，但仍然不能改密码，可以按下面顺序检查：
- 用户对象是否取消了“包括可从父项继承的权限”；
- 是否存在显式“拒绝”ACE；
- 委派权限是否完整授予了“重设密码”扩展权限；
- 委派范围是否确实是“后代用户对象”；
- 目标用户是否位于委派 OU 之外。
这里要区分两个容易混淆的扩展权限：
- 重设密码（User-Force-Change-Password）：ADUC 里“重置密码”实际授予的是它，GUID 为
00299570-246d-11d0-a768-00aa006e0529； - 更改密码（User-Change-Password）：要求调用方知道旧密码，GUID 为
ab721a53-1e2f-11d0-9819-00aa0040529b。
很多“看着委派了却改不了”的案例，就是把“更改密码”当成了“重置密码”。在有效权限中确认真正到达目标对象的是哪一个。
七、快速排查清单
遇到“有些用户能改密码，有些不能”时，可以按这个顺序查：
- 看不能改的用户
adminCount是否为 1； - 在目标用户上查看委派组的“有效权限”；
- 检查目标用户是否取消了权限继承；
- 检查是否存在“拒绝”ACE；
- 检查用户是否通过嵌套组属于受保护组；
- 受保护账户 → 清除
adminCount+ 恢复继承； - 普通账户 → 恢复继承或修正委派权限。
八、总结
这个问题的核心不是“委派没写对”，而是 AD 的 AdminSDHolder 保护机制。
adminCount = 1 表示账户当前或曾经受到保护。把用户从 Domain Admins 等特权组移除后，AD 不会自动清除 adminCount，也不会自动恢复权限继承。必须手动清除 adminCount，并重新勾选“包括可从父项继承的权限”，OU 上的委派权限才会重新生效。
如果确实需要让某个委派组重置受保护账户的密码，另一种方案是在 AdminSDHolder 容器上授权，但这会让该组具备重置所有受保护特权账户密码的能力，安全影响较大，生产环境务必谨慎评估。
操作提醒：批量清除
adminCount或恢复继承前，先确认目标对象上是否有刻意配置的显式权限条目，避免改变现有有效访问权限。