Lock Down a Department with GPO

Build OU structure, enforce Group Policy, and set up shared folders in AD.

Introduction

30 Second Summary

When someone new joins a department at work, they expect their shared drives to appear instantly, their access to be ready, and their restrictions already in place. Behind the scenes, a sysadmin configured all of that using Active Directory structure and Group Policy.

In this project, you will build a production-ready department onboarding setup for a fictional "Sales" team on Windows Server 2022. You will create Organizational Units, configure Group Policy Objects, set NTFS and share permissions, and auto-map a drive so everything works the moment a Sales user logs in.

What You'll Build

When your Sales user logs into any domain workstation, their department drive appears automatically, Control Panel is blocked by policy, and only members of their security group can write to the shared folder.

By the end of this project, you'll have:

  • A Sales user logs in and their S: drive appears automatically, mapped to the department share via Group Policy Preferences.
  • Opening Control Panel shows a restriction message because your GPO blocks it, and you can prove exactly which policy applied by running gpresult /r on the client.
  • A non-Sales user tries to access the Sales share and gets denied because your Security Groups enforce group-based file access.
  • Secret Mission: Onboard a second department (IT) with its own OU, group, share, and a completely different GPO that proves per-department policy isolation.

Are there any prerequisites?

This project assumes you already have a Windows Server 2022 Domain Controller with Active Directory Domain Services configured, at least one domain user account created, and a Windows 10 machine joined to the domain.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Build the OU Structure and Security Groups

Your domain users currently sit in the default "Users" container. This container cannot have Group Policy Objects linked to it, which means you have no way to enforce department-level policies on those users.

In this step, you'll build a proper Organizational Unit hierarchy that separates user objects from computer objects. This structure gives you clean GPO targeting for each department, following Microsoft best practices.

In this step, get ready to:
  • Create the OU hierarchy (Corp > Users > Sales and Corp > Computers > Sales).
  • Create the SG_Sales_Users security group and add your domain user.
  • Move existing objects into their proper OUs and verify in ADUC.
Create the OU hierarchy

A well-structured OU hierarchy separates user objects from computer objects into their own containers. This lets you apply user-focused GPOs to one OU and computer-focused GPOs to another without overlap.

Why separate Users and Computers?

Each GPO has a User Configuration section and a Computer Configuration section. When users and computers live in the same OU, both halves process on every object. Separating them into homogeneous OUs means you can disable the unused half, which speeds up GPO processing and avoids unintended side effects.

  • Switch to your PowerShell (Administrator) window on the Domain Controller.
  • Create the OU structure by pasting and running the following commands:
# Replace "yourdomain" and "com" with your actual domain components (e.g., DC=contoso,DC=com)

Import-Module ActiveDirectory

# Create top-level Corp OU
New-ADOrganizationalUnit -Name "Corp" -Path "DC=yourdomain,DC=com" -Description "Corporate organizational units"

# Create Users and Computers OUs under Corp
New-ADOrganizationalUnit -Name "Users" -Path "OU=Corp,DC=yourdomain,DC=com" -Description "All department user OUs"
New-ADOrganizationalUnit -Name "Computers" -Path "OU=Corp,DC=yourdomain,DC=com" -Description "All department computer OUs"

# Create Sales OUs under Users and Computers
New-ADOrganizationalUnit -Name "Sales" -Path "OU=Users,OU=Corp,DC=yourdomain,DC=com" -Description "Sales department users"
New-ADOrganizationalUnit -Name "Sales" -Path "OU=Computers,OU=Corp,DC=yourdomain,DC=com" -Description "Sales department computers"

What does this code do?

  • Import-Module ActiveDirectory loads the AD cmdlets so PowerShell can manage domain objects.
  • The first New-ADOrganizationalUnit creates a top-level "Corp" OU directly under your domain root. This keeps all custom OUs contained in one place.
  • The next two commands create "Users" and "Computers" OUs nested under Corp.
  • The final two commands create a "Sales" OU under each, giving you Corp > Users > Sales and Corp > Computers > Sales.

Replace the domain path before running

Every DC=yourdomain,DC=com in the commands must match your actual domain. For example, if your domain is contoso.com, replace it with DC=contoso,DC=com. If your domain is lab.local, use DC=lab,DC=local.

  • Verify the OUs were created by running:
Get-ADOrganizationalUnit -Filter * -SearchBase "OU=Corp,DC=yourdomain,DC=com" | Select-Object Name, DistinguishedName

You should see five OUs listed: Corp, Users, Computers, Sales (under Users), and Sales (under Computers).

Getting an error about the path?

  • Double-check that you replaced DC=yourdomain,DC=com with your actual domain components in every command.
  • If you see "Directory object not found", your domain DN may have more than two parts (e.g., DC=sales,DC=contoso,DC=com). Run (Get-ADDomain).DistinguishedName to find the correct value.
  • help me troubleshoot my OU creation error
Create the security group and add your user

A Security Group is the single key that unlocks everything for a department: file share access, drive mapping, and GPO targeting. You assign permissions to the group once, and any user added to it automatically inherits those permissions.

  • Create the Sales security group and add your existing domain user by running:
# Create the Sales security group
New-ADGroup -Name "SG_Sales_Users" -GroupScope Global -GroupCategory Security -Path "OU=Sales,OU=Users,OU=Corp,DC=yourdomain,DC=com" -Description "Sales department members - grants access to Sales resources"

