Windows Server 2025 / How to Design Departmental File Share Permissions
Departmental sharing is easier to manage when users join business groups, those groups join resource-permission groups, and folders grant access to the latter. This lab separates Sales and Support and verifies both permitted changes and denied cross-department access.
Separate accounts, business groups, and resource groups
For one domain, AGDLP means Accounts → Global groups → Domain Local groups → Permissions. It is a useful starting pattern, not the only possible design.
| Item | Sales | Support |
|---|---|---|
| Global security group | GG_Sales | GG_Support |
| Domain local security group | DL_FS_Sales_Modify | DL_FS_Support_Modify |
| New folder | D:\Shares\Sales | D:\Shares\Support |
| Share name | Sales | Support |
Use joined FS1 and NTFS storage. Check for existing names before creating empty folders; do not replace operational shares or groups with lab settings.
Create groups and ordinary test accounts
- In LabGroups, create the four security groups with the scopes shown.
- In LabUsers, create sales.user1 and support.user1 with unique initial passwords and appropriate first-logon change.
- Add each user only to its corresponding business group.
- Nest GG_Sales in DL_FS_Sales_Modify and GG_Support in DL_FS_Support_Modify.
- Confirm that neither test user is an administrator or a member of the other department’s groups.
See AD group scope and creation parameters. Department changes should normally alter business membership rather than adding individual users to every folder ACL.
Get-ADGroupMember 'GG_Sales' Get-ADGroupMember 'DL_FS_Sales_Modify' Get-ADGroupMember 'GG_Support' Get-ADGroupMember 'DL_FS_Support_Modify'
Assign resource groups NTFS Modify
- Inspect the Sales folder’s advanced security and inherited entries.
- For this new lab folder, convert inheritance to explicit access while retaining SYSTEM and administrator rights.
- Review unnecessary broad access for generic users.
- Grant AD\DL_FS_Sales_Modify Modify on the folder and intended children.
- Repeat for Support using only its matching resource group.
Modify covers normal content changes and differs from Full Control, including permission management. Allow access from several groups can accumulate, so do not begin by denying the other department. Establish the required positive grants first.
- Publish Sales through Advanced Sharing.
- Grant its domain local resource group Change and retain necessary administrator rights.
- Configure Support with its corresponding group.
- Verify paths and share access on FS1:
Get-SmbShare -Name Sales,Support | Select-Object Name,Path Get-SmbShareAccess -Name Sales Get-SmbShareAccess -Name Support
Use \\fs1.ad.example.test\Sales or the matching Support path. Avoid mixing IPs and unplanned aliases during the authentication test. Access-based enumeration can hide entries, but visibility and authorization must still be tested separately.
Cross-test both ordinary identities
| User | Own department | Other department |
|---|---|---|
| sales.user1 | Create, edit, and delete test files | Access denied |
| support.user1 | Create, edit, and delete test files | Access denied |
Use fresh CLIENT1 sign-ins, checking whoami and existing SMB connections. Refresh the sign-in token after membership changes. Diagnose share ACL, NTFS inheritance and memberships, and actual credentials separately.
For a controlled department move, change only one business membership, sign in anew, compare results, and restore the original membership. Before cleanup, identify permission references; deleting groups first can leave unresolved SIDs in ACLs. Keep the shares for the later DFS exercise.




