AGDLP权限模型：告别Active Directory权限失控的实践指南

你接手共享文件服务器、应用服务器或者某个专用目录的权限审计时，如果发现“安全设置”里密密麻麻躺着员工姓名，基本可以判断这套 Active Directory 离失控不远了。如果你问我长期维护 AD 最值得坚持的权限管理模型是什么，我会毫不犹豫说：AGDLP。

AGDLP 不是什么需要额外安装的工具，也不是微软某个版本才有的新功能，它是一套把用户、组、权限串起来的经典设计约定。把 AGDLP 想明白，至少能解决 Active Directory 权限管理里 80% 的混乱问题。下面这篇文章我会结合真实维护经验，把它的原理、适用边界、落地步骤和常踩的坑一次讲透。

1. 权限失控的根子：授权动作直接缠死在资源 ACL 上

1.1 我看到的第一种“能跑但很难管”的模型

很多中小型企业的 AD 环境一开始并不算乱，用户只有几十个，共享文件夹也就两三个。管理员发现市场部要访问市场部文件夹，直接右键文件夹，把“张三”“李四”的账号加进安全页签。权限确实通了，访问也正常。

问题在半年后开始暴露：张三离职了，但账号没禁用；李四调岗了，却仍然能读销售数据。更麻烦的是，管理员自己都不记得哪些共享授权给了哪些人，每次有人提“我访问不了”，他就要打开文件夹一个个翻 ACE 列表。

这种“直接给用户账户授权”的模式，问题不在于当时能不能用，而在于它把两个变化频率完全不同的东西绑在了一起：人员的流动是高频的，资源的权限定义是低频的。一个人入职、转岗、离职，都要去改资源端的 ACL，而资源端的 ACL 一旦多人共享、跨服务器分布，你根本不可能逐个去同步更新。

1.2 第二种隐藏更深的混乱：全局组粗放授权

比直接给用户授权稍好一点的，是有人意识到“应该建组”，于是建了一堆全局组，比如“财务部”“研发部”“市场部”，然后把部门所有人都塞进去，再把文件夹权限授给这些组。

这种做法的进步在于实现了“用户-组”的聚合，但粒度通常粗得可怕。一个“研发部”里，有人看代码、有人看文档、有人管测试环境，他们不可能需要同样一套权限。部门组往往只有两种结果：要么权限给得很小，导致动不动要给个别人单独加 ACL；要么权限给得很大，整个部门都能访问本不该访问的目录。于是没过多久，ACL 上又长出了“研发部-张三专用”“研发部-项目临时”之类的新组，混乱只是换了一种形式。

真正的病灶在于这两个模型都没有把“角色”和“资源”拆开。权限管理的本质，应该是让人归属于某个角色，再让角色去对接资源；而不是每次把具体的人直接“怼”到资源的访问列表上。

2. AGDLP 四个字母的作用边界与一次授权请求的完整流转

2.1 先说清楚每个字母代表什么

AGDLP 拆开是四个对象加一个动作：A 代表用户账户（Account），G 代表全局组（Global group），DL 代表域本地组（Domain Local group），P 代表权限（Permission）。整个模型的处理顺序是：用户账户放进全局组，全局组放进域本地组，把权限授予域本地组。

很多资料把 AGDLP 当成“嵌套规则”来讲，这没错，但容易让人只记住形状、没理解意义。我更喜欢从“变化频率”来理解这套模型：A 是变动最快的，P 是变动最慢的，中间的 G 和 DL 分别承接人员流动和资源权限变化。理论上，任何一次权限变更都不需要去动资源 ACL，只需要调整组关系。

按照微软的惯例，G 一般放在域的“全局组 OU”，DL 放在资源域本地组 OU。你不需要刻意把它们分散在不同的域，只要在 OU 设计上做区分即可。例如 OU=Groups,OU=Global 和 OU=Groups,OU=DomainLocal，这样审计和委托管理时一眼就能辨认。

2.2 从“申请权限”到“访问成功”的完整动作流

假设公司有一个应付账款共享目录 \\fs01\Finance\AP，员工王强是财务部应付岗。如果走 AGDLP，这个流程应该是：

1. 管理员先确认王强属于财务应付岗位，把他放进名为 GG_Finance_AP_User 的全局组。
2. 把 GG_Finance_AP_User 加入名为 DL_Share_AP_ReadWrite 的域本地组。
3. 在文件服务器 \\fs01 上，对 Finance\AP 目录的 ACL 只维护一条规则：允许 DL_Share_AP_ReadWrite 修改。
4. 王强访问目录时，Windows 访问检查会沿着“王强 → GG_Finance_AP_User → DL_Share_AP_ReadWrite → ACL 上的允许修改”这条链路进行验证。

后面无论发生什么人员变化，逻辑都很顺：如果王强调岗，把他从 GG_Finance_AP_User 移除；如果整个财务部不再需要修改这个目录，把 GG_Finance_AP_User 从 DL_Share_AP_ReadWrite 移除；如果这个目录换到新服务器，直接把 DL_Share_AP_ReadWrite 规则复制过去即可。

这就是 AGDLP 的魔力：你看到的 ACL 永远是稳定的几条组规则，而不是几十个忽增忽减的人名。

2.3 为什么不建议把 G 直接放进资源 ACL

有人说，那我做到“用户账户进全局组，把全局组直接授权给文件夹”不就行了吗？为什么要多一层域本地组？这个问题很经典，也值得正面回答。

在单域、单资源之下，G 直接授权确实能跑，但如果你长期这么干，会遇到两类问题：