# Add your existing user to the Sales group (replace SalesUser1 with actual username)
Add-ADGroupMember -Identity "SG_Sales_Users" -Members "SalesUser1"

What does this code do?

  • New-ADGroup creates a Global Security group named SG_Sales_Users inside the Sales Users OU. The "SG_" prefix is a naming convention that makes security groups easy to identify.
  • Add-ADGroupMember adds your existing domain user to that group. Replace SalesUser1 with the actual username of the domain user you created earlier.
  • Verify the group membership by running:
Get-ADGroupMember -Identity "SG_Sales_Users" | Select-Object Name

You should see your domain user's name in the output, confirming they are a member of the group.

User not found?

  • Make sure you replaced SalesUser1 with the exact SamAccountName of your domain user. Run Get-ADUser -Filter * | Select-Object SamAccountName to list all user accounts in your domain.
  • help me find my domain username for the security group
Move objects into the Sales OUs

Your user and computer objects still sit in the default containers. Moving them into the proper Sales OUs is what makes your GPO targeting actually work. A GPO linked to the Sales Users OU only applies to objects inside that OU.

  • Move your user and computer objects into their Sales OUs by running:
# Move existing user to Sales Users OU (replace SalesUser1 and adjust source DN)
Get-ADUser -Identity "SalesUser1" | Move-ADObject -TargetPath "OU=Sales,OU=Users,OU=Corp,DC=yourdomain,DC=com"

# Move existing computer to Sales Computers OU (replace WIN10-CLIENT with actual computer name)
Get-ADComputer -Identity "WIN10-CLIENT" | Move-ADObject -TargetPath "OU=Sales,OU=Computers,OU=Corp,DC=yourdomain,DC=com"

What does this code do?

  • Get-ADUser retrieves your user object, then pipes it to Move-ADObject which relocates it from the default Users container into your Sales Users OU.
  • Get-ADComputer does the same for your Windows 10 machine, moving it into the Sales Computers OU. Replace WIN10-CLIENT with your actual computer name.

Before you verify, what do you expect to see when you expand Corp > Users > Sales in ADUC?

  • Open Active Directory Users and Computers (dsa.msc) on the Domain Controller.
  • In the left pane, expand your domain name.
  • Expand Corp > Users > Sales. Confirm your user account appears here.
  • Expand Corp > Computers > Sales. Confirm your Windows 10 computer object appears here.

You should see your user account in Corp > Users > Sales and your computer object in Corp > Computers > Sales. This confirms your OU structure is complete and both objects are in the right place.

Objects not showing up in the new OU?

  • In ADUC, click View in the menu bar and make sure Advanced Features is checked. Then press F5 to refresh the tree.
  • If the move command failed, check that you replaced WIN10-CLIENT with your actual computer name. Run Get-ADComputer -Filter * | Select-Object Name to find it.
  • help me troubleshoot why my objects didn't move to the Sales OU
Save the script for future reference

You've now run all the commands to build your OU structure. Save them as a script file so you have a documented record of what you built (and can reuse the pattern for new departments later).

  • In PowerShell, create the script file by running:
Set-Content -Path "C:\setup-ou-structure.ps1" -Value @'
# Run this on the Domain Controller as Administrator
# Replace "yourdomain" and "com" with your actual domain components (e.g., DC=contoso,DC=com)

Import-Module ActiveDirectory

# Create top-level Corp OU
New-ADOrganizationalUnit -Name "Corp" -Path "DC=yourdomain,DC=com" -Description "Corporate organizational units"

# Create Users and Computers OUs under Corp
New-ADOrganizationalUnit -Name "Users" -Path "OU=Corp,DC=yourdomain,DC=com" -Description "All department user OUs"
New-ADOrganizationalUnit -Name "Computers" -Path "OU=Corp,DC=yourdomain,DC=com" -Description "All department computer OUs"

# Create Sales OUs under Users and Computers
New-ADOrganizationalUnit -Name "Sales" -Path "OU=Users,OU=Corp,DC=yourdomain,DC=com" -Description "Sales department users"
New-ADOrganizationalUnit -Name "Sales" -Path "OU=Computers,OU=Corp,DC=yourdomain,DC=com" -Description "Sales department computers"

# Create the Sales security group
New-ADGroup -Name "SG_Sales_Users" -GroupScope Global -GroupCategory Security -Path "OU=Sales,OU=Users,OU=Corp,DC=yourdomain,DC=com" -Description "Sales department members - grants access to Sales resources"

# Add your existing user to the Sales group (replace SalesUser1 with actual username)
Add-ADGroupMember -Identity "SG_Sales_Users" -Members "SalesUser1"

# Move existing user to Sales Users OU (replace SalesUser1 and adjust source DN)
Get-ADUser -Identity "SalesUser1" | Move-ADObject -TargetPath "OU=Sales,OU=Users,OU=Corp,DC=yourdomain,DC=com"

# Move existing computer to Sales Computers OU (replace WIN10-CLIENT with actual computer name)
Get-ADComputer -Identity "WIN10-CLIENT" | Move-ADObject -TargetPath "OU=Sales,OU=Computers,OU=Corp,DC=yourdomain,DC=com"

