Build a File Server with AD Permissions

Set up SMB shares with AD group-based access control and auto-mapped drives.

Introduction

30 Second Summary

Every office has shared folders that only certain teams should access. The IT team's documentation shouldn't be visible to Finance, and HR's employee records need to stay locked down to HR staff only.

In this project, you will build a file server on your existing domain controller that enforces department-level access control through Active Directory security groups and delivers mapped network drives automatically based on who logs in.

What You'll Build

A file server integrated with your existing Active Directory domain that enforces department-level access control through security groups and delivers mapped drives automatically via Group Policy.

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

  • Department shared folders (IT, HR, Finance) on DC01 with NTFS permissions tied to AD security groups enforcing least-privilege access.
  • SMB shares configured with Authenticated Users at the share level and NTFS handling granular restriction per department.
  • A Group Policy Preferences GPO that maps department drives (H:, I:, J:) automatically based on security group membership using item-level targeting.
  • Secret Mission: Enable Access-Based Enumeration so users cannot even see folders they lack permission to access.

Are there any prerequisites?

This project builds directly on the "Build an Active Directory Domain" project. You need DC01 (your corp.local domain controller) and WS01 (your domain-joined workstation) running in VirtualBox with your existing OUs, security groups (IT-Admins, HR-Staff, Finance-Team), and domain users already provisioned.

Verify Your Lab and Install the File Server Role

Before you can share files across your network, you need a working Active Directory domain and a server ready to host those files.

In this step, you will confirm that your lab from the previous project is still operational and install the File Server role on DC01.

In this step, get ready to:
  • Verify your domain and security groups are intact.
  • Install the File Server role on DC01.
  • Confirm WS01 can still authenticate domain users.
Start your VMs and verify the domain

Your DC01 and WS01 virtual machines need to be running before you can do anything else.

  • Open VirtualBox.
  • Select DC01 in the left panel and click Start.
  • Select WS01 in the left panel and click Start.
  • Once DC01 finishes booting, log in as CORP\Administrator with the password you set during the previous project.

Now you need to open an elevated PowerShell session on DC01 to run verification commands.

  • Right-click the Start menu on DC01.
  • Click Windows PowerShell (Admin).
  • If prompted by User Account Control, click Yes.

First, confirm your domain is responding correctly by running this command:

  • Verify the corp.local domain is operational by running this command:
Get-ADDomain

You should see output showing your domain details, including DNSRoot as corp.local and Forest as corp.local.

  • Confirm your security groups still exist by running this command:
Get-ADGroup -Filter *

You should see your three department groups listed in the output: IT-Admins, HR-Staff, and Finance-Team.

Not seeing your groups or getting an error?

If you see an error about the server being unable to process the request, the Active Directory Web Services (ADWS) may not have finished starting. Wait 30 seconds and try again.

If Get-ADGroup -Filter * does not show IT-Admins, HR-Staff, and Finance-Team, your previous project may not have completed successfully. Go back and re-run the group creation steps from that project before continuing.

Help me troubleshoot my Active Directory domain verification on DC01.

Install the File Server role

The File Server role gives Windows Server the ability to serve files over the network using the SMB protocol. You need this role before you can create shared folders.

  • Install the File Server role with its management tools by running this command:
Install-WindowsFeature -Name FS-FileServer -IncludeManagementTools

What does this command do?

  • Install-WindowsFeature is the PowerShell cmdlet that adds roles and features to Windows Server.
  • -Name FS-FileServer specifies the exact feature name for the File Server role.
  • -IncludeManagementTools installs the graphical management consoles alongside the role so you can manage shares from Server Manager.
  • Verify the installation succeeded by running this command:
Get-WindowsFeature -Name FS-FileServer

You should see FS-FileServer listed with an Install State of Installed.

Install State shows Available instead of Installed?

