A-G-DL-P是微软推荐的AD权限管理命名约定，通过Account→Global Group→Domain Local Group→Permissions四层隔离实现权限可追溯、易审计、防越权。
什么是A-G-DL-P，它解决什么实际问题
域组嵌套策略a-g-dl-p不是某种技术标准，而是微软推荐的、用于控制权限分配路径的命名约定，核心目标是让权限管理可追溯、易审计、不越权。当你在ad中给100个用户分配对某个文件服务器共享文件夹的读写权限时，直接把用户加进权限组（比如fileserver-editors）看似简单，但一旦用户跨部门调动、权限需批量调整或发生安全审计，就会发现：谁在哪个组里？这个组到底能访问什么？有没有循环嵌套或隐性提权？全靠人工翻查。a-g-dl-p通过强制分层，把“谁”（account）、“角色”（global group）、“资源访问范围”（domain local group）、“权限落地点”（permission）四者物理隔离，切断任意两点之间的直连。
四个字母对应的实际组类型与创建要点
必须严格按字母顺序创建和使用，不能跳过或颠倒：
-
A（Accounts）：指具体用户或计算机对象，不是组。它们只被加入
Global Group，绝不直接加进Domain Local Group或直接赋予权限 -
G（Global Group）：作用域为本域，只能包含本域
User或Computer（即A），不能跨域添加用户，也不能包含其他组。命名建议带业务含义，如G-Sales-Users -
DL（Domain Local Group）：作用域为本域，可包含本域G组、其他域的G组（跨域场景）、甚至外部域的用户（不推荐）。它是唯一能被赋予NTFS/Share/Exchange等资源权限的组类型。命名应体现资源，如
DL-FS-Reports-Write -
P（Permissions）：这不是一种组，而是指在文件系统、SQL Server角色、Exchange收件人策略等位置实际配置的权限条目。它只引用
DL组，不引用G或A
为什么不能用G组直接赋予权限，常见错误现象
最常踩的坑是：建了个G-App-Admins，然后直接在IIS管理器里把它加进“Administrators”角色，或者在NTFS安全选项卡里给它勾选“Full control”。这会导致两个后果：
- 跨域失效：
Global Group无法被其他域识别，当该应用部署在另一域的服务器上时，权限完全不生效 - 权限扩散失控：G组成员变动后，所有依赖它的资源权限会同步变化，但你根本不知道哪些资源做了这种直连——因为
Get-ADGroupMember查不到它在哪被用了，dsa.msc里也看不到权限引用关系 - 组策略处理延迟：G组成员变更后，客户端可能要等下次登录或gpupdate才刷新token，而DL组权限在访问资源时实时校验SID，更可靠
正确做法永远是：用户→G组→DL组→资源权限。中间任何一环都不能短路。
嵌套深度与性能影响的实际边界
AD本身支持最多64层嵌套，但A-G-DL-P本质上只要求2层嵌套（G → DL），额外嵌套纯属设计失误。真正影响性能的是token大小：
- 每个用户token包含其所有所属组的SID，G组和DL组都会计入
- 一个用户若属于50个G组，又通过这些G组间接属于200个DL组，token可能超12KB，导致Kerberos认证失败（报错
KDC_ERR_TGT_REVOKED或登录慢） - 解决方案不是减少嵌套，而是收紧G组粒度：避免“
G-All-Employees”这类大组，改用G-HR-Recruiting、G-HR-Compensation等窄口径组
记住：DL组可以复用，G组应该按最小权限原则拆分。一个用户进3个G组，比进1个G组再让它嵌套进30个DL组，更可控、更轻量。