# Verify the OU structure
Get-ADOrganizationalUnit -Filter * -SearchBase "OU=Corp,DC=yourdomain,DC=com" | Select-Object Name, DistinguishedName
'@
  • Confirm the file was created by running:
Test-Path "C:\setup-ou-structure.ps1"

You should see True in the output, confirming your script file exists.

✔️ Awesome, I've got everything!

Great. You have a complete OU hierarchy, a security group with your user in it, and both objects living in the correct Sales OUs. Your script is saved at C:\setup-ou-structure.ps1 for documentation.

ⓧ I'd like to double check the full code

Here is the complete setup-ou-structure.ps1 script. Compare it against what you ran (remembering to substitute your own domain components, username, and computer name):

# Run this on the Domain Controller as Administrator
# Replace "yourdomain" and "com" with your actual domain components (e.g., DC=contoso,DC=com)

Import-Module ActiveDirectory

# Create top-level Corp OU
New-ADOrganizationalUnit -Name "Corp" -Path "DC=yourdomain,DC=com" -Description "Corporate organizational units"

# Create Users and Computers OUs under Corp
New-ADOrganizationalUnit -Name "Users" -Path "OU=Corp,DC=yourdomain,DC=com" -Description "All department user OUs"
New-ADOrganizationalUnit -Name "Computers" -Path "OU=Corp,DC=yourdomain,DC=com" -Description "All department computer OUs"

# Create Sales OUs under Users and Computers
New-ADOrganizationalUnit -Name "Sales" -Path "OU=Users,OU=Corp,DC=yourdomain,DC=com" -Description "Sales department users"
New-ADOrganizationalUnit -Name "Sales" -Path "OU=Computers,OU=Corp,DC=yourdomain,DC=com" -Description "Sales department computers"

# Create the Sales security group
New-ADGroup -Name "SG_Sales_Users" -GroupScope Global -GroupCategory Security -Path "OU=Sales,OU=Users,OU=Corp,DC=yourdomain,DC=com" -Description "Sales department members - grants access to Sales resources"
# Add your existing user to the Sales group (replace SalesUser1 with actual username)
Add-ADGroupMember -Identity "SG_Sales_Users" -Members "SalesUser1"

# Move existing user to Sales Users OU (replace SalesUser1 and adjust source DN)
Get-ADUser -Identity "SalesUser1" | Move-ADObject -TargetPath "OU=Sales,OU=Users,OU=Corp,DC=yourdomain,DC=com"

# Move existing computer to Sales Computers OU (replace WIN10-CLIENT with actual computer name)
Get-ADComputer -Identity "WIN10-CLIENT" | Move-ADObject -TargetPath "OU=Sales,OU=Computers,OU=Corp,DC=yourdomain,DC=com"

# Verify the OU structure
Get-ADOrganizationalUnit -Filter * -SearchBase "OU=Corp,DC=yourdomain,DC=com" | Select-Object Name, DistinguishedName

Your OU structure is in place and your security group is ready. Next up, you'll create a GPO that proves this structure works by visibly restricting what the Sales user can do on any machine they log into.

Create a GPO and See It Enforced on the Client

Your OU structure is in place with Sales users and computers neatly separated into their own containers. The structure by itself does nothing. Until you link a policy to it, your Sales users can do anything on any domain workstation.

A Group Policy Object is a collection of settings that Windows pushes to users or computers based on which OU they live in. In this step, you will create a GPO that blocks Control Panel access for anyone in the Sales Users OU, then prove it works on the Windows 10 client.

In this step, get ready to:
  • Create a GPO called "Sales - User Restrictions" and link it to the Sales Users OU.
  • Configure the GPO to block Control Panel access.
  • Verify the policy applies on the Windows 10 client using gpresult /r.
Create and link the GPO in Group Policy Management Console

The Group Policy Management Console is where you create, link, and manage all GPOs for your domain. You will create a GPO directly on the Sales Users OU so it applies only to users in that container.

  • On the Domain Controller, press the Windows key to open your search bar.
  • Type gpmc.msc and press Enter to open the Group Policy Management Console.
  • In the left pane, expand Forest > Domains > your domain name.
  • Expand the Corp OU, then Users, then Sales.
  • Right-click the Sales OU and select Create a GPO in this domain, and Link it here....
  • In the Name field, type Sales - User Restrictions and click OK.

You should see Sales - User Restrictions appear under the Sales OU in the left pane. The GPO is now linked, but it has no settings configured yet.

What does linking a GPO to an OU mean?

When a GPO is linked to an OU, Windows applies that GPO's settings to every user or computer object inside that OU. Because you linked it to the Sales Users OU (not the Sales Computers OU), these settings follow the user to any workstation they log into.

Configure the Control Panel restriction

Now you will edit the GPO and enable a setting that blocks Sales users from opening Control Panel or PC Settings.

  • Right-click Sales - User Restrictions in the left pane and select Edit....
  • The Group Policy Management Editor window opens.
  • In the left pane, navigate to User Configuration > Policies > Administrative Templates > Control Panel.
  • In the right pane, double-click Prohibit access to Control Panel and PC settings.
  • Select Enabled, then click OK.
  • Close the Group Policy Management Editor window.

Back in the Group Policy Management Console, click Sales - User Restrictions in the left pane. In the Settings tab on the right, you should see your enabled setting listed under User Configuration.

Why User Configuration and not Computer Configuration?