Make sure you ran the Install-WindowsFeature command from an elevated (Administrator) PowerShell window. If your window title does not say "Administrator", close it and reopen using Windows PowerShell (Admin) from the Start menu.

Help me fix my File Server role installation.

Why install File Server on the Domain Controller?

In production environments, you would typically host file services on a separate server. For this lab, running both roles on DC01 saves memory and disk space while still teaching the same permission concepts.

The access control model works identically regardless of whether the file server is a dedicated machine or shares hardware with the domain controller.

Verify WS01 domain connectivity

Your workstation WS01 needs to authenticate against the domain to test file access later. Logging in as a domain user proves the trust relationship is working.

  • Switch to the WS01 VM window in VirtualBox.
  • If WS01 shows a lock screen, press Ctrl+Alt+Delete (use the VirtualBox menu Input > Keyboard > Insert Ctrl+Alt+Del if the keyboard shortcut does not work).
  • Click Other user on the sign-in screen.
  • Enter CORP\mjohnson as the username.
  • Enter P@ssw0rd2024 as the password.
  • Press Enter to sign in.

If you reach the Windows desktop, domain authentication is working correctly. WS01 successfully contacted DC01 to validate the credentials.

Sign-in fails or says the domain is not available?

Make sure DC01 is fully booted and the login screen appeared before you try to sign in on WS01. The workstation needs DC01's DNS to locate the domain.

If you still cannot sign in, verify both VMs are on the same VirtualBox internal network adapter. Check that WS01's DNS is pointed to DC01's IP address (configured in your previous project).

Help me fix domain sign-in on WS01.

Your lab is verified and the File Server role is ready. Next up, you will create department folders and lock them down with NTFS permissions tied to your AD groups.

Create Department Folders with NTFS Permissions

Your File Server role is installed and ready. Now you need to create the actual folders that each department will use to store and access their files.

In an enterprise environment, folder access is controlled through NTFS permissions tied to Active Directory security groups. This means you assign permissions once to a group, and every user added to that group automatically receives the correct access.

In this step, get ready to:
  • Create the department folder structure on DC01.
  • Remove inherited permissions and set explicit NTFS access for each department group.
  • Verify permissions are correctly applied using PowerShell.
Create the folder structure on DC01

Every file server needs a logical folder structure. You will create a root folder called C:\Shares to hold all shared content, then one subfolder per department.

  • In your PowerShell session on DC01 (still running as CORP\Administrator), create the root shares folder and the three department folders by running these commands:
# Create the root shares folder
New-Item -Path "C:\Shares" -ItemType Directory

# Create one subfolder per department
New-Item -Path "C:\Shares\IT" -ItemType Directory
New-Item -Path "C:\Shares\HR" -ItemType Directory
New-Item -Path "C:\Shares\Finance" -ItemType Directory

What do these commands do?

New-Item with -ItemType Directory creates a new folder at the specified path. You end up with a clean hierarchy: C:\Shares as the parent, with IT, HR, and Finance as children.

  • Place a test file in each department folder so you can verify access later. Run these commands:
# Place a test file in each department folder
Set-Content -Path "C:\Shares\IT\IT-TestFile.txt" -Value "IT Department test file"
Set-Content -Path "C:\Shares\HR\HR-TestFile.txt" -Value "HR Department test file"
Set-Content -Path "C:\Shares\Finance\Finance-TestFile.txt" -Value "Finance Department test file"

Why place test files?

These files give you something concrete to read and write when you test access control later. Without files in the folders, you would only be able to verify folder-level access, not file-level operations.

  • Confirm the folders and files were created by running:
Get-ChildItem C:\Shares -Recurse

You should see the three department folders listed, each containing its test file.

Not seeing the folders?

Make sure you are running PowerShell as Administrator on DC01. If you see an "Access Denied" error, right-click PowerShell in the Start menu and select Run as administrator.

Help me troubleshoot folder creation on DC01.

Remove inherited permissions and set explicit NTFS access

