Windows Server 2025 / 如何设计部门文件共享权限

规划部门文件共享时，可以让用户加入业务组，再将业务组加入资源权限组，最后把文件夹权限授予资源权限组，从而集中管理访问。本实验把 Sales（销售）与 Support（支持）分开，既验证用户能修改本部门文件，也验证跨部门访问会被拒绝。

分离账户、业务组与资源权限组

在单域环境中，AGDLP 表示 Accounts → Global groups → Domain Local groups → Permissions，即账户、全局组、本地域组和权限。这是一种起点方案，并不是唯一设计。Active Directory 组作用域允许把全局组嵌套到本地域组中。本地域组属于目录，与 FS1 计算机自己的本地组不同。

使用已加入域的 FS1，以及采用 NTFS（New Technology File System，新技术文件系统）的数据卷。SMB 与 NTFS 权限实验介绍了这里需要配置的两层权限；SMB 指服务器消息块（Server Message Block）。创建 D:\Shares\Sales 和 D:\Shares\Support 前，先检查文件夹和共享名称是否已被使用。只新建空的实验文件夹，不要替换生产配置。表中的对象名是实际标识符，Sales、Support 和组名均应保持原样，不要翻译。

创建安全组和普通测试账户

1. 在“Active Directory 用户和计算机”中打开 Lab → LabGroups，通过“新建 → 组”创建表中的四个组。GG 组选择“全局”作用域，DL 组选择“本地域”作用域；四个组的类型都选“安全”，不要选“分发”，并保留确切名称。
2. 在 Lab → LabUsers 中创建 sales.user1 和 support.user1，设置不同且符合有效密码策略的初始密码。如果要求首次登录时修改密码，应在登录 CLIENT1 时完成，再测试共享。
3. 打开每个全局组的属性，选择“成员 → 添加”。就本实验的业务成员关系而言，sales.user1 只加入 GG_Sales，support.user1 只加入 GG_Support。
4. 在 DL_FS_Sales_Modify 的“成员”中添加 GG_Sales，在 DL_FS_Support_Modify 中添加 GG_Support。嵌套方向是本地域组包含全局组，而不是相反。
5. 确认两个测试账户都不是管理员，也没有直接或间接加入另一部门的组。不要在不清楚用途的情况下移除账户的默认组。

可参阅 New-ADGroup 的创建与作用域参数。图形界面步骤使用 DC1 上的“Active Directory 用户和计算机”，也可以使用装有远程服务器管理工具的计算机，但账户需要拥有实验组织单位的相应管理权限。在已提供 ActiveDirectory 模块的 PowerShell 中执行下列查询。部门变化通常应通过业务组成员关系管理，而不是把用户逐个写入所有文件夹的访问控制列表（Access Control List，ACL）。

Get-ADGroupMember 'GG_Sales'
Get-ADGroupMember 'DL_FS_Sales_Modify'
Get-ADGroupMember 'GG_Support'
Get-ADGroupMember 'DL_FS_Support_Modify'

没有 -Recursive 时，Get-ADGroupMember显示直接成员。GG_Sales 应包含 sales.user1，DL_FS_Sales_Modify 应包含 GG_Sales；Support 使用相同结构。资源权限组返回全局组，而不是展开后的用户列表，是预期结果。正式验证隔离前，还应检查间接成员关系。

将 NTFS 修改权限授予资源权限组

1. 在 FS1 上打开 D:\Shares\Sales 的“属性 → 安全 → 高级”，更改前记录条目及其应用范围。
2. 仅对这个新建的空文件夹禁用继承，并把继承权限转换为显式条目。保留 SYSTEM 和管理员所需的“完全控制”。转换本身不会移除宽泛的“允许”条目。
3. 检查 Users、Authenticated Users、Everyone 和其他通用组。移除该文件夹中不必要的授权，包括可能让另一部门进入的读取权限。
4. 授予 AD\DL_FS_Sales_Modify“修改”权限，应用于此文件夹、子文件夹和文件。不要把 sales.user1 直接加入 ACL。
5. 对 D:\Shares\Support 使用 AD\DL_FS_Support_Modify 重复配置。除必要的管理员权限外，每个文件夹应只使用与自身匹配的资源权限组。

“修改”允许一般内容操作，但不等于“完全控制”，也不能等同于管理全部权限。来自多个组的“允许”授权可能累加。因此应先配置必要授权，并移除这些新文件夹中不必要的宽泛访问，不要一开始就为另一个部门增加“拒绝”条目。

配置共享权限与服务器名称

1. 打开 D:\Shares\Sales 的“属性 → 共享 → 高级共享”，使用实际名称 Sales 共享文件夹。
2. 在“权限”中授予 AD\DL_FS_Sales_Modify“更改”，保留必要的管理权限，并移除让其他用户进入的不必要宽泛授权。不要向整个域授予“完全控制”。
3. 把 D:\Shares\Support 共享为 Support，授予 AD\DL_FS_Support_Modify“更改”。检查默认条目，并分别保存两个共享配置。
4. 在 FS1 的 PowerShell 中使用下列命令检查路径和权限。Name 与 Path 应和表格一致；除预期的管理条目外，每个资源权限组应只在自己的共享上拥有 Allow 与 Change。

Get-SmbShare -Name Sales,Support | Select-Object Name,Path
Get-SmbShareAccess -Name Sales
Get-SmbShareAccess -Name Support

使用 \\fs1.ad.example.test\Sales 和 \\fs1.ad.example.test\Support。整个测试保持同一个正常服务器名称，不要混用 IP 地址或临时别名。基于访问的枚举可以隐藏条目，但看不到名称并不能证明访问被拒绝；还必须直接打开另一个部门的共享路径进行验证。

交叉验证两种身份的部门访问

在 CLIENT1 上注销后以 sales.user1 重新登录，检查 whoami、whoami /groups 和现有 SMB 连接，避免使用残留的管理员会话。在 Sales 中创建测试文件、修改、重新读取并删除，然后直接打开 Support，确认访问被拒绝。再以 support.user1 反向测试，分别记录两种身份的结果。如果与表格不符，应分别检查共享权限、NTFS ACL、继承、组成员关系以及实际凭据，不要通过授予“完全控制”掩盖问题。

模拟调岗时，先记录 sales.user1 的原成员关系，只将该账户从 GG_Sales 移除并加入 GG_Support，保持 ACL 和其他账户不变。注销并重新登录后，在本实验条件下，该用户应能操作 Support，同时失去对 Sales 的访问。随后精确恢复原组成员关系，再次重新登录并验证初始状态。清理前先找出权限引用；如果先删除组，ACL 中可能残留无法解析的安全标识符（Security Identifier，SID）。请保留文件夹、共享和记录，以供后续分布式文件系统（DFS）实验使用。