User Configuration settings follow the user account regardless of which machine they log into. Computer Configuration settings apply to the machine regardless of who logs in. Because you want to restrict what Sales users can do on any workstation, User Configuration is the correct choice.

Force a policy refresh and test on the client

Group Policy refreshes automatically every 90 minutes, but you do not want to wait. You will force an immediate refresh on the Windows 10 client and then test whether the restriction works.

  • Switch to your Windows 10 client (WIN10-CLIENT).
  • Log off the current session and log back in as your Sales user (SalesUser1).
  • Once logged in, open Command Prompt by pressing the Windows key, typing cmd, and pressing Enter.
  • Force an immediate policy refresh by running this command:
gpupdate /force

Wait for both the Computer Policy and User Policy updates to complete. You should see messages confirming each update succeeded.

  • Now try to open Control Panel. Click the Start button, type Control Panel, and press Enter.

Before you do this, what do you think will happen? Will Control Panel open normally, or will something block it?

You should see a restriction message that reads: "This operation has been cancelled due to restrictions in effect on this computer. Please contact your system administrator." That is your GPO working.

What just happened?

When SalesUser1 logged in, Windows checked which OU the user lives in, found the linked GPO, and applied the restriction. The gpupdate /force command ensured the policy was pulled immediately rather than waiting for the next automatic refresh cycle.

Because the GPO is linked to the Sales Users OU (not the domain root), the Administrator account on the DC is unaffected. Only users inside that OU see the restriction.

Control Panel still opens normally?

Make sure you logged in as SalesUser1, not as the domain Administrator. The GPO only applies to users in the Sales Users OU.

Confirm that SalesUser1 is actually in the OU=Sales,OU=Users,OU=Corp path. On the Domain Controller, open Active Directory Users and Computers and check the user's location.

If the user is in the correct OU, try logging off completely and logging back in instead of just running gpupdate /force. Some settings require a fresh logon to take effect.

help me troubleshoot why my GPO is not applying to my domain user on the Windows 10 client

Confirm the GPO with gpresult

Seeing the restriction message is proof the GPO works, but sysadmins need a diagnostic tool that shows exactly which policies are applied and where they came from. That tool is gpresult.

  • In the same Command Prompt window on WIN10-CLIENT, run:
gpresult /r

Before you look at the output, predict: where in the results do you expect to find your GPO name?

  • Scroll through the output and find the section labelled USER SETTINGS.
  • Under Applied Group Policy Objects, confirm that Sales - User Restrictions appears in the list.

This confirms the GPO is reaching the client through your OU structure. The policy flows from the domain, through Corp, through Users, and lands on the Sales OU where your user lives.

What does gpresult /r show?

The gpresult /r command displays the Resultant Set of Policy (RSoP) summary. It lists every GPO that applied to the current user and computer, including the OU the object belongs to and the last time policy was applied.

In production, this is the first command you run when a user reports that a policy is not working. It tells you immediately whether the GPO reached the machine and whether it was filtered out.

GPO not listed under Applied Group Policy Objects?

Check that you linked the GPO to OU=Sales,OU=Users,OU=Corp (the Users branch), not OU=Sales,OU=Computers,OU=Corp (the Computers branch). User settings only apply when linked to an OU containing user objects.

Also check the gpresult /r output under "The following GPOs were not applied because they were filtered out" to see if security filtering is blocking it.

help me figure out why my GPO is not showing in gpresult output

Your GPO is live. Any user in the Sales Users OU is now blocked from Control Panel on any workstation they log into. Next up, you will create a shared folder for the Sales team and discover what happens when permissions are not configured properly.

Create a Shared Folder and Hit the Permissions Wall

Your GPO is live and doing its job. SalesUser1 cannot open Control Panel, and gpresult /r proves the policy is reaching the client through your OU structure.

Now the Sales team needs somewhere to store their documents. In this step, you will create a shared folder on the Domain Controller and share it on the network. You will deliberately leave permissions at their defaults to see what breaks.

In this step, get ready to:
  • Create a shared folder at C:\Shares\Sales on the Domain Controller.
  • Test file access from the Windows 10 client as SalesUser1.
  • Hit the permissions wall and understand why it happens.
Create the Sales shared folder on the Domain Controller

Every department needs a central location for shared documents. A folder on the Domain Controller, shared over the network via SMB, makes files accessible to any domain user with the right permissions.

  • Switch back to your Domain Controller.
  • Open PowerShell as Administrator (right-click the Start menu, select Windows PowerShell (Admin)).
  • Create the shared folder by running these commands:
# Create the folder structure
New-Item -Path "C:\Shares\Sales" -ItemType Directory -Force

# Share the folder (initially with default permissions - this will be fixed in Step 4)
New-SmbShare -Name "Sales" -Path "C:\Shares\Sales" -ReadAccess "Everyone"

What do these commands do?

  • New-Item creates the C:\Shares\Sales folder on disk. The -Force flag means it will not error if the folder already exists.
  • New-SmbShare exposes that folder to the network as a share named Sales. The -ReadAccess "Everyone" flag grants read-only access to all domain users. Notice there is no write or change permission here.
  • Confirm the share was created by running:
Get-SmbShare -Name "Sales"

You should see the share listed with its path showing C:\Shares\Sales.

Seeing an error about the share name already existing?