By default, new folders inherit permissions from their parent. This means anyone with access to C:\ could potentially access your department folders. You need to break that inheritance and grant access only to the correct AD group for each department.

  • Remove inherited permissions from each department folder and grant Administrators Full Control by running these commands:
# Remove inherited permissions from each department folder
icacls "C:\Shares\IT" /inheritance:r
icacls "C:\Shares\HR" /inheritance:r
icacls "C:\Shares\Finance" /inheritance:r

# Grant Administrators Full Control on all three folders
icacls "C:\Shares\IT" /grant "Administrators:(OI)(CI)F"
icacls "C:\Shares\HR" /grant "Administrators:(OI)(CI)F"
icacls "C:\Shares\Finance" /grant "Administrators:(OI)(CI)F"

What does this code do?

/inheritance:r strips all inherited permissions from the folder. After running it, the folder has no permissions at all except those you explicitly add.

(OI)(CI)F means Object Inherit, Container Inherit, Full Control. This ensures Administrators can manage the folder, its subfolders, and its files. You add this immediately after removing inheritance so you do not lock yourself out.

  • Now grant each AD security group Modify access to its corresponding department folder by running:
# Grant each department group Modify access to their folder
icacls "C:\Shares\IT" /grant "CORP\IT-Admins:(OI)(CI)M"
icacls "C:\Shares\HR" /grant "CORP\HR-Staff:(OI)(CI)M"
icacls "C:\Shares\Finance" /grant "CORP\Finance-Team:(OI)(CI)M"

Why Modify instead of Full Control?

Modify access lets users create, edit, and delete files within the folder. Full Control adds the ability to change permissions and take ownership, which is reserved for Administrators only. This follows the principle of least privilege by giving users exactly what they need and nothing more.

The CORP\ prefix specifies the domain name so Windows resolves the correct domain group rather than a local account.

  • After each command, you should see output confirming "Successfully processed 1 files; Failed processing 0 files" for every line.

Seeing an error about the group not being found?

Double-check that the group names match exactly what you created in the previous project: IT-Admins, HR-Staff, Finance-Team. Group names are case-sensitive in icacls commands.

Verify your groups still exist by running Get-ADGroup -Filter * and comparing the output to the names in your commands.

Help me fix the group not found error in icacls.

Verify the NTFS permissions are correct

Before moving on, you should confirm that each folder has exactly the permissions you intended. The Get-Acl cmdlet displays the access control list for a folder.

  • Check the permissions on each department folder by running:
# Verify permissions on each department folder
Get-Acl C:\Shares\IT | Format-List
Get-Acl C:\Shares\HR | Format-List
Get-Acl C:\Shares\Finance | Format-List

What should I see?

For each folder, the Access field should show exactly two entries. The first is Administrators with Full Control. The second is the department group (for example, CORP\IT-Admins) with Modify access.

If you see additional entries like BUILTIN\Users or NT AUTHORITY\SYSTEM, the inheritance removal did not complete correctly. Re-run the icacls /inheritance:r command for that folder.

  • Confirm each folder shows only Administrators and its department group.

Seeing extra permissions you did not set?

Run icacls "C:\Shares\IT" /inheritance:r again to ensure inheritance is fully removed. Then run the Get-Acl command again to verify.

Help me clean up unexpected NTFS permissions.

Your folder structure is locked down. Each department folder is accessible only by its matching AD group and Administrators. Next up, you will expose these folders over the network by creating SMB shares.

Create SMB Shares Tied to AD Groups

Your department folders are locked down with NTFS permissions, but right now they are only accessible locally on DC01. To make them available across the network, you need to share them using the SMB protocol.

In this step, you will create SMB shares for each department folder and configure them so that WS01 can access them over the network. The share-level permissions will be broad (Authenticated Users with Change access), and NTFS will handle the granular restriction per department.

