Windows File Server and NTFS Permissions Guide: Share vs NTFS, ABE and Auditing

Windows file servers hold the documents ransomware crews encrypt and exfiltrate, and their permissions have usually grown for years without design or review. Shares created with Everyone access, broken inheritance, user accounts granted directly on folders and service accounts with Full Control across every volume are normal findings. This guide explains how share and NTFS permissions combine, how to design a group model that stays reviewable, how to use access-based enumeration correctly, how to handle backup, migration and scanning accounts, and which audit events to collect. It is written for Windows administrators, data owners and security teams responsible for on-premises file services. For the wider data governance picture see the Unstructured Data and File Share Security Guide; this page covers the Windows mechanics.

Key takeaways

• Two permission layers apply to network access. The share permission and the NTFS permission are both checked, and the user gets the most restrictive result; local access only uses NTFS.
• Put the real control in NTFS. Set share permissions broadly (for example Authenticated Users: Change, Administrators: Full Control) and express access in NTFS through domain local groups that data owners can review.
• Access-based enumeration hides, it does not protect. ABE removes folders a user cannot read from their view; a user who knows the path is still governed only by share and NTFS permissions.
• Privileged and service accounts bypass the model. Backup operators, SeBackupPrivilege holders, migration tools and scanners can read or change everything, so they need Tier 1 treatment.
• Audit selectively. Events 4663 and 5145 need audit policy plus SACLs and generate heavy volume; target write, delete and permission-change rights on sensitive folders.

How identity and access work in Windows file servers

Every file and folder has a security descriptor with an owner, a discretionary ACL (DACL) of allow and deny entries, and a system ACL (SACL) that drives auditing. When a user connects to a share over SMB, the server builds an access token from the user's Kerberos or NTLM authentication, including all group SIDs, then evaluates the share's own ACL and the NTFS DACL. Microsoft's guidance is to assign permissions to groups rather than users, and notes that the owner of an object can always change its permissions regardless of the DACL.

NTFS rights that matter for security

Inheritance flags shape how a grant spreads: (OI) object inherit applies to files, (CI) container inherit to subfolders, (IO) inherit only, (NP) do not propagate, and (I) marks an entry inherited from the parent. Windows evaluates entries in canonical order: explicit denies, explicit allows, inherited denies, inherited allows. An explicit allow on a child therefore overrides an inherited deny, which surprises many reviewers.

Admin roles and privileged access

• Use a group model: the common AGDLP pattern places user accounts in global (role) groups, nests those into domain local groups named for a resource and right (for example FS-Finance-Payroll-RW), and grants only the domain local groups on NTFS. Data owners then review group membership, not ACLs. See the Data Access Governance Guide.
• Limit who can change permissions: grant Modify, not Full Control, to business groups so they cannot change ACLs. Where users create folders, consider the OWNER RIGHTS SID (S-1-3-4) entry to restrict the implicit permission-change right owners otherwise retain.
• File server administrators: local Administrators on a file server can take ownership of any file. Use a dedicated admin group per server tier, grant it just in time and keep domain admins off file servers. See the Privileged Access Management Guide.
• Backup Operators and backup privileges: SeBackupPrivilege and SeRestorePrivilege let a process read and write any file regardless of the DACL. Membership of Backup Operators, and service accounts granted these rights, is privileged access and belongs in your PAM inventory.
• Break-glass: keep a documented path to regain access (an admin group with ownership rights) rather than leaving personal admin accounts on ACLs.

Integrations, API tokens and service accounts

File servers accumulate non-human identities with sweeping rights: backup agents, antivirus and DLP scanners, data classification and migration tools, search indexers, sync engines and line-of-business applications writing to shares. Attackers use these accounts because they can read every folder (MITRE ATT&CK T1039 Data from Network Shared Drive) and often encrypt them (T1486 Data Encrypted for Impact).

• Prefer gMSAs: run backup, scanning and application services as group managed service accounts so passwords rotate automatically and cannot be used interactively. See the Group Managed Service Accounts (gMSA) Guide.
• Read-only where possible: scanners and indexers need Read, not Modify. Grant write only to accounts that must restore or write data, and use backup privileges instead of Full Control ACL entries for backup software.
• Scope application accounts: an application writing invoices needs Modify on one folder, not the share root. Record the owner and purpose for every service account on an ACL.
• Retire migration accounts: migration and consolidation projects add accounts with Full Control on every volume; remove them when the project closes and search for them with icacls <path> /findsid <sid> /T.
• Separate backup identity: backup repositories must not be writable by the accounts that read production shares. See the Backup Identity Isolation Guide.

Logging and detection

Object access auditing needs two things: the advanced audit policy subcategory (Audit File System for 4663, Audit Detailed File Share for 5145, Audit File Share for 5140) and, for 4663, SACL entries on the folders that match the rights you want to record. Microsoft documents that 5145 is generated every time a network share object is accessed and that its failure events appear only for denials at the share level, not at the NTFS level.

