支持人员可以重置部分用户密码，但不能重置全部？

Question

在我们的环境中，每人有两个 AD 帐户，一个用户级帐户和一个管理员级帐户。我们的支持人员只能重置用户级别帐户，这很好，但我不明白为什么。这是顶级域的 ADUC 权限：

是什么导致他们无法重置管理员帐户？管理员帐户不属于任何全局管理员组（域管理员等）。

Answer 1

他们有可能曾经是域管理员组的成员吗？如果是这样，来自 OU 的权限继承将被禁用，您必须手动重新激活它。

Answer 2

这是设计使然。

一般来说，较低层的支持人员（甚至二级特权帐户）不应该重置较高级别管理帐户密码的能力。这被视为潜在的特权升级。较低级别的管理员可以重置较高级别管理员的密码，获得帐户的控制权并可能拥有网络。

为了防止这种情况，AD 有一个内置机制来确保杂散委托不会被被视为高特权帐户的帐户继承。该机制涵盖的群体的完整列表可以在这里找到： https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c --活动目录中的受保护帐户和组#受保护组

SDProp 进程通过将属性 adminCount 设置为值 1 来标记属于这些组的递归成员的所有帐户。然后，每个帐户都禁用继承，并更改/更新 NTDS 权限以与 AdminSDHolder 对象上的 ACL 匹配。因此，每小时都会禁用继承，并且 ACL 会重置为已知的良好基线。

此过程可确保任何受保护帐户的 ACL 不会偏离定义的基础 - 因此您不会意外地委托初级管理员重置域管理员密码的能力 - 或者您不会意外地（永久地） ）阻止管理员访问以执行此操作。

因此，如果您需要更改敏感/特权对象上的 ACL（尽管在这种情况下我建议不要这样做），您需要首先更改 AdminSDHolder 对象上的 ACL，然后让权限流经 SDProp 进程。

一个问题是，SDProp 进程会将 adminCount 属性设置为 1；但是，没有相应的进程可以清除该属性（默认为 null/empty）。因此，任何曾经享有特权但不再享有特权的帐户仍将受到此过程的影响。如果您发现自己处于这种情况，适当的操作过程是清除该属性并重新启用对象的继承。