In this step, get ready to:
  • Create three SMB shares (IT, HR, Finance) using PowerShell.
  • Verify the shares exist and test local access on DC01.
  • Enable the firewall rule for File and Printer Sharing and confirm WS01 can reach the shares.
Create three SMB shares for each department folder

SMB shares make folders accessible over the network using a UNC path like \\DC01\IT. You will set share-level permissions broadly and rely on the NTFS permissions you already configured to enforce who can actually read and write files.

  • Create all three department shares by running this script in your elevated PowerShell session on DC01:
# Create the IT department share
New-SmbShare -Name "IT" -Path "C:\Shares\IT" -ChangeAccess "Authenticated Users" -FullAccess "Administrators"

# Create the HR department share
New-SmbShare -Name "HR" -Path "C:\Shares\HR" -ChangeAccess "Authenticated Users" -FullAccess "Administrators"

# Create the Finance department share
New-SmbShare -Name "Finance" -Path "C:\Shares\Finance" -ChangeAccess "Authenticated Users" -FullAccess "Administrators"

What does this code do?

Each New-SmbShare command creates a network share for one department folder.

  • -Name sets the share name that appears on the network (e.g. \\DC01\IT).
  • -Path points to the local folder the share exposes.
  • -ChangeAccess "Authenticated Users" grants any domain-authenticated user Change access at the share level.
  • -FullAccess "Administrators" gives admins full control at the share level.

Why grant Authenticated Users at the share level?

When both share permissions and NTFS permissions are in play, the most restrictive of the two wins. By setting the share level broadly, you let NTFS be the single control point for granular access.

This is the standard approach in enterprise environments. It avoids the complexity of mirroring permissions at both layers and makes troubleshooting straightforward.

  • You should see output confirming each share was created, showing the share name, path, and description columns.

Seeing an error about the share already existing?

If you ran the commands before and are trying again, the shares already exist. Remove them first with Remove-SmbShare -Name "IT" -Force (repeat for HR and Finance), then re-run the creation commands.

Help me troubleshoot this issue

Verify the shares and test local access
  • Confirm all three shares appear by running:
# List all SMB shares on this server
Get-SmbShare
  • You should see IT, HR, and Finance in the list alongside the default shares (like C$ and ADMIN$).
  • Test local access to one of the shares by running:
# Test that the IT share is accessible locally
Test-Path \\localhost\IT
  • You should see True returned, confirming the share is reachable from DC01 itself.

Test-Path returns False?

Double-check that the share name matches exactly by reviewing the Get-SmbShare output. The share name is case-insensitive but must match the name you created.

Also confirm the Server service is running by running Get-Service LanmanServer. Its status should be Running.

Help me troubleshoot this

Enable the firewall rule and verify WS01 can reach the shares

For WS01 to connect to DC01's shares over the network, the Windows Firewall on DC01 must allow SMB traffic through. The built-in File and Printer Sharing rule group handles this.

  • Enable the File and Printer Sharing firewall rules on DC01 by running:
# Enable File and Printer Sharing through the firewall
Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True

What does this command do?

This enables all firewall rules in the "File and Printer Sharing" display group, which opens the ports needed for SMB communication (primarily port 445). Without these rules enabled, WS01's connection attempts would be silently dropped by the firewall.

  • Now switch to your WS01 VM.
  • Log into WS01 as CORP\Administrator (a domain admin account).
  • Open PowerShell and verify WS01 can reach the IT share by running:
# Test connectivity to the IT share from WS01
Test-Path \\DC01\IT
  • You should see True returned, confirming WS01 can access the shares over the network.

Test-Path returns False from WS01?

  • Verify DC01 is reachable by running ping DC01 from WS01. If this fails, check that both VMs are on the same virtual network in VirtualBox.
  • Confirm the firewall rule took effect on DC01 by running Get-NetFirewallRule -DisplayGroup "File and Printer Sharing" | Select-Object DisplayName, Enabled and checking that the rules show True.
  • Make sure you are logged into WS01 with a domain account (CORP\Administrator), not a local account.