If you previously created a share with the same name, remove it first with Remove-SmbShare -Name "Sales" -Force and then re-run the New-SmbShare command.

Help me troubleshoot this error

  • Verify the share permissions by running:
Get-SmbShareAccess -Name "Sales"

You should see a single entry: Everyone with Read access. This is the only permission protecting the share right now.

Why only Everyone - Read?

Share permissions and NTFS permissions are two independent layers. The effective permission a user gets is the most restrictive combination of both. Right now, the share layer only grants Read. The NTFS layer has not been configured for your security group at all.

This means even if NTFS allowed writes, the share permission would still block them. You are about to see this in action.

Test access from the Windows 10 client

The share is live on the network. Time to test whether SalesUser1 can actually use it from the client machine.

  • Switch to your Windows 10 client (WIN10-CLIENT).
  • Make sure you are logged in as SalesUser1.
  • Open File Explorer by pressing Win+E.
  • Click the address bar at the top of File Explorer and type the UNC path to your share:
\\[[YOURSERVERNAME="your DC server name"]]\Sales
  • Press Enter to navigate to the share.

You should see the folder open successfully. It is empty, but the fact that it opened proves read access is working through the network share.

Now for the real test. Before you try creating a file, predict what will happen. You have a share that grants Everyone only Read access. What do you think happens when SalesUser1 tries to write something?

  • Right-click inside the empty folder.
  • Select New then Text Document.

You will see a "Destination Folder Access Denied" dialog telling you that you need permission to perform this action. The file cannot be created.

Understand the permissions wall

This error is not a bug. You designed it. This is the exact scenario that generates helpdesk tickets in real environments every single day.

Why did this happen?

Two permission layers blocked the write. The share permission only grants Read to Everyone. Creating a file requires Change or Full Control at the share level.

Even if you fixed the share permission, the NTFS permissions on C:\Shares\Sales have not been configured to grant your SG_Sales_Users group any explicit access. Both layers need to allow the action for it to succeed.

The fix is never to grant permissions to individual users. You always assign them to security groups. That is the core sysadmin pattern you will apply in the next step.

✔️ Awesome, I've got everything!

Great. You have confirmed that the share exists and that the default permissions block write access. This is exactly the state you need before fixing it properly.

ⓧ I'd like to double check the full code

Here is the complete script you ran on the Domain Controller:

# Run this on the Domain Controller as Administrator
# Creates the shared folder for the Sales department

# Create the folder structure
New-Item -Path "C:\Shares\Sales" -ItemType Directory -Force

# Share the folder (initially with default permissions - this will be fixed in Step 4)
New-SmbShare -Name "Sales" -Path "C:\Shares\Sales" -ReadAccess "Everyone"

You have proven that a share with default permissions is a broken share. Users can see it, but they cannot do their work. In the next step, you will fix this the right way using your SG_Sales_Users security group.

Fix Permissions Using Security Groups

In the previous step, you hit the "Access Denied" wall when trying to create a file in the Sales share. That happened because the share only grants Everyone Read access, and the NTFS permissions have no explicit entry for your security group.

The fix follows a core sysadmin pattern: never assign permissions to individual users. Always assign to security groups. You will fix both the share permissions AND the NTFS permissions, because Windows checks both layers and enforces the most restrictive combination.

In this step, get ready to:
  • Fix share permissions to grant SG_Sales_Users Change access.
  • Fix NTFS permissions to grant SG_Sales_Users Modify access.
  • Verify write access works from the Windows 10 client.
Fix the share permissions

The share currently has "Everyone - Read" as the only permission entry. You need to remove that generic entry and replace it with explicit access for your SG_Sales_Users security group.

  • On the Domain Controller, open PowerShell as Administrator.
  • Create a new script file called fix-sales-permissions.ps1 and add the following share permissions code:
# Run this on the Domain Controller as Administrator
# Fixes the Sales share with proper security group permissions

# Fix share permissions - remove Everyone, add SG_Sales_Users with Change, add Domain Admins with Full
Revoke-SmbShareAccess -Name "Sales" -AccountName "Everyone" -Force
Grant-SmbShareAccess -Name "Sales" -AccountName "SG_Sales_Users" -AccessRight Change -Force
Grant-SmbShareAccess -Name "Sales" -AccountName "Domain Admins" -AccessRight Full -Force

What does this code do?

  • Revoke-SmbShareAccess removes the "Everyone" entry entirely, so no random user can browse the share.
  • The first Grant-SmbShareAccess gives SG_Sales_Users "Change" access at the share level. Change allows read, write, and delete through the share.
  • The second Grant-SmbShareAccess gives Domain Admins "Full" access so administrators can always manage the folder.
  • The -Force flag suppresses confirmation prompts so the commands run without pausing.

Why Change and not Full for the Sales group?

"Change" lets users create, edit, and delete files. "Full" also lets them modify the share's permissions themselves. Regular users should never be able to change who else has access. Only administrators get Full Control.

Fix the NTFS permissions

Share permissions are just the first gate. NTFS permissions are the second layer that Windows checks independently. Even with correct share permissions, NTFS can still block access if it has no matching rule for the user's group.

  • Add the following NTFS permissions code below the share permissions section in fix-sales-permissions.ps1:
# Fix NTFS permissions
$folderPath = "C:\Shares\Sales"
$acl = Get-Acl -Path $folderPath

