OU本身不直接实现权限委派，需通过ACL显式配置；右键“委派控制”不可见任务常见因继承禁用、管理员缺Write权限或高级任务未勾选“包括所有子对象类型”；重置密码与解锁账户需分别委派Reset Password和Write lockoutTime权限。
ou（组织单位）本身不直接“实现权限委派”，它只是active directory中一个容器对象；真正的权限控制必须通过acl（访问控制列表）在ou上显式配置delegation of control，否则新建的ou默认没有任何管理权限继承或自动委派。
为什么在OU上右键“委派控制”却看不到想分配的任务？
常见原因是目标OU未启用“防止对象被意外删除”以外的继承策略，或管理员账户缺乏对父容器的Write权限，导致向该OU写入ACE失败。另外，AD默认隐藏部分高级任务（如重置密码、修改组成员），需勾选“包括所有子对象类型”并手动展开选择。
- 确保当前登录账号对目标OU具有
Manage auditing and security log或至少Full Control（通常需Domain Admin或Enterprise Admin权限才能首次开启委派） - 检查OU属性中的
Security选项卡 → 点击Advanced→ 确认Inherit from parent已启用（除非刻意隔离） - 运行
dsacls "OU=Sales,DC=contoso,DC=com"验证当前ACL是否可读；若报错Access is denied，说明无基础读取权限，委派向导无法加载可用任务
用“委派控制向导”分配重置密码和解锁账户时要注意什么？
这两个操作看似简单，但实际依赖两个不同权限位：Reset Password（允许调用Set-ADAccountPassword）和Change Password（允许用户自己改密），而“解锁账户”对应的是Write lockoutTime属性。向导中若只勾选“重置密码”，不会自动赋予解锁能力。
- 必须在向导第二步明确勾选
Reset user passwords and force password change at next logon和Read and write lockoutTime（后者不在默认任务列表里，需点Custom task to delegate→Only the following objects in the folder→ 勾选User objects→ 在下方权限列表中单独勾选Write lockoutTime） - 如果目标用户启用了
Smart Card Logon，还需额外委派Write pkcs12，否则重置后无法生成新证书私钥 - 执行后建议用普通域用户测试：
Get-ADUser -Identity testuser -Properties LockedOut | Select LockedOut确认能读，再用Unlock-ADAccount -Identity testuser验证是否成功
脚本化委派：用PowerShell替代图形向导分配“管理组成员”权限
图形向导无法批量处理上百个OU，且不记录操作日志；用dsacls或Set-ADObject配合SecurityDescriptor更可控，但容易因GUID拼写错误或继承标志误设导致权限失效。
- 推荐使用
Add-ADPermission（AD模块v2.0+）：Add-ADPermission -Identity "OU=Dev,DC=contoso,DC=com" -User "CONTOSO\HelpDesk" -AccessRights ReadProperty, WriteProperty -Properties "member" -InheritanceType "All"
- 注意
-Properties "member"必须小写，且不能写成"Member"或"members"，AD Schema中该属性名是全小写 - 若需同时允许添加/删除组成员并查看完整成员列表，还需追加
-ExtendedRights "Send As","Receive As"——但这已超出纯组管理范畴，属于邮件权限，容易误配 - 执行前务必用
Get-ADPermission -Identity "OU=Dev,DC=contoso,DC=com" -User "CONTOSO\HelpDesk"确认旧权限未冲突
真正难的不是点几下鼠标完成委派，而是理解每个复选框背后对应的LDAPDisplayName属性、rightGuid和继承范围；生产环境里一个Deny ACE写错位置，就可能让整个OU的用户对象突然无法被任何非管理员账户读取。
