Active Directory 无法直接实现标准 RBAC，因其原生无角色抽象层，仅支持 user、group、OU 和 ACL；所谓“AD 中的 RBAC”实为用 security group 模拟角色，结合组策略与权限委派实现权限收敛。
active directory 中无法直接实现标准 rbac（基于角色的访问控制），因为 ad 原生不支持“角色”抽象层——它只有 user、group、ou 和 acl。所谓“ad 中的 rbac”，本质是用 security group 模拟角色，再通过组策略和权限委派完成权限收敛。
为什么不能直接用 AD 内置角色做最小权限
AD 自带的内置组（如 Domain Admins、Account Operators）粒度太粗，且多数绑定高危权限（例如 Account Operators 可重置任意用户密码、创建/删除账号）。一旦成员误操作或账户泄露，影响面极大。
常见错误现象：Account Operators 组被用来批量管理普通员工账号，结果某次误删导致 200+ 账户丢失；或为方便运维，把临时外包人员加进 Server Operators，结果其可任意重启域控服务。
- AD 没有“角色继承”“权限模板”“条件访问策略”等现代 IAM 能力
- 所有权限最终都落到
ACL上，而 ACL 是对象级（如某个 OU 下的user对象），不是角色级 - 内置组权限不可拆分、不可审计变更历史（除非启用详细 SACL + 审核策略）
用安全组模拟角色：命名、范围与生命周期
必须放弃“一个组管一类人”的懒政思维。真实有效的做法是：按“职责动作”建组，而非按“人员类型”建组。例如不建 Finance-Users，而是建 Finance-ResetPassword-SelfOnly、Finance-UnlockAccount-InHR-OU。
实操建议：
- 组名必须含动词 + 作用域 + 限制条件，如
HelpDesk-ModifyPhone-UserObjects-In-OU-HR - 全部使用
security group（非distribution group），作用域优先选Global（跨域复用）或Universal（多域环境），避免Domain Local（仅限本域本地资源授权） - 禁用嵌套超过 2 层的组（AD 查找组成员时会递归展开，影响登录慢、Kerberos 票据超长失败）
- 所有组必须配
description字段，写明用途、审批人、到期时间（例如：用于 HR 部门自助重置密码，有效期至 2025-12-31，审批人：hr-sec@company.com）
权限委派：只给 OU 下特定属性，别碰整个对象
在 OU 上右键 → “委派控制”只是图形界面快捷方式，背后仍是修改 ACL。默认向导会给整个 user 对象的完全控制权，这是最大风险点。
正确做法是手动编辑 ACL，只勾选具体需要的权限项：
- 要允许重置密码 → 勾选
Reset password和Read pwdLastSet（否则用户无法判断是否已重置） - 要允许修改电话号码 → 勾选
Write telephoneNumber，而不是Write all properties - 禁止勾选
Full control、Delete、Change password（该权限允许用户改自己密码，但不应由委派组授予） - 若需限制仅对某类用户生效（如只对
department=HR的用户），需配合Attribute-based filtering（Windows Server 2016+ 支持）或脚本定期清理组成员
验证与维护：别让组变成权限黑洞
90% 的 AD 权限失控，不是因为初始设计错，而是没人定期清理。一个没被审计过的 security group，半年后往往已混入离职人员、临时权限未回收、甚至测试账号。
必须落地的三件事：
- 用
Get-ADGroupMember+Get-ADUser -Filter {Enabled -eq $false}每月跑一次检查，自动输出失效成员报告 - 对所有委派权限运行
Get-Acl "AD:\OU=HR,DC=corp,DC=local" | fl，确认无GenericAll或WriteDacl权限残留 - 任何新权限申请，必须附带最小化说明（例如：“只需修改
ipPhone属性，不需要physicalDeliveryOfficeName”），并走 ITSM 工单留痕
最常被忽略的一点：Administrators 组在域控制器上的本地权限，仍可能绕过所有 OU 委派。只要有人进了这个组，就等于拿到域内最高权限——所以 Administrators 组成员必须比 Domain Admins 更少、更严控。
