关于Active Directory环境中普通用户可重置其他用户密码的排查工具及解决方案咨询

看起来你遇到的这个问题确实挺头疼的——30-40条权限项里找哪条出问题，太费时间了。我给你分享几个实用的工具和排查思路，应该能帮你快速定位并解决：

一、权限排查工具推荐 #

• ADUC高级视图：先打开Active Directory Users and Computers，勾选顶部菜单栏的「查看」→「高级功能」。右键你的域根节点，选「属性」→「安全」→「高级」，这里能看到所有继承或直接设置的权限项。重点看那些「应用到」范围包含「用户对象」的条目，找有没有授予普通用户/域用户组「重置密码」权限的项。另外，对单个用户对象用「有效访问」标签时，记得在「权限」里专门勾选「重置密码」这个选项，不要只看笼统的权限。
• PowerShell命令：用Get-Acl "AD://DC=你的域名,DC=com" | Select-Object -ExpandProperty Access可以导出域根的所有访问控制项（ACE），然后你可以筛选包含重置密码权限的条目——重置密码对应的权限GUID是00299570-246d-11d0-a768-00aa006e0529，你可以加个过滤条件：Where-Object { $_.ObjectType -eq "00299570-246d-11d0-a768-00aa006e0529" }。另外，ActiveDirectory模块里的Get-ADPermission也能查，但输出需要稍微解析下。
• 微软AD Permissions Analyzer：这个官方工具简直是救星，能生成可视化的权限报告，直接帮你标出哪些用户/组拥有重置密码的权限，不用自己一条条核对，非常高效。

二、排查关键思路 #

1. 不要只盯着域根：权限可能是在某个OU层级设置的，然后继承到了用户对象，所以重点检查存放用户的OU的权限设置。
2. 检查嵌套组：有时候不是直接给域用户组授权，而是域用户属于某个被授权的嵌套组，你可以用Get-ADGroupMember -Identity "疑似授权组" -Recursive来确认嵌套关系。
3. 区分「重置密码」和「修改密码」：这两个权限是不同的，你要找的是「重置密码」（不需要知道旧密码），而用户自己改密码是「修改密码」（需要旧密码），别搞混了。

三、解决方案 #

1. 删除/修改违规权限：找到那条授予普通用户重置密码权限的ACE后，直接删除或者把权限主体改成授权的组（比如Helpdesk团队）。
2. 保留用户自改密码权限：默认情况下，用户通过「SELF」主体拥有修改自己密码的权限，这个一定要保留，别误删了。
3. 验证混合环境兼容性：因为你有密码回写的混合环境，修改权限后要确认AD Connect相关的服务账户仍拥有必要的密码回写权限，避免影响云同步。

四、注意事项 #

• 修改AD权限前，务必备份AD（比如用ntdsutil做快照，或者用Windows Server的备份功能），万一改坏了能快速恢复。
• 改完后一定要测试：找普通用户测试能不能重置他人密码（应该不行），能不能改自己密码（应该可以），同时验证密码回写功能正常。

备注：内容来源于stack exchange，提问作者Blai