Help me troubleshoot network share connectivity

Your file shares are live and accessible across the network. Next up, you will use Group Policy Preferences to automatically map these shares as network drives based on each user's group membership.

Map Network Drives via Group Policy Preferences

Your SMB shares are live on DC01, but expecting users to manually type UNC paths every time they need a file is impractical. In an enterprise environment, users expect their department drives to just appear when they log in.

Group Policy Preferences can automatically map network drives the moment users log in. By combining drive map items with item-level targeting, each user only sees drives for their own department.

In this step, get ready to:
  • Create and link a "Department Drive Maps" GPO to the corp.local domain.
  • Configure three drive map items with item-level targeting for each department group.
  • Force a policy update on WS01 and verify the GPO is applied.
Create the Department Drive Maps GPO

A Group Policy Object (GPO) is a container for policy settings that Windows pushes to domain-joined computers and users. You will create a new GPO specifically for drive mappings and link it to the entire corp.local domain.

  • On DC01, open the Run dialog by pressing Win+R.
  • Type gpmc.msc and press Enter to open the Group Policy Management Console.
  • In the console tree on the left, expand Forest: corp.local.
  • Expand Domains.
  • Expand corp.local.
  • Right-click corp.local and select Create a GPO in this domain, and Link it here....
  • In the New GPO dialog box, type Department Drive Maps as the name.
  • Click OK.

The new GPO appears under corp.local in the left pane. It is already linked to the domain because you used the "Create and Link" option.

What is a GPO?

A Group Policy Object is a set of rules that Windows Server pushes to domain-joined computers and users. By linking the GPO at the domain level, every user who logs into any workstation in corp.local will process this GPO's settings.

The item-level targeting you configure next ensures only members of the correct group actually receive each drive mapping.

Why Group Policy Preferences instead of logon scripts?

Logon scripts require writing and maintaining batch files or PowerShell scripts. Group Policy Preferences provide a GUI-driven alternative that integrates directly with AD security groups through item-level targeting. No scripting knowledge is required, and the mappings are easier to audit and update.

Don't see corp.local in the tree?

Make sure you are logged into DC01 as CORP\Administrator. If the domain does not appear, close GPMC and reopen it. The console must connect to your domain controller to display the domain tree.

help me troubleshoot why corp.local is not showing in Group Policy Management Console

Configure drive map items with item-level targeting

Each department needs its own drive map item. You will create three items inside this GPO, each pointing to a different SMB share and restricted to the matching AD security group using item-level targeting.

  • In the Group Policy Management console, find the Department Drive Maps GPO you just created under corp.local.
  • Right-click Department Drive Maps and select Edit.
  • In the left pane of the Group Policy Management Editor, expand User Configuration.
  • Expand Preferences.
  • Expand Windows Settings.
  • Click Drive Maps.

Now you will create the first drive map for the IT department (H: drive).

  • Right-click Drive Maps, point to New, and select Mapped Drive.
  • In the New Drive Properties dialog, set the Action dropdown to Replace.
  • In the Location field, type \\DC01\IT.
  • Under Drive Letter, select Use.
  • Choose H: from the drive letter dropdown.
  • Click the Common tab at the top of the dialog.
  • Check the box for Item-level targeting.
  • Click the Targeting... button.
  • In the Targeting Editor, click New Item and select Security Group.
  • Click the ... (browse) button next to the Group field.
  • Type IT-Admins in the object name field.
  • Click Check Names.
  • Click OK to confirm the group selection.
  • Click OK to close the Targeting Editor.
  • Click OK to close the New Drive Properties dialog.

Why use Replace instead of Create?

The Replace action deletes any existing mapping on that drive letter and recreates it with the configured settings. This ensures the mapping is always correct, even if a user previously had a stale or incorrect mapping on that letter.

If the mapping does not exist yet, Replace creates it from scratch. This makes Replace the safest default for drive map items.

