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

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

Windows Server 2022 continues to be the backbone of enterprise file sharing through the Server Message Block (SMB) protocol. Properly configuring SMB shares alongside NTFS permissions is one of the most critical administrative tasks you will perform. The two permission systems work in tandem, and understanding how they interact—particularly the “most restrictive wins” rule—is essential for building a secure and functional file server environment. This guide walks through creating shares, assigning both layers of permissions, enabling security features like SMB signing and encryption, and auditing file access.

Understanding the Two Permission Layers

Every SMB file share on Windows Server 2022 applies two independent permission sets. The first is the SMB share permission, which controls access at the network level and applies only when connecting via the network. The second is the NTFS permission, which is enforced by the file system itself and applies to both local and network access. When a user connects over the network, Windows evaluates both permission sets and grants only the access allowed by the more restrictive of the two. For example, if SMB grants Full Control but NTFS grants Read, the effective access is Read.

A common best practice is to set the SMB share permission to Full Control for the Everyone or Authenticated Users group, then use NTFS permissions alone to control granular access. This simplifies administration because you manage one set of permissions rather than maintaining both in parallel.

Installing the File Server Role

Before creating shares, ensure the File Server role service is installed. On Server 2022, this is part of the File and Storage Services role:

Install-WindowsFeature -Name FS-FileServer -IncludeManagementTools

Verify the installation completed successfully:

Get-WindowsFeature -Name FS-FileServer

Creating SMB Shares with New-SmbShare

The New-SmbShare cmdlet creates a new SMB share from a PowerShell prompt. The minimum parameters required are the share name and the local path. You can also specify share-level permissions, description, and various behavioral settings in a single command.

Create a basic share with a description and grant full control to Authenticated Users at the share level:

New-SmbShare -Name "Finance" `
             -Path "D:SharesFinance" `
             -Description "Finance department shared files" `
             -FullAccess "CONTOSODomain Admins" `
             -ChangeAccess "CONTOSOFinance_Users" `
             -ReadAccess "CONTOSOFinance_Auditors" `
             -FolderEnumerationMode AccessBased

The -FolderEnumerationMode AccessBased parameter enables Access-Based Enumeration (ABE), which hides files and folders from users who do not have at least Read permission to them. This prevents users from seeing the existence of resources they cannot access, which is an important security and usability feature in multi-department file servers.

To verify the share was created:

Get-SmbShare -Name "Finance" | Format-List *

To list all current shares on the server:

Get-SmbShare | Select-Object Name, Path, Description, FolderEnumerationMode

Modifying Share Properties with Set-SmbShare

After a share is created, use Set-SmbShare to modify its properties without recreating it. For example, to enable ABE on an existing share and require encryption:

Set-SmbShare -Name "Finance" `
             -FolderEnumerationMode AccessBased `
             -EncryptData $true `
             -Confirm:$false

To change the share-level permissions, use Grant-SmbShareAccess and Revoke-SmbShareAccess:

# Grant change access to a new group
Grant-SmbShareAccess -Name "Finance" `
                     -AccountName "CONTOSOFinance_Managers" `
                     -AccessRight Change `
                     -Confirm:$false

# Revoke access from a group
Revoke-SmbShareAccess -Name "Finance" `
                      -AccountName "CONTOSOFinance_Auditors" `
                      -Confirm:$false

Configuring NTFS Permissions with icacls

NTFS permissions provide the granular, file-system-level access control. The command-line tool icacls is reliable and scriptable for bulk permission assignments. The following example configures the Finance folder with appropriate permissions:

# Remove inherited permissions and set explicit permissions
icacls "D:SharesFinance" /inheritance:r

# Grant Full Control to Domain Admins
icacls "D:SharesFinance" /grant "CONTOSODomain Admins:(OI)(CI)F"

# Grant Modify (read, write, delete) to Finance_Users
icacls "D:SharesFinance" /grant "CONTOSOFinance_Users:(OI)(CI)M"

