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）不是理论摆设，而是解决实际管理痛点的方法：

Windows-Android_SSH_Remote_Control

通过 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脚本批量维护组成员，比手动添加更可靠，也便于审计