第一，你丢失了“资源代理”这一层。域本地组本质上是资源侧的“占位符”，它可以把“访问这个文件夹”和“哪些人来访问”彻底拆开。没有了占位符，资源管理员每次变更授权策略都要关心全局组的内部结构，而全局组内部结构是按岗位划分的，岗位合并、拆分带来的影响会直接扩散到所有资源 ACL。

第二，跨域、跨林时会非常痛苦。全局组可以放进受信任域资源的 ACL，但如果你在一个多域环境里把全局组当成 ACL 主角，一旦出现域合并、组迁移、或者资源转移到另一个域，ACL 中所有组 SID 都得逐个检查。域本地组把授权边界限制在自己的域内，外面的人员流动都在组关系层面消化，DA（域管理员）不需要跨域去改文件服务器 ACL。

2.4 职责分离是 AGDLP 的隐藏价值

我见过很多企业组设计得很好，但管理仍然混乱，为什么？因为他们把“谁能改这个组”和“谁能看这个组”混在一起，所有组的管理权限都攥在域管理员手里。域管理员成为瓶颈，业务部门又不断催权限，最后管理员图省事又开始直接授权。

如果你借 AGDLP 把 G 和 DL 分开，天然的职责分离就出现了：资源所有者可以维护“域本地组”的成员关系，比如决定让哪个岗位角色进入“可写名单”；AD 管理员可以维护“全局组”的成员关系，比如根据 HR 入离职数据增减人员。两边可以分别委托给不同的人，不需要把“用户管理”和“文件服务器授权”两件大事交到同一个人手里。

3. 把现有权限体系改成 AGDLP 的五步重建方法

3.1 先从业务动作而不是现有 ACL 反推组边界

很多管理员拿到重构任务会急着写脚本扫描 ACL，然后照着现有权限“复制一份”。这通常会失败，因为旧权限本身就是混乱的产物。我的建议是：第一步不是盘 ACL，而是先把业务动作理清楚。

对每个受管资源问三个问题：

• 谁需要读？谁需要写？谁需要完全控制？
• 这些“谁”应该如何按岗位归类？
• 当前资源 ACL 里哪些授权明显不合理？

拿财务系统举例，你最后会得到类似这样的角色对应关系：应付岗可以读应付目录和写发票台账，应收岗只能读应收目录，财务经理对两个目录都有读取权限但一般不直接写入。这些角色可以映射成 GG_Finance_AP_User、GG_Finance_AR_User、GG_Finance_Manager。

组名不是拍脑袋起的，一个好的命名规范能让后面所有脚本和审计工具都方便。我常用的规范是：全局组用“GG_业务域_岗位角色”，域本地组用“DL_资源名_权限级别”，权限级别统一用 RO/RW/M/F 四个档，分别代表只读、读写、修改、完全控制。看到 DL_Share_AP_ReadWrite 就知道它是“AP 共享的可写域本地组”。

3.2 用脚本快速建立 ACL 权限基线和成员清单

组边界设计完，再去盘点存量。这一步最忌讳手工打开文件夹属性漫无目的地看，务必用脚本导出。我通常先拿共享服务器上所有共享目录的 ACL：

powershell复制$folders = Get-ChildItem "D:\Shares" -Directory -Recurse
$export = foreach ($folder in $folders) {
    $acl = Get-Acl $folder.FullName
    foreach ($ace in $acl.Access) {
        [PSCustomObject]@{
            Path      = $folder.FullName
            Identity  = $ace.IdentityReference.Value
            Rights    = $ace.FileSystemRights
            Type      = $ace.AccessControlType
            IsInherited = $ace.IsInherited
        }
    }
}
$export | Export-Csv "D:\acl-baseline.csv" -NoTypeInformation

导出的 CSV 就是基线。接下来重点看两件事：哪些 ACE 直接写的是员工姓名或非常规组名，哪些全局组出现在资源 ACL 里。这个清单不用过于精确，先把人眼审查范围缩小到 10 屏以内，再决定怎么归类。

3.3 创建全局组和域本地组并把用户按角色归类

盘点结束后按照第一步设计的角色矩阵创建组。PowerShell 可以批量处理，但前期我不建议追求一步到位，先在一个 OU 下手工建两三个“样板组”，确认路径、命名、作用域都没问题，再写循环批量建。

下面是建组的核心命令：

powershell复制# 创建全局组，用于装用户
New-ADGroup -Name "GG_Finance_AP_User" `
    -SamAccountName "GG_Finance_AP_User" `
    -GroupScope Global `
    -GroupCategory Security `
    -Path "OU=GlobalGroups,OU=Groups,DC=corp,DC=example,DC=com"

# 创建域本地组，用于做资源 ACL 授权对象
New-ADGroup -Name "DL_Share_AP_ReadWrite" `
    -SamAccountName "DL_Share_AP_ReadWrite" `
    -GroupScope DomainLocal `
    -GroupCategory Security `
    -Path "OU=DomainLocalGroups,OU=Groups,DC=corp,DC=example,DC=com"

接着把用户放进全局组。如果你有一个用户名单 CSV 或已经梳理出角色的映射关系，可以批量执行：

powershell复制$memberMap = Import-Csv ".\user-role-map.csv"
# CSV 表头： samAccountName, role
foreach ($row in $memberMap) {
    $group = switch ($row.role) {
        "AP"  { "GG_Finance_AP_User" }
        "AR"  { "GG_Finance_AR_User" }
        "Mgr" { "GG_Finance_Manager" }
        default { continue }
    }
    Add-ADGroupMember -Identity $group -Members $row.samAccountName -Confirm:$false
}

这里格外提醒：把用户加入新组不会中断用户现有访问，所以可以放胆执行。真正的风险在后面的“移除旧授权”阶段，必须验证完再删。

3.4 资源端 ACL 切换到域本地组并保留新旧并行窗口

现在进入关键操作：