在我们的环境中，每个人有两个 AD 帐户，一个用户级帐户和一个管理员级帐户。我们的支持人员只能重置用户级帐户，这很好，但我不知道为什么。这是顶级域上的 ADUC 权限：
是什么原因导致他们无法重置管理员帐户？管理员帐户不属于任何全局管理员组（域管理员等）。
答案1
他们是否曾经是域管理员组的一部分？如果是这样，他们从 OU 继承权限的功能将被禁用，您必须手动重新激活它。
答案2
这是设计使然。
一般来说，较低级别的支持人员（甚至是二级特权账户）应该不是有能力重置更高层级管理员帐户的密码。这被视为潜在的特权升级。较低层级的管理员可以重置较高层级管理员的密码，获得帐户控制权并可能拥有网络。
为了防止这种情况发生，AD 有一个内置机制，以确保那些被视为高权限帐户的账户不会继承多余的委派。此机制涵盖的群组的完整列表可在此处找到：https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory#protected-groups
SDProp 进程通过将属性 adminCount 设置为 1 来标记这些组的递归成员的所有帐户。然后，每个帐户都禁用继承，并更改/更新 NTDS 权限以与 AdminSDHolder 对象上的 ACL 匹配。因此，每小时都会禁用继承，并将 ACL 重置为已知的良好基线。
此过程可确保任何受保护帐户的 ACL 不会偏离定义的基础 - 因此您不会意外地委托初级管理员重置域管理员密码的权限 - 或者您不会意外（永久）阻止管理员这样做的权限。
因此，如果您需要更改敏感/特权对象上的 ACL（尽管在这种情况下我建议不要这样做），则需要先更改 AdminSDHolder 对象上的 ACL，然后让权限流经 SDProp 进程。
一个问题是，SDProp 进程会将 adminCount 属性设置为 1；但是，没有相应的进程会清除该属性（默认为 null/empty）。因此，任何曾经拥有特权但不再拥有特权的帐户仍将受到此进程的影响。如果您发现自己处于这种情况，则适当的做法是清除该属性并重新启用对象的继承。