# Grant Read & Execute to Finance_Auditors
icacls "D:SharesFinance" /grant "CONTOSOFinance_Auditors:(OI)(CI)RX"

# Grant Read-only to HR_Viewers
icacls "D:SharesFinance" /grant "CONTOSOHR_Viewers:(OI)(CI)R"

The flags (OI) (Object Inherit) and (CI) (Container Inherit) ensure permissions propagate to all files and subfolders. The permission codes are: F = Full Control, M = Modify, RX = Read & Execute, R = Read, W = Write.

Verify the current NTFS permissions on a folder:

icacls "D:SharesFinance"

Managing NTFS Permissions with PowerShell (Get-Acl / Set-Acl)

PowerShell provides a more programmatic approach using Get-Acl and Set-Acl. This is especially useful when you need to copy permissions from one folder to another or build complex ACL configurations in scripts:

# Read existing ACL
$acl = Get-Acl -Path "D:SharesFinance"

# Create a new access rule
$identity = "CONTOSOFinance_Managers"
$rights = [System.Security.AccessControl.FileSystemRights]"Modify"
$inheritance = [System.Security.AccessControl.InheritanceFlags]"ContainerInherit, ObjectInherit"
$propagation = [System.Security.AccessControl.PropagationFlags]"None"
$type = [System.Security.AccessControl.AccessControlType]"Allow"

$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    $identity, $rights, $inheritance, $propagation, $type
)

# Add the rule and apply it
$acl.AddAccessRule($rule)
Set-Acl -Path "D:SharesFinance" -AclObject $acl

To copy NTFS permissions from one folder to another:

$sourceAcl = Get-Acl -Path "D:SharesFinance"
Set-Acl -Path "D:SharesFinance_Archive" -AclObject $sourceAcl

Disabling SMBv1

SMBv1 is a legacy protocol with well-documented security vulnerabilities including EternalBlue, which was exploited by WannaCry and NotPetya ransomware. On Windows Server 2022 SMBv1 is disabled by default, but you should verify and explicitly enforce this in your environment:

# Check current SMBv1 state
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol

# Disable SMBv1 if somehow enabled
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Confirm:$false

# Also remove the SMBv1 feature to reduce attack surface
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

Enabling SMB Signing

SMB signing ensures that each packet in an SMB communication session is digitally signed, preventing man-in-the-middle attacks where an attacker could intercept and modify SMB traffic. On Windows Server 2022, SMB signing is enabled by default for domain controllers. For all file servers, you should require signing:

# Require SMB signing on the server (clients must sign)
Set-SmbServerConfiguration -RequireSecuritySignature $true -Confirm:$false

# Enable signing on the server (sign if client requests it)
Set-SmbServerConfiguration -EnableSecuritySignature $true -Confirm:$false

# Verify the current signing configuration
Get-SmbServerConfiguration | Select-Object RequireSecuritySignature, EnableSecuritySignature

Note: If you require signing on the server, all clients connecting to it must also support and enable SMB signing. Modern Windows clients (Windows 10/11, Server 2016+) support this by default.

Enabling SMB Encryption

SMB Encryption (available since SMB 3.0) encrypts SMB data in transit, providing protection against eavesdropping on networks where you cannot guarantee physical security (e.g., branch offices, cloud-connected sites). Encryption can be enabled per-share or globally for all shares:

# Enable encryption for a specific share
Set-SmbShare -Name "Finance" -EncryptData $true -Confirm:$false

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

# Verify encryption status per share
Get-SmbShare | Select-Object Name, EncryptData

# Verify global encryption setting
Get-SmbServerConfiguration | Select-Object EncryptData, RejectUnencryptedAccess

When global encryption is enabled, the RejectUnencryptedAccess setting (default: $true) will deny connections from clients that cannot support SMB encryption. Clients must be running Windows 8/Server 2012 or later to support SMB 3.0 encryption.

