NTFS permissions
Control access to files and folders on NTFS volumes. They apply both locally and, in combination with share permissions, across the network.
Windows 11 · Lesson 10
Files, Folders & Share Permissions
Learn how NTFS permissions, share permissions, ownership, inheritance, group membership, and effective access combine to determine who can actually reach Windows data.
Permission hardening is not just removing names from a list. Strong teams understand where access comes from, preserve required workflows, and verify the final result from the user's perspective.
Lesson Snapshot
Permission layers5
Common NTFS levels5
Main principleLeast privilege
GoalCorrect effective access
Learning objectives
What permission review should help you do
01
Explain the difference between NTFS permissions, share permissions, ownership, inheritance, and effective access.
02
Review file and folder access without assuming that one visible permission entry tells the whole story.
03
Use least privilege to preserve required access while removing unnecessary exposure.
04
Recognize how local permissions and network share permissions combine when a folder is accessed remotely.
05
Use File Explorer, Computer Management, icacls, and PowerShell to inspect permissions in an authorized environment.
06
Verify that authorized users retain required access and unauthorized users lose unnecessary access after changes.
Core concept
Effective access is the real answer
A user's actual access may come from direct entries, inherited entries, group membership, ownership, and share permissions. Review the whole path before deciding.
Permission warning
Removing access can break applications and services
SYSTEM, service accounts, administrators, or application groups may have legitimate access to data folders.
Preserve required dependencies and test the real workflow after high-impact ACL changes.
Permission layers
Five ideas that determine access
Share permissions
Apply when a folder is accessed through a Windows network share. They do not replace NTFS permissions.
Ownership
The owner has special control over the object and may be able to change permissions. Ownership should be reviewed when access seems unusual.
Inheritance
Permissions can flow from a parent folder to child folders and files. Inherited entries may explain access that is not obvious from one object.
Effective access
The access a user actually receives after group memberships, explicit permissions, inherited permissions, denies, and share permissions are considered together.
NTFS permission levels
Match permission level to the required task
Full control
Allows reading, writing, modifying, deleting, and changing permissions. This is highly privileged and should be limited.
Modify
Allows reading, writing, changing, and deleting content but does not provide every permission-management capability of Full control.
Read & execute
Allows reading files and running executable content where applicable.
Read
Allows viewing file and folder content without modification.
Write
Allows creation or modification of files or folders depending on the object and inherited rights.
Inheritance and groups
Access may come from somewhere else
Inherited allow
A user may receive access from a parent folder even if the child folder has no explicit allow entry for that user.
Explicit allow
An explicit permission is assigned directly to the object rather than inherited from a parent.
Explicit deny
Deny entries can override expected access and should be used carefully because they can create confusing results.
Broken inheritance
A child object may stop inheriting from its parent and maintain a different permission set.
Group-based access
Users often receive access through groups, so reviewing only the user's direct entries may miss the real source of permission.
Local vs network access
Share and NTFS permissions work together
Local access
When a user accesses the folder directly on the computer, NTFS permissions determine the result.
Network access
When a user accesses the folder through a Windows share, both share permissions and NTFS permissions matter.
Most restrictive result
For remote access, the effective result is limited by the combination of share and NTFS permissions.
Scenario requirement
A share should be available only to the users or groups who need it, with no more access than the required workflow demands.
Windows tools
Inspect permissions from the GUI
File Explorer — Security tab
Properties → SecurityShows NTFS permission entries and provides access to Advanced Security Settings.
Advanced Security Settings
Properties → Security → AdvancedShows ownership, inherited entries, explicit entries, inheritance state, and effective-access tools.
Shared Folders
Computer Management → Shared FoldersShows shares, sessions, and open files, which can help identify active network access.
Share properties
Properties → Sharing → Advanced Sharing → PermissionsShows permissions that apply when the folder is accessed through the share.
Command-line inspection
Read ACLs and share access efficiently
Inspect NTFS permissions
icacls "C:\Practice\Project"Displays access-control entries for a selected authorized practice folder.
PowerShell ACL inspection
Get-Acl "C:\Practice\Project" | Format-ListShows owner, access entries, and other ACL information for inspection.
Review SMB shares
Get-SmbShareLists Windows SMB shares and basic properties.
Review SMB share access
Get-SmbShareAccess -Name "ProjectShare"Shows share-level access entries for a known authorized practice share.
Before changing permissions
Ten questions to answer
01
Who is supposed to access this file, folder, or share?
02
Should the user have Read, Modify, or Full control?
03
Is access assigned directly or through a group?
04
Is the permission inherited from a parent?
05
Is there an explicit deny that changes the expected result?
06
Does the folder also have share permissions?
07
Who owns the object?
08
Could changing permissions break a required application, service, or user workflow?
09
Does a forensic question depend on the file, timestamps, or existing access configuration?
10
How will the team test the final effective access?
Access classification
Decide what kind of permission problem you have
Required access
The user or group clearly needs access to perform a scenario-required task.
Response
Keep the access, but reduce it to the minimum permission level needed.
Excessive access
The user needs access, but has more privilege than necessary.
Response
Reduce Full control or Modify to the least privilege that supports the task.
Unauthorized access
A user or group has access with no scenario or operational justification.
Response
Remove or correct the permission after confirming dependencies and effective access.
Unknown access
The permission entry is unfamiliar or appears to come from an unexpected group or inheritance path.
Response
Investigate group membership, inheritance, ownership, and application dependencies before changing it.
Least-privilege examples
Match access to role
Read-only research folder
Users who only need to view documents should not receive Modify or Full control.
Shared project folder
Contributors may need Modify while reviewers may need only Read. Different roles can require different groups.
Administrative folder
Only administrators or a narrow management group may need access to sensitive configuration files.
Application data
Changing permissions manually can break software if the application expects a service account or system principal to have access.
Ownership
Treat ownership changes as high impact
Ownership is not ordinary access
The owner may not automatically have every read or write permission, but ownership can allow control over permission changes.
Taking ownership is high impact
Changing ownership can alter the security model of a folder and may affect applications or system files.
Preserve system ownership
System-managed folders often have intentional ownership and ACL structures. Do not take ownership merely because access is inconvenient.
Document unusual ownership
Unexpected ownership on a sensitive folder can be evidence worth recording before changing it.
Decision cases
Permission decisions in context
Authorized user has Full control
Avery is authorized to read and edit project documents, but the folder grants Avery Full control.
Avery needs access, but permission-management capability is unnecessary.
Response
Reduce access to the level required for editing, then verify Avery can still complete the project workflow.
Everyone has broad share access
A project share grants broad access at the share level while NTFS permissions are more restrictive.
The NTFS layer may reduce actual access, but the broad share still creates unnecessary ambiguity and exposure.
Response
Align share permissions with the intended audience while preserving the required users and verifying remote access.
Unknown group inherits access
An unfamiliar local group appears on a folder through inheritance from the parent directory.
Removing the child entry alone may not work because the source is inherited.
Response
Investigate the group, parent ACL, and required application access before changing inheritance or group membership.
Required application folder is restricted
A service account loses access after permissions are tightened on the application's data folder.
The security change removed a dependency the application actually requires.
Response
Restore the narrow service-account access required by the application and verify the service works.
Deny permissions
Use explicit deny sparingly
Prefer clear group design
It is usually easier to manage who should receive access than to build complex layers of deny entries.
Use deny carefully
A deny can override access inherited through groups and produce surprising results.
Test effective access
If a deny is present, verify the actual result for the affected user or group.
Do not remove blindly
An existing deny may protect sensitive content. Understand why it exists before deleting it.
Share security
Review remote-access requirements too
01
Is the share actually required?
02
Which users or computers need remote access?
03
Does the active firewall profile allow the required SMB traffic?
04
Are share permissions broader than necessary?
05
Are NTFS permissions broader than necessary?
06
Do authorized users receive the same intended access locally and remotely?
07
Are there active sessions or open files that could be interrupted by the change?
08
Should the share remain hidden or discoverable according to the scenario?
Fictional defensive lab
Build least-privilege access for a shared project folder
Step 01
Read the fictional scenario
A project folder must be shared with Avery and Riley. Avery needs Modify access, Riley needs Read access, and Morgan is the authorized administrator. Other local users should not access the project.
Step 02
Inspect NTFS permissions
The folder inherits broad Users-group Modify access from its parent and also gives Morgan Full control.
Step 03
Inspect share permissions
The share grants broad Change access to a large group, which is wider than the scenario requires.
Step 04
Design least privilege
Avery should keep Modify, Riley should receive Read, Morgan should retain administrative control, and unnecessary broad access should be removed.
Step 05
Apply controlled changes
Adjust the NTFS and share permissions with inheritance and group membership in mind rather than adding multiple confusing deny rules.
Step 06
Verify effective access
Test Avery locally and remotely for Modify, Riley for Read-only access, Morgan for administration, and an unauthorized user for denied access.
Troubleshooting
When permissions do not behave as expected
User can access locally but not through the share
Are share permissions more restrictive than NTFS? Is SMB allowed through the firewall? Is the user accessing the correct share name?
User has access even after direct permission removal
Is access inherited? Is the user a member of another allowed group? Does ownership or another ACL entry provide access?
Application stops working
Did the application or service account lose access to its data or configuration folder? Was inherited access removed?
Permission changes keep propagating unexpectedly
Is inheritance enabled? Was the parent ACL changed? Did the change convert inherited entries to explicit entries?
Common mistakes
Permission habits that create avoidable problems
Looking only at direct user entries
Group membership and inheritance often explain effective access.
Using deny as the first fix
Complex deny rules can make permissions harder to understand and troubleshoot.
Ignoring share permissions
Remote access depends on both share and NTFS permissions.
Taking ownership unnecessarily
Changing ownership can disrupt system or application security structures.
Removing SYSTEM or service access blindly
Applications and Windows components may depend on these principals.
No effective-access test
A permission dialog can look correct while the real user experience is still wrong.
Reflection
Test your permission reasoning
Question 1
What is the difference between NTFS permissions and share permissions?
Question 2
Why can a user still have access after a direct permission entry is removed?
Question 3
Why should inheritance be reviewed before changing a child folder?
Question 4
When can taking ownership create problems?
Question 5
Why is effective access more important than one visible ACL entry?
Question 6
What should be tested after changing permissions on a required share?
Verification checklist
Confirm the final access model
01
Confirm the folder owner is appropriate.
02
Confirm inheritance is configured intentionally.
03
Confirm explicit permissions are limited to required users and groups.
04
Confirm share permissions match the remote-access requirement.
05
Confirm authorized users receive the intended Read or Modify access.
06
Confirm unauthorized users do not receive unnecessary access.
07
Confirm required applications or service accounts still function.
08
Confirm required shares remain reachable through the firewall.
09
Review open sessions if the share is actively used.
10
Document high-impact permission changes and unresolved access questions.
Competition checklist
Before leaving Files, Folders & Shares
01
Identify the exact users and groups who require access.
02
Separate local NTFS access from network share access.
03
Review inherited and explicit permissions.
04
Review ownership before taking ownership or changing it.
05
Review group membership for users with unexpected access.
06
Review share permissions for every required SMB share.
07
Reduce excessive Full control or Modify access.
08
Avoid unnecessary deny entries.
09
Preserve required application and service-account access.
10
Test authorized and unauthorized effective access.
11
Verify firewall and share availability after remote-access changes.
12
Document important permission changes.
Next Windows lesson
Remote Access & RDP
Next, learn how Remote Desktop depends on users, user rights, firewall rules, services, network exposure, and secure access decisions.