ad权限映射本质是用户、角色（组）、资源通过安全主体与acl精准关联；须按职能建功能组、权限绑定自定义ou、ntfs分三层控制，并定期验证有效性。
ad环境中的访问权限映射，本质是把人（用户）、角色（组）、资源（对象或文件）三者通过安全主体与acl规则精准关联。关键不在“谁直接有权限”，而在于“谁通过什么组、在什么范围、对什么属性拥有什么操作”。高效方案必须避开直授用户权限、绕过ou边界乱委派、忽略继承冲突这三大坑。
按职能建组，不按部门建组
很多管理员习惯为每个部门建一个“Dept-IT”“Dept-HR”组并直接赋权，结果导致权限泛滥、复用困难、审计混乱。正确做法是按操作职责建功能组，例如：
- PasswordReset-Delegated：仅含重置密码+强制改密权限，委派给服务台人员
- ComputerJoin-Allowed：仅含“将计算机加入域”权限，授予桌面运维组
- UserProvision-Standard：可创建用户、写入基本属性（姓名、邮箱、电话），但不能设密码或加组
这些组可跨部门复用，也便于后期权限回收或审计——查一个组，就知所有相关操作边界。
权限绑定到OU，不是绑定到容器
默认的Computers和Users容器不支持委派向导，且其ACL受adminSDHolder机制保护，强行修改易被覆盖。所有委派操作应基于自定义OU（如OU=Workstations,DC=corp,DC=local），并在OU上启用“阻止继承”后手动添加所需ACE。这样既避免内置容器的意外干扰，又确保权限范围清晰可控。
NTFS共享权限分层控制
文件服务器上的权限不是只设一次就完事。推荐采用三层结构：
- 共享级（Share Permission）：统一设为Everyone - Read或Authenticated Users - Change，仅作网络入口控制
- NTFS级（DACL）：绑定AD安全组，例如GRP-Finance-RW拥有“修改”权限，GRP-Finance-RO仅“读取和执行”
- 属性级（可选）：对敏感文件夹启用“加密文件系统（EFS）”或通过GPO限制复制/打印，补充逻辑访问之外的防护
特别注意：若NTFS权限中存在“拒绝”项，它会优先于所有“允许”，且无法被子对象继承覆盖——慎用拒绝，宁可删组也不加拒绝。
定期验证权限映射有效性
权限不是设完就静态存在。建议每季度执行三项检查：
- 用Get-ADPrincipalGroupMembership确认关键用户是否仍在预期组中，有无冗余成员关系
- 运行icacls \servershare /T导出实际NTFS权限，比对是否与AD组策略一致
- 抽查5–10个典型用户，模拟其登录后能否完成岗位必需操作（如HR能否编辑员工信息、IT能否重置指定OU内账户）
发现偏差立即回溯委派路径，修正组成员或OU权限设置，而非临时加权限补漏。
