Windows Server · Lesson 11
Secure Windows file sharing by understanding how SMB share permissions and NTFS permissions combine, then apply least privilege without breaking required user or application access.
File-server security is not one permission screen. Ownership, inheritance, group membership, share access, NTFS access, and service dependencies all contribute to the final result.
Lesson Snapshot
Learning objectives
Explain the difference between share permissions and NTFS permissions on Windows Server.
Use File Explorer, Computer Management, Server Manager, and PowerShell to review SMB shares and folder permissions.
Understand ownership, inheritance, explicit permissions, inherited permissions, Allow, Deny, and effective access.
Recognize how share permissions and NTFS permissions combine for network access.
Apply least privilege without breaking required file access for users, groups, applications, or service accounts.
Verify required SMB access from an authorized client after any permission or share change.
Core concepts
A folder or resource published over the network through the Server Message Block protocol.
A permission applied at the SMB share layer that controls network access to the share.
A file-system permission applied to files and folders on an NTFS volume, whether access is local or through a share.
The owner of a file or folder can influence permission management and may be able to change access controls.
Allows child files and folders to receive permissions from a parent folder unless inheritance is changed.
The access a user actually receives after all applicable group memberships, NTFS permissions, share permissions, inheritance, and Deny rules are considered.
Core idea
A user connecting through SMB must satisfy the share layer and the NTFS layer. Troubleshooting only one side can lead to the wrong conclusion.
Permission warning
Service accounts, inherited groups, open files, and nested group memberships may depend on the current ACL.
Tool map
Right-click folder → Properties → Sharing / SecurityUse Sharing for share-related settings and Security for NTFS permissions.
Right-click folder → Properties → Security → AdvancedReview owner, inheritance, explicit permissions, inherited permissions, and effective access.
Win + R → compmgmt.msc → System Tools → Shared Folders → Shares / Sessions / Open FilesReview active shares, connected users, sessions, and open files.
Server Manager → File and Storage Services → SharesUseful for reviewing and managing SMB shares when File and Storage Services is installed.
Start → search PowerShell → Run as administrator when requiredUse Get-SmbShare, Get-SmbShareAccess, Get-Acl, and related commands for inspection.
Start → search Command Prompt → Run as administrator when requiredicacls can inspect and change NTFS permissions. Use changes only after documenting the original state.
Permission layers
Scope
Network access through the SMB share.
Examples
Read, Change, Full Control.
Share permissions do not replace NTFS permissions.
Scope
Files and folders on the disk, including local and network access.
Examples
Read, Write, Modify, Read & execute, Full control, special permissions.
NTFS usually provides the more detailed permission model.
Scope
Network users are constrained by both layers.
Examples
If share access is broader than NTFS, NTFS can still restrict the user.
Always inspect both layers when troubleshooting network access.
Common NTFS permissions
Allows reading file contents and basic folder information.
Allows reading plus executing programs and traversing folders where applicable.
Allows viewing file and folder names inside a directory.
Allows creating files or folders and writing data, depending on the inherited and advanced permissions.
Typically includes read, write, execute, and delete capabilities without full permission-control authority.
Includes broad data access plus permission and ownership-related control. Use only when truly required.
Share review
What share is required by the scenario?
What local folder path backs the share?
Which users or groups should have network access?
Which users or groups should be read-only?
Which users or groups need Modify access?
Does any application or service account depend on the folder?
What share permissions are currently configured?
What NTFS permissions are currently configured?
Are permissions inherited or explicit?
How will access be tested from an authorized client?
PowerShell and command-line inspection
Get-SmbShare | Select-Object Name, Path, Description, SpecialCreates an inventory of SMB shares and the paths they expose.
Get-SmbShare -Name "ShareName" | Format-List *Shows detailed properties for a specific SMB share.
Get-SmbShareAccess -Name "ShareName"Shows users or groups with Allow or Deny access at the share layer.
Get-Acl "C:\Path\To\Folder" | Format-ListShows owner and access-control information for a folder.
(Get-Acl "C:\Path\To\Folder").Access | Select-Object IdentityReference, FileSystemRights, AccessControlType, IsInheritedCreates a readable list of NTFS permission entries.
icacls "C:\Path\To\Folder"Shows NTFS permission entries using the built-in command-line tool.
Get-SmbSession | Select-Object ClientComputerName, ClientUserName, NumOpensShows current SMB clients and can reveal active dependencies before changes.
Get-SmbOpenFile | Select-Object ClientComputerName, ClientUserName, PathShows files currently open through SMB before disruptive changes.
Inheritance
Received from a parent folder. Inheritance helps keep permissions consistent across a tree.
Assigned directly to the file or folder and may differ from the parent.
Stops normal permission inheritance and should be done only when the folder truly needs a different access model.
Can turn inherited entries into explicit entries, preserving the current access while breaking the inheritance link.
Can immediately remove access for users and services that depended on the parent permissions.
Too many explicit exceptions make a folder tree difficult to understand and troubleshoot.
Deny guidance
A Deny entry can block access even when another group grants Allow, which makes troubleshooting more complex.
Prefer assigning access to well-defined groups rather than creating many user-specific entries.
Many environments can achieve least privilege by simply not granting unnecessary access.
A user may receive permissions through multiple groups, including nested domain groups.
Effective access
01
Know the exact local or domain identity whose access you are testing.
02
Identify groups that may grant or restrict access.
03
Check whether the identity or one of its groups is allowed or denied at the SMB share layer.
04
Check inherited and explicit NTFS permissions on the folder and relevant child objects.
05
Look for explicit or inherited Deny entries that may override expected access.
06
Use the actual network path and authorized account to prove the final result.
Secure design examples
All members of a department should read files but only one editing group should modify them.
Approach
Use domain groups for readers and editors, keep permissions group-based, and avoid granting Full Control to ordinary users.
Verify
Test reading with a reader account and creating/editing with an editor account.
A required service account needs Modify access, while normal users should have no direct access.
Approach
Grant the service identity only the rights it needs and avoid broad user-group access.
Verify
Confirm the application still writes data and an unauthorized user cannot browse the folder.
Administrators need full management rights, while users only need read access.
Approach
Separate administrative and user groups instead of granting Full Control broadly.
Verify
Test with one authorized administrator and one standard user.
Troubleshooting
Symptom
Check
Review share Change/Full Control access, NTFS Modify/Write permissions, inheritance, file-level ACLs, and any Deny entries.
Symptom
Check
Confirm the share exists, SMB service is available, firewall permits required access, the user is allowed at the share layer, NTFS permits access, and the network path is correct.
Symptom
Check
Review inheritance and whether changes were propagated to child objects. Restore the documented original ACL if needed.
Symptom
Check
Review the service account, required folder rights, executable/data paths, and application logs.
Symptom
Check
Review direct and nested group membership plus Allow and Deny entries. Use Advanced Security Effective Access when appropriate.
Symptom
Check
Check SMB share configuration, firewall rules, Server service, share permissions, network reachability, and client credentials.
High-risk situations
Broad Full Control can allow users to change permissions, delete data, or alter files beyond what the scenario requires.
Ownership changes can affect permission management and may disrupt applications or administrative workflows.
A single inheritance change can affect hundreds of child objects.
SYSTEM, Administrators, service identities, or application groups may be required.
Users may have open files and unsaved work. Review active sessions before disruptive changes.
Deny rules are powerful and can create confusing effective-access results.
Decision cases
The TeamDocs share is required, but the broad permission grants more access than the scenario needs.
The share must remain available while excessive privilege should be reduced.
Response
Document current share and NTFS permissions, identify required reader/editor groups, replace broad access with least-privilege group access, and verify from client accounts.
The account is not a human user and the folder supports a required application.
The account may be a legitimate application identity.
Response
Confirm the service or application dependency before removing access. Reduce rights only if the application can still function.
The user belongs to Editors but still cannot write.
A Deny entry or more restrictive NTFS permission may override the expected access.
Response
Review both share and NTFS permissions, nested groups, explicit Deny entries, and effective access before changing anything.
No one recognizes the share and there are no current sessions.
Lack of active sessions does not prove the share is unnecessary.
Response
Review scenario requirements, application dependencies, historical use, folder contents, service accounts, and permissions before removing it.
Fictional defensive lab
Step 01
FILE-SRV hosts the required TeamDocs share. StaffReaders need read access, StaffEditors need modify access, Morgan administers the server, and AppSvc uses a separate application-data folder.
Step 02
Use Computer Management, Server Manager, and Get-SmbShare to identify share names, paths, and current clients.
Step 03
Run Get-SmbShareAccess for TeamDocs and compare the result with the scenario-required groups.
Step 04
Use the Security tab, Advanced Security, Get-Acl, and icacls to document inherited and explicit permissions.
Step 05
Preserve administrative and application dependencies, remove only clearly excessive access, and keep reader/editor rights aligned with the scenario.
Step 06
Confirm a reader can read but not modify, an editor can modify, Morgan retains administration, AppSvc still works, and an unauthorized user cannot access the share.
Common mistakes
Network access can still fail because share permissions are a second layer.
NTFS permissions may still restrict the user even when the share layer allows access.
Full Control often provides more privilege than users need.
Large permission trees can become inconsistent and hard to troubleshoot.
Applications may fail even though user access looks correct.
Administrators may have broader rights than normal users, hiding permission problems.
Reflection
Question 1
Why do network users have to pass both share and NTFS permissions?
Question 2
Why is Full Control usually broader than ordinary users need?
Question 3
How can inheritance simplify permission management?
Question 4
Why can a Deny entry produce unexpected results?
Question 5
What should be checked before removing a service account from a folder ACL?
Question 6
Why should permission verification use standard user accounts instead of only an administrator?
Verification checklist
Required SMB shares still exist.
Share paths point to the correct folders.
Required readers can read.
Required editors can modify.
Unauthorized users do not have unnecessary access.
Administrative access remains intact.
Required service accounts still function.
No unexpected Deny entry blocks required access.
Inheritance behaves as intended.
SMB firewall and service dependencies remain healthy.
Competition checklist
Open Computer Management → Shared Folders.
Open Server Manager → File and Storage Services → Shares.
Run Get-SmbShare.
Run Get-SmbShareAccess on required shares.
Review folder Security and Advanced Security.
Review owner and inheritance.
Run Get-Acl or icacls.
Check active SMB sessions before disruptive changes.
Use groups instead of many user-specific entries.
Avoid unnecessary Full Control and Deny.
Protect required service-account access.
Verify required network access from client accounts.
Next Windows Server lesson
Next, review remote administrative access, authorized users, firewall exposure, Remote Desktop Services, WinRM, and safe management paths without locking the team out.