# Remove inheritance and copy existing rules
$acl.SetAccessRuleProtection($true, $false)

# Add Domain Admins - Full Control
$adminRule = New-Object System.Security.AccessControl.FileSystemAccessRule("Domain Admins", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($adminRule)

# Add SYSTEM - Full Control
$systemRule = New-Object System.Security.AccessControl.FileSystemAccessRule("SYSTEM", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($systemRule)

# Add SG_Sales_Users - Modify
$salesRule = New-Object System.Security.AccessControl.FileSystemAccessRule("SG_Sales_Users", "Modify", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($salesRule)

# Apply the ACL
Set-Acl -Path $folderPath -AclObject $acl

# Verify
Get-SmbShareAccess -Name "Sales"
Get-Acl -Path $folderPath | Format-List

What does this code do?

Get-Acl retrieves the current access control list for the folder. SetAccessRuleProtection($true, $false) disables inheritance and removes all inherited rules. This gives you a clean slate where only your explicit rules apply.

Each FileSystemAccessRule defines who gets access, what level, and whether it applies to subfolders and files (ContainerInherit,ObjectInherit). SYSTEM needs Full Control because Windows itself uses that account for background operations.

The verification commands at the end print both the share permissions and NTFS permissions so you can confirm everything applied correctly.

  • Save fix-sales-permissions.ps1.
  • Run the script by executing this command in PowerShell:
.\fix-sales-permissions.ps1

You should see output showing the updated share permissions (SG_Sales_Users with Change, Domain Admins with Full) and the NTFS ACL listing your three explicit entries.

Seeing an error about the share not being found?

  • Make sure the share name "Sales" matches exactly what you created in the previous step. Run Get-SmbShare to list all shares and check the name.
  • If you see a permissions error, confirm you are running PowerShell as Administrator (right-click, Run as Administrator).
  • help me troubleshoot my fix-sales-permissions.ps1 script errors

✔️ Awesome, I've got everything!

Great. Double check you have saved fix-sales-permissions.ps1 and that the output shows SG_Sales_Users with Change access and Domain Admins with Full Control.

ⓧ I'd like to double check the full code

Here is the complete fix-sales-permissions.ps1 script. Compare yours against it:

# Run this on the Domain Controller as Administrator
# Fixes the Sales share with proper security group permissions

# Fix share permissions - remove Everyone, add SG_Sales_Users with Change, add Domain Admins with Full
Revoke-SmbShareAccess -Name "Sales" -AccountName "Everyone" -Force
Grant-SmbShareAccess -Name "Sales" -AccountName "SG_Sales_Users" -AccessRight Change -Force
Grant-SmbShareAccess -Name "Sales" -AccountName "Domain Admins" -AccessRight Full -Force

# Fix NTFS permissions
$folderPath = "C:\Shares\Sales"
$acl = Get-Acl -Path $folderPath

# Remove inheritance and copy existing rules
$acl.SetAccessRuleProtection($true, $false)

# Add Domain Admins - Full Control
$adminRule = New-Object System.Security.AccessControl.FileSystemAccessRule("Domain Admins", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($adminRule)

# Add SYSTEM - Full Control
$systemRule = New-Object System.Security.AccessControl.FileSystemAccessRule("SYSTEM", "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($systemRule)

# Add SG_Sales_Users - Modify
$salesRule = New-Object System.Security.AccessControl.FileSystemAccessRule("SG_Sales_Users", "Modify", "ContainerInherit,ObjectInherit", "None", "Allow")
$acl.AddAccessRule($salesRule)

# Apply the ACL
Set-Acl -Path $folderPath -AclObject $acl

# Verify
Get-SmbShareAccess -Name "Sales"
Get-Acl -Path $folderPath | Format-List
Verify write access on the Windows 10 client

The permissions are fixed on the server side. Now you need to confirm that your Sales user can actually create files in the share from the client machine.

  • Switch to your Windows 10 client (logged in as your Sales user).
  • Open Command Prompt and run this command to clear any cached connections:
net use * /delete

Why clear cached connections?

Windows caches your network share connections with the old permissions. Without clearing the cache, you might still see "Access Denied" even though the server-side permissions are now correct.

  • If prompted to confirm, type Y and press Enter.
  • Open File Explorer and type the UNC path to your share in the address bar:
\\[[YOURSERVERNAME="YourServerName"]]\Sales

Before you try creating a file, think about what you expect to happen. Do you think it will succeed this time?

  • Right-click inside the folder.
  • Select New, then Text Document.
  • Name the file test.txt.

The file creates successfully. No more "Access Denied." Your security group permissions are working.

  • Right-click test.txt and select Properties.
  • Click the Security tab.
  • Confirm that SG_Sales_Users appears in the permissions list with Modify access.

Still seeing Access Denied?

  • Log off and log back in as the Sales user. Group membership changes sometimes require a fresh logon to take effect.
  • On the Domain Controller, run Get-ADGroupMember -Identity "SG_Sales_Users" to confirm your user is actually in the group.
  • Verify both layers: run Get-SmbShareAccess -Name "Sales" to check share permissions and Get-Acl C:\Shares\Sales | Format-List to check NTFS permissions on the server.
  • help me fix Access Denied on my Sales share after running the permissions script

You just fixed the most common helpdesk ticket in Windows file sharing: "I can see the folder but I can't save anything." The pattern you used (security group permissions on both layers) is how every production environment handles access. Next up, you will make this share appear automatically as a mapped drive when any Sales user logs in.

Auto-Map the Drive with Group Policy Preferences

Your Sales users can read and write files in the shared folder. But right now they have to type a UNC path like \\YourServerName\Sales from memory every time they want to get there.

In a production environment, users should never have to remember network paths. Group Policy Preferences can auto-map a drive letter the moment a user logs in. In this step, you will configure the S: drive to appear automatically for every Sales user on any domain workstation.

In this step, get ready to:
  • Open the existing Sales GPO in the Group Policy Editor.
  • Configure a Drive Maps preference to map S: to the Sales share.
  • Verify the drive appears automatically on the Windows 10 client after logon.
Open the GPO editor and navigate to Drive Maps

Your "Sales - User Restrictions" GPO already blocks Control Panel. You will now add a drive mapping preference to the same GPO so that a single policy handles all Sales user settings.

  • On the Domain Controller, open Group Policy Management Console by pressing the Windows key, typing gpmc.msc, and pressing Enter.
  • In the left pane, expand Forest > Domains > your domain > Corp > Users > Sales.
  • Right-click the Sales - User Restrictions GPO listed under the Sales OU.
  • Select Edit.
  • In the Group Policy Management Editor, expand User Configuration > Preferences > Windows Settings > Drive Maps.
  • Right-click Drive Maps in the left pane, then select New > Mapped Drive.

A New Drive Properties dialog opens. This is where you define what drive letter to assign, where it points, and how it behaves.

Why Drive Maps instead of logon scripts?

Group Policy Preferences Drive Maps lets you configure mapped drives for an enterprise environment without writing logon scripts. The mapping is managed centrally in the GPO, applies at every logon, and can be updated or removed by editing a single preference item.

Configure the mapped drive settings

The General tab controls where the drive points and which letter it uses. You need to fill in four fields.

  • In the Action dropdown at the top, select Update.
  • In the Location field, type the UNC path to your Sales share (for example: \\YourServerName\Sales). Replace YourServerName with your Domain Controller's actual hostname.
  • Under Drive Letter, select Use: and pick S: from the dropdown.
  • In the Label as: field, type Sales Drive.
  • Confirm that Reconnect is checked. This saves the mapping so it persists across logons.
  • Click OK to save the Drive Maps preference item.

Why Update instead of Replace?

The Update action modifies the drive mapping if it already exists, or creates it if it does not. It preserves other settings the user may have without deleting and recreating the drive each time Group Policy refreshes.

Replace would also work, but it deletes and recreates the mapping on every policy refresh. In a production environment with open files on the mapped drive, that can disrupt users.

You should now see a Drive Maps entry in the right pane of the Group Policy Management Editor showing the S: drive pointing to your Sales share.

Don't see the Drive Maps entry?

Make sure you expanded Preferences (not Policies) under User Configuration. Drive Maps lives under Preferences > Windows Settings, not under Policies > Administrative Templates.

If the Location field was empty when you clicked OK, the item will not save. Re-open the item and confirm the UNC path is filled in.

Help me troubleshoot my Drive Maps configuration

Verify the drive mapping on the Windows 10 client

The drive mapping applies when a user logs in and Group Policy processes. To pick up the new preference, the Sales user needs a fresh logon session.

  • Switch to the Windows 10 client machine.
  • If you are currently logged in as SalesUser1, click Start, click the user icon, then select Sign out.
  • Log back in as SalesUser1.

Before you open File Explorer, predict what you expect to see under This PC. Do you think a new drive letter will appear?

  • Open File Explorer by pressing the Windows key, typing File Explorer, and pressing Enter.
  • Click This PC in the left sidebar.

You should see Sales Drive (S:) listed under Network Locations. The drive mapped automatically at logon thanks to your GPO.

  • Double-click Sales Drive (S:) to open it.
  • Confirm you can see the test.txt file you created in the previous step.
  • Right-click inside the folder and create a new text file to confirm write access still works.

The S: drive is live. Your Sales users will never need to remember a UNC path again.

Don't see Sales Drive (S:)?

Make sure you fully signed out and signed back in. A simple lock/unlock does not trigger a fresh Group Policy logon pass. If in doubt, open Command Prompt and run:

gpupdate /force

Then sign out and sign back in again. The drive should appear after the fresh logon.

Also verify that the Location field in your Drive Maps preference matches your server's actual hostname. A typo in the UNC path results in no drive appearing.

Help me troubleshoot my missing drive mapping

  • To confirm the full picture, open Command Prompt on the Windows 10 client and run the following command:
gpresult /r

In the output under USER SETTINGS > Applied Group Policy Objects, confirm Sales - User Restrictions appears. This proves the GPO delivering both your Control Panel restriction and drive mapping is reaching the client through your OU structure.

Your Sales department is fully onboarded. Users get their drive automatically, cannot access Control Panel, and only see files their security group permits. Every piece connects through the OU structure you built in Step 1. Ready to push this further? The Secret Mission challenges you to onboard a second department with completely different policies.

Secret mission

Onboard a Second Department with Different Policies

You've locked down the Sales team. Now prove you can do it again for a completely different department with different needs. The IT department needs Control Panel access (unlike Sales) but should have USB storage disabled. Can you design the OU structure and GPO to enforce per-department isolation?

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely within your lab environment, so there are no ongoing cloud costs.

Resources you used:

  • OU structure under Corp (Corp > Users > Sales, Corp > Users > IT, Corp > Computers > Sales, Corp > Computers > IT).
  • Security groups: SG_Sales_Users, SG_IT_Users.
  • GPOs: "Sales - User Restrictions", "IT - User Restrictions".
  • SMB shares and folders: C:\Shares\Sales (shared as "Sales"), C:\Shares\IT (shared as "IT").
  • Domain user account: ITUser1.
  • PowerShell scripts: setup-ou-structure.ps1, create-sales-share.ps1, fix-sales-permissions.ps1, setup-it-department.ps1.

Keep everything running

No action needed. Choose this if you are still actively building on your Active Directory lab or plan to add more departments, GPOs, or shares.

  • Your OU structure, GPOs, shares, and user accounts remain in place.
  • You can continue onboarding new departments or experimenting with additional Group Policy settings.
  • Your PowerShell scripts remain wherever you saved them on the Domain Controller.

Pause - I'll come back to this later

Shut down your virtual machines to free up memory and CPU while keeping all your lab configuration intact.

  • On the Windows 10 client, click Start > Power > Shut down.
  • On the Domain Controller, click Start > Power > Shut down.
  • When you return, power on the Domain Controller first, wait for AD DS to start, then power on the Windows 10 client.

Delete - I don't want to use this again

Remove all project resources from your Active Directory environment and start fresh. Run all commands on the Domain Controller in an elevated PowerShell session.

First, move your original objects back to their default containers so they are not deleted with the OUs.

  • Move SalesUser1 and WIN10-CLIENT back to the default containers by running:
# Move user back to default Users container
Get-ADUser -Identity "SalesUser1" | Move-ADObject -TargetPath "CN=Users,DC=yourdomain,DC=com"

# Move computer back to default Computers container
Get-ADComputer -Identity "WIN10-CLIENT" | Move-ADObject -TargetPath "CN=Computers,DC=yourdomain,DC=com"

Next, delete the two GPOs from Group Policy Management Console.

  • Open gpmc.msc.
  • Expand Group Policy Objects under your domain.
  • Right-click Sales - User Restrictions and select Delete. Confirm when prompted.
  • Right-click IT - User Restrictions and select Delete. Confirm when prompted.

Remove the SMB shares and their folders by running:

# Remove SMB shares
Remove-SmbShare -Name "Sales" -Force
Remove-SmbShare -Name "IT" -Force

# Delete the shared folders
Remove-Item -Path "C:\Shares" -Recurse -Force

Delete the ITUser1 account and security groups by running:

# Remove the IT user account
Remove-ADUser -Identity "ITUser1" -Confirm:$false

# Remove security groups
Remove-ADGroup -Identity "SG_Sales_Users" -Confirm:$false
Remove-ADGroup -Identity "SG_IT_Users" -Confirm:$false

Finally, remove the OU structure. You must disable accidental deletion protection on each OU before deleting. Remove child OUs first, then parents.

# Disable protection and remove child OUs
$ouPaths = @(
    "OU=Sales,OU=Users,OU=Corp,DC=yourdomain,DC=com",
    "OU=IT,OU=Users,OU=Corp,DC=yourdomain,DC=com",
    "OU=Sales,OU=Computers,OU=Corp,DC=yourdomain,DC=com",
    "OU=IT,OU=Computers,OU=Corp,DC=yourdomain,DC=com",
    "OU=Users,OU=Corp,DC=yourdomain,DC=com",
    "OU=Computers,OU=Corp,DC=yourdomain,DC=com",
    "OU=Corp,DC=yourdomain,DC=com"
)

foreach ($ou in $ouPaths) {
    Set-ADOrganizationalUnit -Identity $ou -ProtectedFromAccidentalDeletion $false
    Remove-ADOrganizationalUnit -Identity $ou -Confirm:$false
}

Delete the PowerShell scripts you created during this project. Remove them from wherever you saved them on the Domain Controller.

# Delete scripts (adjust paths if you saved them elsewhere)
Remove-Item -Path ".\setup-ou-structure.ps1" -Force
Remove-Item -Path ".\create-sales-share.ps1" -Force
Remove-Item -Path ".\fix-sales-permissions.ps1" -Force
Remove-Item -Path ".\setup-it-department.ps1" -Force

Nice Work!

Nice Work!

You just built a production-ready department onboarding setup from scratch. Any new Sales user who logs into a domain workstation now gets their S: drive automatically, cannot access Control Panel, and can only reach files their security group permits.

What you learned:

  • Built a proper OU hierarchy following Microsoft best practices, separating user and computer objects by department so GPOs target exactly the right scope.
  • Created and linked a Group Policy Object that enforces desktop restrictions and auto-maps a department drive via Group Policy Preferences, verified end-to-end with gpresult /r on the client.
  • Hit the "Access Denied" wall and fixed it the right way by layering NTFS permissions and share permissions on security groups instead of individual users.
  • Secret Mission: Proved per-OU policy isolation by onboarding a second department (IT) with completely different restrictions, confirming that each OU gets exactly the policies it needs.

You can now onboard any new department into your domain in under 10 minutes: create the OU, add the security group, set permissions, link the GPO. That is what sysadmins do every week in production environments.

Ready to quiz yourself?