Now create the second drive map for the HR department (I: drive).

  • Right-click Drive Maps, point to New, and select Mapped Drive.
  • Set the Action to Replace.
  • In the Location field, type \\DC01\HR.
  • Under Drive Letter, select Use.
  • Choose I: from the dropdown.
  • Click the Common tab.
  • Check the box for Item-level targeting.
  • Click Targeting....
  • Click New Item and select Security Group.
  • Click the ... (browse) button next to the Group field.
  • Type HR-Staff in the object name field.
  • Click Check Names.
  • Click OK to confirm the group selection.
  • Click OK to close the Targeting Editor.
  • Click OK to close the Drive Properties dialog.

Finally, create the third drive map for the Finance department (J: drive).

  • Right-click Drive Maps, point to New, and select Mapped Drive.
  • Set the Action to Replace.
  • In the Location field, type \\DC01\Finance.
  • Under Drive Letter, select Use.
  • Choose J: from the dropdown.
  • Click the Common tab.
  • Check the box for Item-level targeting.
  • Click Targeting....
  • Click New Item and select Security Group.
  • Click the ... (browse) button next to the Group field.
  • Type Finance-Team in the object name field.
  • Click Check Names.
  • Click OK to confirm the group selection.
  • Click OK to close the Targeting Editor.
  • Click OK to close the Drive Properties dialog.

You should now see three drive map items listed in the right pane of the Group Policy Management Editor under Drive Maps.

What is item-level targeting?

Item-level targeting lets you apply individual preference items to only certain users or computers within the GPO's scope. You are using Security Group targeting so that only members of IT-Admins get the H: drive, only HR-Staff get the I: drive, and only Finance-Team get the J: drive.

Without item-level targeting, every user in the domain would receive all three drive mappings regardless of their department.

Check Names not finding your group?

Make sure you are typing the exact group name as it appears in Active Directory (IT-Admins, HR-Staff, Finance-Team). The search is case-insensitive but requires the full name. If the group is not found, verify it still exists by running Get-ADGroup -Filter * in PowerShell on DC01.

help me troubleshoot why Check Names cannot find my AD security group in Group Policy targeting

Force a policy update and verify on WS01

Group Policy refreshes automatically every 90 minutes, but you can force an immediate update on WS01 to test your GPO right away.

  • Switch to the WS01 VM.
  • Log in as any domain user (for example, CORP\mjohnson).
  • Press the Windows key, type cmd, and press Enter to open a Command Prompt.
  • Force a Group Policy update by running this command:
gpupdate /force

What does this command do?

The gpupdate /force command tells Windows to immediately re-download and apply all Group Policy settings from the domain controller. Without the /force flag, Windows only applies policies that have changed since the last refresh.

  • Wait for the command to report that both Computer Policy and User Policy updates have completed successfully.
  • Verify the GPO was applied by running this command:
gpresult /r
  • Scroll through the output and look under the USER SETTINGS section.
  • Find Applied Group Policy Objects.
  • Confirm that Department Drive Maps appears in the list.

What does gpresult /r show?

This command displays which GPOs are currently applied to the user and the computer. If your GPO appears under Applied Group Policy Objects, it means the drive map settings are active and will process at the next logon.

Department Drive Maps not appearing in gpresult?

Make sure you linked the GPO to the corp.local domain (not just created it under Group Policy Objects without linking). In GPMC on DC01, check that Department Drive Maps appears directly under the corp.local node with a link icon.

Also try logging off and back on to WS01. User-targeted GPP items like drive maps apply at logon, not just at gpupdate.

help me troubleshoot why my Department Drive Maps GPO is not appearing in gpresult on WS01

Your drive mappings are now configured and the GPO is live. Next up, you will log in as different department users on WS01 to prove that each user only sees their own department's mapped drive.

Test Access Control from WS01

Your file server is configured, your permissions are set, and your Group Policy is live. Now it is time to prove that everything actually works.

