A-G-DL-P是微软推荐的域权限管理强制路径，即用户账户（A）→全局组（G）→域本地组（DL）→资源权限（P），四层物理隔离，不可跳过或直连，确保权限可追溯、跨域有效、审计清晰。

用a-g-dl-p原则设计域组嵌套模型，核心是把“谁”“角色”“资源”“权限”四者物理分离，避免直连、混用和跨域失能。它不是命名习惯，而是权限流的强制路径——用户只能通过这层漏斗获得访问权，中间任何一环都不能绕过。

明确四层角色与创建约束

每层有不可替代的功能和严格边界：

• A（用户账户）：仅指具体User或Computer对象，不建组，不直接加权限，只加入G组
• G（全局组）：作用域限本域，成员只能是本域用户/计算机或同域其他G组；命名体现业务角色，如G-HR-Editors、G-IT-Support
• DL（域本地组）：作用域限本域，但可跨域添加G组（甚至U组）；它是唯一能被赋NTFS、共享、SQL角色等权限的组类型；命名应绑定资源，如DL-SQL-Prod-Reader、DL-Share-Reports-Write
• P（权限）：不是组，而是你在文件夹属性、Exchange收件人策略、SQL Server安全角色里实际勾选的那些选项；它只引用DL组，绝不引用G或A

按场景选择嵌套结构

不是所有环境都只用A→G→DL→P四步，需根据域数量和管理分工调整：

• 单域内部权限：标准A→G→DL→P即可。例如销售用户→G-Sales→DL-FS-SalesData→在共享文件夹上设“修改”权限
• 双域协作（如A域用户访问B域资源）：A域建G-A-Sales，B域建DL-B-Reports，再把G-A-Sales加入DL-B-Reports；权限只在B域配置，A域管理员自行维护G组成员
• 三域以上或频繁跨域聚合：引入U（通用组），走A→G→U→DL→P路径。U组可跨域包含多个G组，便于统一授权，但需森林功能级别≥2003且启用全局编录

避开高频错误操作

这些做法看似省事，实则埋下审计盲区和权限失控隐患：

• 禁止把用户直接拖进DL组——失去角色抽象，无法批量调整岗位权限
• 禁止给G组直接分配NTFS或IIS权限——跨域时完全失效，且Get-ADPrincipalGroupMembership查不到调用关系
• 禁止在DL组里加其他DL组或用户——DL只负责承接G/U，不参与分层组织
• 禁止用同一个组既当G又当DL（比如改名伪装）——作用域和成员规则硬性冲突，AD会拒绝保存

落地时的关键检查点

每次新建组或调整嵌套后，快速验证是否符合模型逻辑：

• G组的“作用域”字段必须是Global，成员列表里没有外部域用户或DL组
• DL组的“作用域”必须是Domain local，且其“成员”中只含G/U组或本域用户（后者应尽量避免）
• 在资源权限界面（如文件夹安全选项卡）中，只有DL组出现，且没有G组或用户名字
• 运行Get-ADGroup -Identity "DL-XXX" | Get-ADGroupMember，确认返回的是G组而非用户