• Write-focused SACLs: audit WriteData, AppendData, DELETE, DeleteChild, WRITE_DAC and WRITE_OWNER on sensitive trees rather than all reads; Microsoft's 4663 guidance lists these as the rights to watch.
• Ransomware signals: one account modifying or renaming hundreds of files a minute, new file extensions appearing, or ransom notes in many folders. File Server Resource Manager file screens can alert on known patterns. See the Ransomware Prevention Guide.
• Discovery: a workstation enumerating shares across many servers (T1135 Network Share Discovery) shows up as bursts of 5140 events.

Metrics

• Open access: number of folders granting Everyone, Authenticated Users or Domain Users write access (trend to zero outside designated drop folders).
• Direct user ACEs: count of ACL entries naming users instead of groups.
• Broken inheritance: folders with inheritance disabled, by share.
• Review completion: percentage of resource groups certified by their data owner in the last cycle.
• Privileged service accounts: service accounts with Full Control or backup privileges, each with an owner.
• Stale data: volume of folders with no access in 12 months, a candidate for archive and permission removal.

Hardening baseline

Server and SMB settings

See the SMB Protocol Security and Signing Guide for protocol detail and the Windows Server Hardening Guide for the operating system baseline.

Folder structure and ACL design

• Shallow structure: set permissions at a small number of levels (share root, department, restricted subfolder) and let everything below inherit.
• Root ACL: SYSTEM and file server admins Full Control, a read group for traversal where needed, CREATOR OWNER only where users must create private folders.
• Home folders: one folder per user with the user and administrators only; do not grant the user Full Control, or they can share it with others.
• No Deny for routine control: remove access by removing group membership; reserve Deny for exceptional cases because canonical ordering makes it hard to reason about.

Choosing an approach for permission clean-up

Rollout and rollback

1. Snapshot permissions: icacls D:\Shares\* /save D:\acl-backup\shares.acl /T /C before any change, and export share definitions with Get-SmbShare and Get-SmbShareAccess.
2. Report: list open access, direct user entries, broken inheritance and unknown SIDs (from deleted accounts) per share.
3. Agree owners: each top-level folder gets a named data owner who approves its groups.
4. Turn on auditing first: enable 4663 write auditing on target folders to learn who actually uses them before removing access.
5. Change in waves: replace user entries and broad groups with resource groups one department at a time, communicating the change and keeping a help desk path.
6. Roll back: icacls D:\Shares\ /restore D:\acl-backup\shares.acl reapplies the saved DACLs for a folder tree if a wave breaks access.

Framework mapping

Common misconfigurations

• Everyone Full Control on the share and the folder: the share default was relaxed and NTFS was never tightened, so every authenticated account, including compromised service accounts, can encrypt the share.
• Relying on ABE or hidden shares as security: a $ suffix and ABE only hide names; a user who learns the path keeps whatever NTFS grants.
• Users granted Full Control on their folders: they can change permissions and share data outside any review.
• Orphaned SIDs and direct user entries: deleted accounts and leavers' entries accumulate, making reviews impossible and hiding real exposure.
• Service accounts with Full Control everywhere: a backup or migration account with interactive logon and a non-rotating password is the most valuable account on the server.
• Auditing everything or nothing: all-read SACLs flood the SIEM and get disabled; no SACLs leave no evidence when data is taken. Unpatched NTFS and SMB flaws add to the risk: CVE-2025-24993, an NTFS heap overflow, and CVE-2017-0143, the SMBv1 remote code execution flaw, are both in the CISA Known Exploited Vulnerabilities catalog.

Practitioner checklist

• Save every share's ACLs with icacls /save and export share definitions before changing anything.
• Set share permissions to Authenticated Users Change and Administrators Full Control, and remove Everyone.
• Express all business access in NTFS through domain local resource groups with named data owners.
• Remove direct user entries, orphaned SIDs and Full Control grants to business users.
• Enable access-based enumeration on user-facing shares and DFS namespaces, knowing it hides rather than protects.
• Require SMB signing, remove SMB 1.0 and enable SMB encryption for sensitive shares.
• Run file service accounts as gMSAs with read-only rights where possible and inventory backup privilege holders.
• Audit writes, deletes and permission changes with 4663 SACLs on sensitive folders and forward 5140 and 5145 selectively.
• Certify resource group membership with data owners at least twice a year.

Standards and references

• Microsoft Learn: Access control overview
• Microsoft Learn: icacls
• Microsoft Learn: SMB security enhancements
• Microsoft Learn: Overview of SMB signing
• Microsoft Learn: Enable access-based enumeration on a namespace
• Microsoft Learn: 4663 An attempt was made to access an object
• Microsoft Learn: 5145 A network share object was checked
• MITRE ATT&CK: Data from Network Shared Drive

Related NHI Mgmt Group resources: Unstructured Data and File Share Security Guide · Windows Server Hardening Guide · SMB Signing Guide · Data Access Governance Guide