In this step, you will log into WS01 as different department users and verify that each user can only see and access their own department's resources. This is the moment where all the pieces come together.

In this step, get ready to:
  • Log in as an HR user and confirm only the HR drive appears.
  • Attempt direct access to another department's share and get denied.
  • Log in as an IT user and confirm read/write access to the IT share.
Log in as mjohnson and verify the HR drive mapping

Your first test uses an HR department user. If your permissions and Group Policy are correct, mjohnson should only see the HR drive mapped.

  • On WS01, sign out of the current session by clicking **Start**, then clicking the user icon, then selecting **Sign out**.
  • At the Windows login screen, click **Other user** in the bottom left.
  • Enter CORP\mjohnson as the username.
  • Enter P@ssw0rd2024 as the password and press **Enter**.
  • Wait for the desktop to load. The first login may take a minute while the user profile is created.

Why sign out instead of switch user?

Signing out completely clears the previous user's security token. This ensures the Group Policy Preferences drive maps are evaluated fresh for the new user's group memberships.

  • Open **File Explorer** by clicking the folder icon in the taskbar, or pressing **Win+E**.
  • In the left sidebar, look under **This PC** for mapped network drives.

You should see drive I: mapped to \\DC01\HR. Drives H: and J: should NOT appear because mjohnson is not a member of IT-Admins or Finance-Team.

  • Double-click the I: drive to open it.
  • Confirm you can see the test file inside the HR folder.

Don't see the I: drive?

Make sure you signed out and signed back in (not just locked the screen). Group Policy Preferences drive maps are applied at logon.

Try running gpupdate /force in a Command Prompt, then sign out and sign back in. Also verify mjohnson is in the HR-Staff group by checking on DC01.

Help me troubleshoot why my GPP drive map is not appearing for mjohnson on WS01.

Confirm access denied when accessing another department's share

Seeing the correct drive mapped is only half the test. You also need to prove that mjohnson cannot reach shares belonging to other departments, even when accessing them directly.

  • While still logged in as CORP\mjohnson on WS01, click the address bar in **File Explorer**.
  • Type \\DC01\IT and press **Enter**.

You should see an access denied error. This confirms that NTFS permissions are blocking mjohnson because the account is not in the IT-Admins group.

Why does this work?

Two layers of permissions protect each share. At the share level, Authenticated Users have Change access, so mjohnson passes that gate. At the NTFS level, only IT-Admins have Modify access to the IT folder.

Since the most restrictive permission wins, mjohnson is denied. This is exactly why the industry best practice is to control granular access through NTFS while keeping share permissions broad.

  • Try the same test with \\DC01\Finance in the address bar to confirm it is also denied.

Not getting access denied?

If you can open the IT or Finance folder as mjohnson, the NTFS permissions were not applied correctly. Return to DC01 and run Get-Acl C:\Shares\IT | Format-List to check which groups have access.

Confirm that inherited permissions were removed in Step 2. If the Users group or Everyone still has access, that is the cause.

Help me figure out why mjohnson can access a share they should be blocked from.

Log in as jsmith and verify IT access with read/write

The final test switches to an IT department user. You will confirm that jsmith gets the IT drive, can create files in it, and is blocked from other departments.

  • Sign out of the mjohnson session on WS01 by clicking **Start**, then the user icon, then **Sign out**.
  • At the login screen, click **Other user**.
  • Enter CORP\jsmith as the username.
  • Enter P@ssw0rd2024 as the password and press **Enter**.
  • Wait for the desktop to load.
  • Open **File Explorer** with **Win+E**.
  • Under **This PC**, confirm drive H: is mapped to \\DC01\IT.
  • Double-click the H: drive and confirm the test file is visible.

Now verify that jsmith has full read/write access to the IT share.

  • Right-click inside the H: drive window, select **New**, then **Text Document**.
  • Name the file jsmith-test.txt and press **Enter**.
  • Confirm the file is created without errors. This proves jsmith has Modify permissions on the IT share.

