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

  1. In LabGroups, create the four security groups with the scopes shown.
  2. In LabUsers, create sales.user1 and support.user1 with unique initial passwords and appropriate first-logon change.
  3. Add each user only to its corresponding business group.
  4. Nest GG_Sales in DL_FS_Sales_Modify and GG_Support in DL_FS_Support_Modify.
  5. 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

  1. Inspect the Sales folder’s advanced security and inherited entries.
  2. For this new lab folder, convert inheritance to explicit access while retaining SYSTEM and administrator rights.
  3. Review unnecessary broad access for generic users.
  4. Grant AD\DL_FS_Sales_Modify Modify on the folder and intended children.
  5. 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.

Configure share access and normal server names

  1. Publish Sales through Advanced Sharing.
  2. Grant its domain local resource group Change and retain necessary administrator rights.
  3. Configure Support with its corresponding group.
  4. 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.