How to Configure SMB File Shares and NTFS Permissions on Windows Server 2025

How to Configure SMB File Shares and NTFS Permissions on Windows Server 2025

Shared folders are at the heart of almost every Windows Server deployment. Getting the permission model right is not optional — a misconfigured share can expose confidential data, allow unintended writes, or prevent legitimate users from doing their jobs. Windows Server 2025 uses two independent but cooperative permission layers: SMB share permissions that control who can connect over the network, and NTFS permissions that control what an authenticated user can actually do with files and folders on disk. When both layers are in play, the effective access a user receives is always the most restrictive of the two. This tutorial walks through creating and securing SMB shares with the correct NTFS ACLs, enabling SMB3 encryption, configuring access-based enumeration, and auditing file access — all from PowerShell.

Prerequisites

• Windows Server 2025 with the File and Storage Services role installed (installed by default)
• An NTFS-formatted volume to host the share (e.g., D:Shares)
• A domain environment with Active Directory users and groups (or local accounts for workgroup scenarios)
• PowerShell 7+ or Windows PowerShell 5.1 running as Administrator
• The SmbShare module (built into Windows Server 2025)

Step 1: Create the Folder Structure

Before creating the SMB share, create the underlying folder on an NTFS volume. In this example the share will hold departmental data for the Finance team.

# Create the root share folder and a sub-folder for Finance
New-Item -ItemType Directory -Path "D:SharesFinance" -Force
New-Item -ItemType Directory -Path "D:SharesFinanceReports" -Force
New-Item -ItemType Directory -Path "D:SharesFinanceInvoices" -Force

Keeping a clean folder hierarchy makes it much easier to apply granular NTFS permissions later. Always create sub-folders even if they are empty at this stage — the ACLs you set now will be inherited by all child objects.

Step 2: Create the SMB Share with New-SmbShare

Use New-SmbShare to publish the folder over SMB. The best practice for share permissions is to grant Everyone or a broad group Change access at the share level and let NTFS permissions handle the fine-grained control. This avoids the confusion that arises when two restrictive layers conflict.

