道歉，如果我没有find类似于我的问题，但我已经搜查诚实！
首先，我们对活动目录的安全性采取了默认组方法。 这一直非常成功。 然而，我们有一个错误熊，导致所有高级pipe理员在现场感到沮丧，因为他们需要请求另一个pipe理员更改他们的密码。 这不是我们想要的理想，也不知道是否有其他人反对这个问题。
这里的重要信息是我们正在使用terminal服务来远程数据中心，并使用服务器上的用户和计算机来重置密码。
另外，我还发现将用户放在Enterprise Admins组中可以更改密码。 但是我不能为我的生活锻炼什么acl / dacl来添加/更改，以便使我们的组在没有添加到用户的企业pipe理员angular色的情况下运行。
您遇到了安全描述符传播器（SDPROP）的威力和麻烦。
为了保护“关键对象”，Active Directory尝试跟踪属于一个或多个受保护组的成员的所有对象。 这些包括：
Account Operators Administrators Backup Operators Domain Admins Domain Controllers Enterprise Admins Print Operators Read-only Domain Controllers Schema Admins Server Operators
所有属于这些组的成员帐户都将自动拥有一个名为AdminCount的属性，其值为1 – 如果您在用户仍然是其中一个受保护组的成员时取消设置此属性，它将很快重新出现。
其目的是确保这些对象不能让对象的ACL被过度拧使它们在function上“破坏”（试图想象一个恶意的共同域pipe理员试图剥夺你的pipe理员帐户上的所有权利）。
为了维护关键对象的ACL，所有Active Directory默认命名上下文分区中都存在名为AdminSDHolder的引用对象。
在固定的时间间隔内，SDPROP调用本地DSA上的FixUpInheritance例程。 FixUpInheritance ， FixUpInheritance例程检查属性AdminCount所有对象，并将名为AdminSDHolder的引用对象的ACL应用于关键对象。
除非帐户本身已经通过身份validation并具有Enterprise Admin组成员资格，否则由于此特定权限的实现方式，此ACL-“修复”具有剥离“更改密码”权限的用户帐户的恼人副作用。 Active Directory用户和计算机mmc甚至可能会显示“用户无法更改密码”选项作为未选中，即使它仍然不能自行工作。
要testing这是否实际上是怎么回事，请尝试以下操作：
dsa.msc ） 现在testing用户是否可以更改密码。
为了testingSDPROP实际上是这种行为的原因，强制FixUpInheritance例程运行（在这里使用PowerShell）：
$RootDSE = [ADSI]"LDAP://RootDSE" $RootDSE.Put("fixupInheritance",1) $RootDSE.SetInfo()
确保使用pipe理凭据运行此命令
如果用户在运行FixUpInheritance后不再能够更改密码，则SDPROP是罪魁祸首。
无论如何，这里真正的问题是平等对待正规账户和特权账户的做法。
每个拥有pipe理权限的人（例如任何受保护组织的成员）都应该维护2个账户 – 一个是常规的，没有任何受保护的组成员，还有一个pipe理员帐号用于pipe理工作，而不是其他任何事项。
阅读更多关于这个例程，这有时是奇怪的效果：
AdminSDHolder，受保护的组和SDPROP – TechNet Magazine 2009