agdlp模型是域权限管理核心,即用户→全局组→域本地组→权限:全局组仅含本域用户,用于人员归类;域本地组接收跨域全局组并分配本域资源权限;权限只赋给域本地组,实现解耦与高效维护。
域用户的组归属与权限继承,核心在于理解组的类型、嵌套逻辑和权限分配路径。直接把用户加到权限组里看似简单,但容易导致管理混乱、权限扩散难控、跨域协作低效。真正稳定可维护的做法,是遵循结构化分层原则。
明确三类组的作用边界
域环境中主要用三类安全组,不能混用:
- 全局组(Global Group):只允许添加本域内的用户或全局组,适合按职能/部门归类人员,比如“财务部_G”“研发一组_G”
- 域本地组(Domain Local Group):可添加任意域的用户、全局组、通用组,但只能在本域内分配资源权限,比如“FINA_Folder_Read_DL”“SQL_Server_Admin_DL”
- 通用组(Universal Group):跨域可用,成员和使用范围都支持整个林,但仅在启用通用组功能(全局编录启用)的环境中生效,多用于大型多域架构
用AGDLP模型实现权限解耦
AGDLP(Accounts → Global Groups → Domain Local Groups → Permissions)不是理论摆设,而是解决实际管理痛点的方法:
通过 SSH 隧道从 Android 设备在互联网上对 Windows PC 实现完整远程控制的设置与使用指南,适用于远程桌面访问、安全 RDP 等。
- 用户账号(A)只加入对应职能的全局组(G),不直连权限组
- 全局组(G)被加入一个或多个域本地组(DL),代表“谁可以访问什么”
- 所有权限(P)只赋给域本地组(DL),不赋给用户、也不赋给全局组
- 例如:A域5名财务人员加入“A_Finance_G”,B域3名加入“B_Finance_G”;两个G都加入B域的“FINA_Share_RW_DL”;该DL拥有B域“FINA”文件夹的读写权限——这样A域管理员改自己G,B域管理员管自己DL,互不干扰
权限继承的关键规则要盯住
权限不是自动“穿透”的,必须满足条件才能生效:
- 只有安全组(非通讯组)才参与权限计算
- 组嵌套只在同林内有效;跨林需建立信任并显式配置
- 用户登录后获得的是“当前会话有效组成员身份”,动态组策略应用可能有延迟,建议用whoami /groups验证实际生效的组
- 拒绝权限(Deny)优先于允许权限(Allow),哪怕来自更高层级的组,也会中断继承
- 本地组(如Administrators)和域组共存时,本地组权限在本机生效,域组权限通过域策略或共享设置生效,二者叠加但不冲突
日常运维中几个易错点
很多权限异常其实源于配置惯性:
- 避免把用户直接加进Domain Admins或Administrators这类高危组,应通过自定义全局组+域本地组间接授权
- 不要用内置组(如Domain Users)直接赋资源权限,它随每个新用户自动加入,极易造成权限泛滥
- 删除用户时,检查其是否仍在某个全局组中;重命名用户不影响组成员关系,但迁移用户到其他域需重新加组
- 启用组策略首选项(GPP)或PowerShell脚本批量维护组成员,比手动添加更可靠,也便于审计