# Create the Finance share
New-SmbShare `
    -Name "Finance" `
    -Path "D:SharesFinance" `
    -Description "Finance department shared data" `
    -FullAccess "DOMAINFinance-Admins" `
    -ChangeAccess "DOMAINFinance-Users" `
    -ReadAccess "DOMAINFinance-Auditors" `
    -FolderEnumerationMode AccessBased `
    -CachingMode None `
    -EncryptData $true

# Verify the share was created
Get-SmbShare -Name "Finance" | Format-List

Key parameters explained:

• -FullAccess: Grants Full Control at the share level (read, write, change permissions, take ownership). Restrict this to administrative groups only.
• -ChangeAccess: Grants Change permission — users can read, write, and delete files but cannot change share-level permissions.
• -ReadAccess: Read-only network access.
• -FolderEnumerationMode AccessBased: Enables Access-Based Enumeration (ABE). Users only see files and folders they have NTFS read access to, which dramatically reduces information disclosure risk.
• -EncryptData $true: Enables per-share SMB3 encryption, protecting data in transit even on internal networks.

Step 3: Modify an Existing Share with Set-SmbShare

If you need to change share settings after creation — for example to enable encryption on an existing share or update its description — use Set-SmbShare rather than deleting and recreating it.

# Enable encryption on an existing share without recreating it
Set-SmbShare -Name "Finance" -EncryptData $true -Confirm:$false

# Change the description
Set-SmbShare -Name "Finance" -Description "Finance data — encrypted, ABE enabled" -Confirm:$false

# Verify
Get-SmbShare -Name "Finance" | Select-Object Name, EncryptData, FolderEnumerationMode, Description

Step 4: Configure NTFS Permissions with icacls

NTFS permissions are the true security boundary. At this stage you typically want to remove broad default permissions (e.g., Users having inherited Full Control from the drive root) and apply least-privilege ACEs.

# Disable inheritance and convert inherited ACEs to explicit ones
icacls "D:SharesFinance" /inheritance:d

# Remove the default Users group permission if present
icacls "D:SharesFinance" /remove:g "BUILTINUsers"

# Grant Finance-Admins Full Control with inheritance to all child objects (OI)(CI)
icacls "D:SharesFinance" /grant "DOMAINFinance-Admins:(OI)(CI)F"

# Grant Finance-Users Modify (read/write/delete) with inheritance
icacls "D:SharesFinance" /grant "DOMAINFinance-Users:(OI)(CI)M"

# Grant Finance-Auditors Read & Execute only
icacls "D:SharesFinance" /grant "DOMAINFinance-Auditors:(OI)(CI)RX"

# SYSTEM and local Administrators always need Full Control for backups and management
icacls "D:SharesFinance" /grant "NT AUTHORITYSYSTEM:(OI)(CI)F"
icacls "D:SharesFinance" /grant "BUILTINAdministrators:(OI)(CI)F"

# Verify the resulting ACL
icacls "D:SharesFinance"

Inheritance flags: (OI) means Object Inherit — the ACE applies to files within this folder. (CI) means Container Inherit — the ACE applies to sub-folders. Using both ensures all new files and folders created inside D:SharesFinance automatically receive the correct permissions without manual intervention.

Step 5: Apply Granular NTFS Permissions to Sub-Folders

The Reports sub-folder should be readable by Finance-Auditors but writable only by Finance-Managers. The Invoices folder should be writable only by Accounts-Payable. Apply additional scoped ACEs on top of the inherited ones:

# Reports: add Finance-Managers with Modify (they already inherit from parent but let's be explicit)
icacls "D:SharesFinanceReports" /grant "DOMAINFinance-Managers:(OI)(CI)M"

# Invoices: grant Accounts-Payable Modify; restrict Finance-Users from writing here
# First apply a Deny Write on Finance-Users for Invoices specifically
icacls "D:SharesFinanceInvoices" /grant "DOMAINAccounts-Payable:(OI)(CI)M"
icacls "D:SharesFinanceInvoices" /deny  "DOMAINFinance-Users:(W)"

# Review final ACLs
icacls "D:SharesFinanceInvoices"

Important: Deny ACEs always override Allow ACEs at the same or higher level. Use Deny sparingly and only when you cannot achieve the desired result by removing an Allow entry, as Deny rules are easy to misread during future audits.

Step 6: Enable SMB3 Server-Wide Encryption

If your environment mandates that all SMB traffic be encrypted regardless of per-share settings, enable encryption at the server level. Note that clients must support SMB 3.0 or higher (Windows 8 / Server 2012 and later).

# Enable encryption for all shares on this server
Set-SmbServerConfiguration -EncryptData $true -Confirm:$false

# Reject unencrypted client connections (SMB 1 and older SMB 3 clients without encryption support)
Set-SmbServerConfiguration -RejectUnencryptedAccess $true -Confirm:$false

# Verify
Get-SmbServerConfiguration | Select-Object EncryptData, RejectUnencryptedAccess

Step 7: Configure File Access Auditing via SACL

Auditing writes to the Security Event Log whenever a user accesses (or fails to access) files in the share. You must enable object access auditing in Group Policy and then configure a System Access Control List (SACL) on the folder.

# Enable object access auditing via the local audit policy (use GPO in production)
auditpol /set /subcategory:"File System" /success:enable /failure:enable

# Add an audit rule using PowerShell's .NET ACL classes
$folder    = "D:SharesFinance"
$acl       = Get-Acl -Path $folder -Audit

# Audit all Finance-Users: log Success and Failure for Write operations
$identity  = [System.Security.Principal.NTAccount]"DOMAINFinance-Users"
$rights    = [System.Security.AccessControl.FileSystemRights]"Write, Delete, ChangePermissions"
$inherit   = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit, ObjectInherit"
$propagate = [System.Security.AccessControl.PropagationFlags]"None"
$auditType = [System.Security.AccessControl.AuditFlags]"Success, Failure"

$auditRule = New-Object System.Security.AccessControl.FileSystemAuditRule(
    $identity, $rights, $inherit, $propagate, $auditType
)

$acl.AddAuditRule($auditRule)
Set-Acl -Path $folder -AclObject $acl

Write-Host "Audit SACL applied. Events will appear in Security Log (Event ID 4663)."

After applying the SACL, test by writing and deleting a file as a Finance-Users member, then check Event Viewer under Windows Logs → Security for Event ID 4663 (file system access) and 4656 (object handle requested).

Step 8: Verify Share Connectivity and Permissions

# List all active SMB sessions to the Finance share
Get-SmbSession | Where-Object { $_.ShareName -eq "Finance" } | Format-Table

# List open files on the share
Get-SmbOpenFile | Where-Object { $_.ShareName -eq "Finance" } | Format-Table

# Test that the share is accessible from a remote machine (run on the client)
Test-NetConnection -ComputerName FS01 -Port 445

# Map a drive to verify (run on client)
New-PSDrive -Name Z -PSProvider FileSystem -Root "\FS01Finance" -Credential (Get-Credential)

Conclusion

Properly configured SMB shares on Windows Server 2025 combine three defensive layers: SMB share permissions that set the ceiling for network access, NTFS ACLs that enforce the real least-privilege boundary at the file system level, and SMB3 encryption that protects data crossing the wire. By applying Access-Based Enumeration you also prevent users from discovering folders they cannot read — a simple but effective information-hiding measure. Adding a SACL on sensitive directories ensures that any access — successful or not — is logged to the Security Event Log, giving your security team the visibility they need for incident response and compliance. Revisit your share ACLs regularly; user roles change, projects end, and stale permissions are one of the most common sources of privilege creep in Windows environments.