Finally, confirm jsmith is blocked from other departments.

  • Click the address bar in File Explorer and type \\DC01\HR, then press **Enter**.
  • Confirm you see an access denied error. jsmith is in IT-Admins but not in HR-Staff, so NTFS blocks the access.

What did you just prove?

You have verified end-to-end access control. Each user gets only their department's drive mapped automatically through Group Policy Preferences. Even if they try to access another share directly, NTFS permissions block them.

This is exactly how enterprise IT teams manage shared file access. Membership in an Active Directory security group is the single control point. Add a user to a group, and they automatically get the drive and permissions. Remove them, and access disappears after their next logon.

jsmith can access the HR share?

Check whether jsmith was accidentally added to the HR-Staff group in the previous project. On DC01, run Get-ADGroupMember -Identity "HR-Staff" and confirm jsmith is not listed.

Also verify the NTFS permissions on C:\Shares\HR to ensure inherited permissions were removed.

Help me troubleshoot why jsmith can access a share restricted to HR-Staff.

Secret mission

Enable Access-Based Enumeration

Right now, users who browse a shared folder can see the names of subfolders they cannot open. Access-Based Enumeration hides those folders entirely, so users never even know they exist. Can you harden all three department shares and prove it works?

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 on your local VirtualBox VMs with free evaluation licenses. There are no ongoing cloud costs.

Resources you used:

  • File Server role (FS-FileServer) installed on DC01.
  • SMB shares on DC01: IT, HR, Finance, and Departments (if you completed the Secret Mission).
  • GPO "Department Drive Maps" linked to corp.local.
  • Folder structure at C:\Shares on DC01.
  • File and Printer Sharing firewall rule enabled on DC01.

Keep everything running

No action needed. Choose this if you are still actively building on your file server lab or plan to extend it further.

  • Your file server configuration, shares, GPO, and folder structure remain intact on DC01.
  • All drive mappings and NTFS permissions stay active for any domain user who logs into WS01.
  • You can continue experimenting by adding new department folders, groups, or users at any time.

Pause - I'll come back to this later

Shut down both VMs cleanly to free up system memory and CPU. Everything will be preserved for next time.

  • On DC01, click the Start menu and select Shut down.
  • On WS01, click the Start menu and select Shut down.
  • When you return, start both VMs in VirtualBox. DC01 should start first so the domain controller is available when WS01 boots.

Delete - I don't want to use this again

Remove both VMs entirely to reclaim disk space. This deletes everything from the AD lab including your file server configuration.

  • Shut down both DC01 and WS01 if they are still running.
  • In VirtualBox Manager, right-click WS01 and select Remove. Choose Delete all files to remove the virtual disk.
  • Right-click DC01 and select Remove. Choose Delete all files to remove the virtual disk.
  • This removes all resources listed above: the File Server role, SMB shares, GPO, folder structure, and firewall rule. These all lived on the DC01 VM.

This follows the same process from your previous project

If you completed the "Build an Active Directory Domain" cleanup, you already know these steps. The process is the same. Deleting both VMs removes the entire lab environment including everything you built in this project.

Nice Work!

Nice Work!

You just built a production-style file server integrated with Active Directory that enforces department-level access control through security groups and delivers mapped drives automatically via Group Policy.

You've learned how to:

  • Configured NTFS permissions tied to AD security groups (IT-Admins, HR-Staff, Finance-Team) to enforce least-privilege access on department shared folders.
  • Created SMB shares with Authenticated Users at the share level, letting NTFS handle granular restrictions.
  • Used Group Policy Preferences with item-level targeting to automatically map department drives (H:, I:, J:) based on user group membership.
  • Secret Mission: Enabled Access-Based Enumeration to hide folders from users who lack permissions, hardening the file server for production use.

Ready to quiz yourself?