Configuring SMB Multichannel

SMB Multichannel allows a single SMB 3.x connection to use multiple network adapters simultaneously, providing both increased throughput and fault tolerance. Windows Server 2022 enables SMB Multichannel by default when multiple adapters are present. To verify and manage it:

# Check if Multichannel is enabled (server side)
Get-SmbServerConfiguration | Select-Object EnableMultiChannel

# Enable Multichannel if disabled
Set-SmbServerConfiguration -EnableMultiChannel $true -Confirm:$false

# Check active Multichannel connections
Get-SmbMultichannelConnection

# Check Multichannel constraints (RDMA, RSS capable interfaces)
Get-SmbMultichannelConstraint

Enabling Access-Based Enumeration (ABE)

ABE hides folders and files from users who do not have Read or higher permissions. Without ABE, a user browsing a share can see folders even if they cannot open them, which reveals sensitive information about your directory structure. Enable ABE on existing shares:

# Enable ABE on a specific share
Set-SmbShare -Name "Finance" -FolderEnumerationMode AccessBased -Confirm:$false

# Enable ABE on all shares at once
Get-SmbShare | Where-Object {$_.Special -eq $false} | 
    Set-SmbShare -FolderEnumerationMode AccessBased -Confirm:$false

# Verify ABE status
Get-SmbShare | Select-Object Name, FolderEnumerationMode

Auditing File Access

File auditing records access events to the Security event log, which is essential for compliance and forensic investigation. You must configure auditing at two levels: Group Policy (what events to audit) and NTFS (which files/folders to audit).

First, enable object access auditing via Group Policy or locally:

# Enable auditing of object access (Success and Failure)
auditpol /set /subcategory:"File System" /success:enable /failure:enable

# Verify the setting
auditpol /get /subcategory:"File System"

Then configure NTFS audit entries on the folder using icacls:

# Audit all access by all users (success and failure) on Finance folder
icacls "D:SharesFinance" /audit "Everyone:(OI)(CI)(F)"

# Audit only failed access attempts
icacls "D:SharesFinance" /audit:f "Everyone:(OI)(CI)(F)"

Alternatively use PowerShell to set audit ACEs:

$acl = Get-Acl -Path "D:SharesFinance" -Audit
$auditRule = New-Object System.Security.AccessControl.FileSystemAuditRule(
    "Everyone",
    "FullControl",
    "ContainerInherit, ObjectInherit",
    "None",
    "Success, Failure"
)
$acl.AddAuditRule($auditRule)
Set-Acl -Path "D:SharesFinance" -AclObject $acl

File access events appear in the Windows Security event log under Event ID 4663 (An attempt was made to access an object) and Event ID 4656 (A handle to an object was requested). Use Event Viewer or PowerShell to query these:

Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4663]]" |
    Select-Object TimeCreated, Message -First 20

Viewing and Disconnecting Open Files and Sessions

Monitor who has files open and what sessions are active using the SMB cmdlets:

# View all open files on SMB shares
Get-SmbOpenFile | Select-Object FileId, SessionId, Path, ClientUserName, ClientComputerName

# View all active SMB sessions
Get-SmbSession | Select-Object SessionId, ClientUserName, ClientComputerName, NumOpens

# Close a specific open file (FileId from Get-SmbOpenFile)
Close-SmbOpenFile -FileId 17179869213 -Confirm:$false

# Disconnect a specific session
Close-SmbSession -SessionId 4294967297 -Confirm:$false

Summary

Windows Server 2022 provides a comprehensive set of tools for managing SMB file shares and NTFS permissions. The key principles are: set SMB share permissions permissively and use NTFS permissions for granular control; always disable SMBv1; enable SMB signing to prevent man-in-the-middle attacks; use SMB encryption for sensitive data; and enable ABE to improve both security and user experience. Combining regular permission audits with file access auditing gives you full visibility into how your file server is being used and by whom.