Build secure Windows Server 2025 file shares with NTFS, SMB encryption, and quotas
Combine group-based share and NTFS permissions, SMB 3.1.1 encryption/signing, Kerberos, ABE, FSRM hard quotas, and a verified metadata-preserving restore.
Provide a least-privilege encrypted file service whose capacity and complete recovery behavior are tested rather than assumed.
- Windows Server 2025
- SMB 3.1.1
- Data and identity ownership Data owner, domain groups, fresh test users, canonical DNS/SPN, retention, classification, and audit policy are approved.
- Supported NTFS capacity Target NTFS volume has reserve, monitoring, and FSRM support; existing path/name ownership is known.
- Independent backup and restore target VSS-aware data/metadata backup and isolated restore server/path are available with RPO/RTO acceptance.
OneLiners never runs these steps or stores secrets. Review placeholders, versions, current state, and change-control requirements before using a command.
Full guide
What you will build
- A Windows Server 2025 SMB 3.1.1 share with an explicit domain-group permission model across both share permissions and NTFS ACLs, required encryption/signing, Kerberos evidence, Access-Based Enumeration, and no unmanaged offline cache.
- A hard FSRM quota with staged operational alerts plus a recoverable configuration/data package that is proven through an isolated restore of files, streams, ACLs, share security, quota, and user outcomes.
- Reader, writer, denied user, and recovery administrator produce the approved effective behavior using fresh non-admin tokens; broad grants are absent.
- A real client/server session proves SMB 3.1.1, encryption, signing, canonical FQDN, and Kerberos while unsupported clients are rejected.
- Capacity is bounded and monitored, and a separate restore reproduces data plus security metadata and meets documented RPO/RTO.
Architecture
How the parts fit together
A Windows Server 2025 file server exposes one canonical SMB namespace backed by an NTFS directory. Share ACL gates network entry and NTFS DACL provides object-level rights; the effective result is their intersection. SMB 3.1.1 encryption/signing protects traffic and Kerberos binds the canonical CIFS identity. FSRM enforces a hard directory quota while independent VSS-aware backup stores data and metadata outside the server and restores into an isolated validation namespace.
- A client resolves the canonical server FQDN, obtains a CIFS Kerberos ticket, and negotiates signed encrypted SMB 3.1.1.
- Share access first gates the session; NTFS evaluates file/folder rights from the fresh token, with the most restrictive effective combination winning.
- FSRM monitors aggregate usage and rejects growth at the hard limit while owner alerts trigger capacity or retention action earlier.
- Backup captures files and metadata plus separate configuration exports; isolated restore rebuilds the service and repeats identity-based tests.
Assumptions
- Windows Server 2025 is domain joined, uses canonical DNS and correct CIFS SPNs, is patched, monitored, and protected by a supported VSS-aware backup product.
- The target is an NTFS volume supported by FSRM with reserve beyond the quota for operating system, backup, maintenance, and recovery.
- Data owner controls approved domain groups and can provide reader, writer, and denied test accounts with fresh tokens.
- All production clients support SMB 3.x encryption/signing; legacy dependencies are upgraded or separately isolated instead of weakening the share.
- A separate server/path/namespace can receive restore tests without users, DFS, applications, or search systems mistaking it for production.
Key concepts
- Share versus NTFS permission
- Network access must satisfy both layers; share rights do not override a more restrictive NTFS DACL, and local access sees NTFS only.
- Access-Based Enumeration
- Hides names users cannot list but does not grant or deny the underlying object.
- SMB Encryption
- Protects SMB payload end to end between supported peers and is separate from EFS or at-rest disk encryption.
- Kerberos CIFS identity
- A ticket for `cifs/server-fqdn` authenticates the canonical SMB service and avoids IP/alias NTLM fallback.
- Hard quota
- FSRM rejects new growth above a path limit; it does not reserve volume capacity or replace alerting.
Before you copy
Values used in this guide
{{volumeLetter}}NTFS data volume drive letter.
Example: D{{sharePath}}Owned NTFS share root.
Example: D:\Shares\Finance{{shareName}}Production SMB share name.
Example: Finance{{fileServerFqdn}}Canonical Kerberos/DNS server name.
Example: fs01.example.net{{shareDescription}}Owner and classification label.
Example: Finance controlled data; owner Finance Data Owner{{recoveryGroup}}Restricted file-recovery administrator group.
Example: EXAMPLE\GG-File-Recovery{{modifyGroup}}Data writer group.
Example: EXAMPLE\GG-Finance-Modify{{readGroup}}Read-only group.
Example: EXAMPLE\GG-Finance-Read{{quotaBytes}}Approved hard quota size in bytes.
Example: 536870912000{{quotaDescription}}Quota owner and alert policy.
Example: Finance hard quota; alerts 80/90/95%; owner Finance Data Owner{{aclBackupPath}}Protected ACL export outside the share.
Example: C:\AdminBackup\Finance-acl.txt{{backupTarget}}Dedicated Windows Server Backup target volume or protected UNC destination.
Example: E:{{shareConfigBackup}}Protected share configuration export.
Example: C:\AdminBackup\Finance-share.xml{{quotaBackupPath}}Protected FSRM quota export.
Example: C:\AdminBackup\Finance-quota.xml{{restorePath}}Isolated restore path.
Example: R:\Restore\Finance{{restoreShareName}}Unique nonproduction validation share.
Example: Finance-Restore-20260728{{restoreTestFile}}Known restored file used for hash/stream verification.
Example: R:\Restore\Finance\quarter-close.xlsxSecurity and production boundaries
- Use separate named administrator accounts, Just Enough Administration or delegated roles where practical, and protected management networks. Do not perform routine work as a Domain Admin or paste credentials into PowerShell.
- Capture effective state from both the service and a real client. Hyper-V, SMB, NTFS, FSRM, Kerberos, DNS, firewall, and storage layers can each make a locally correct setting ineffective.
- Before any disruptive change, prove console or out-of-band access, current application-consistent backup, capacity, ownership, maintenance approval, and a time-bounded rollback decision.
- Do not mistake a Hyper-V checkpoint, NTFS shadow copy, DFS replica, RAID mirror, quota report, or open file handle for an independent tested backup.
Stop before continuing if
- Stop when the path/name/data owner is uncertain, target is not NTFS for FSRM, or existing data/ACLs were not backed up and reviewed.
- Stop if any broad write grant, unexpected deny/inheritance, admin-only acceptance test, SMB1/NTLM dependency, or unencrypted session appears.
- Stop hard-quota rollout when alerts fail or the application cannot recover cleanly from quota exceeded.
- Stop release until an isolated restore reproduces data, metadata, ACLs, encryption, quota, and reader/writer/denied outcomes.
Finish line
Verification checklist
Get-SmbConnection -ServerName {{fileServerFqdn}} | Format-Table ServerName,ShareName,Dialect,Encrypted,SigningRequiredReal client session is SMB 3.1.1, encrypted, signed, and backed by canonical CIFS Kerberos.Get-SmbShareAccess -Name {{shareName}}; icacls {{sharePath}}Only approved recovery, modify, and read groups exist, and fresh non-admin tests produce allowed plus denied outcomes.Get-FsrmQuota -Path {{sharePath}}; Get-SmbShare -Name {{restoreShareName}}; icacls {{restorePath}}Hard quota/alerts work and isolated restore reproduces data, streams, ACL, encrypted share, quota, and RPO/RTO.Recovery guidance
Common problems and safe checks
A user is denied although the share permission appears to allow access.
Likely causeNTFS ACL is more restrictive, group membership/token is stale, the path contains an inherited deny, or the client is using another identity.
Get-SmbShareAccess -Name {{shareName}}icacls {{sharePath}}whoami /groupsklist
ResolutionEvaluate both layers using the user's fresh logon token; correct the narrowest wrong ACE rather than granting Everyone Full Control.
A user can write or delete more than intended.
Likely causeShare permission, NTFS inheritance, broad group nesting, CREATOR OWNER, local administrator behavior, or an application service identity expands access.
Get-SmbShareAccess -Name {{shareName}}icacls {{sharePath}} /save {{aclBackupPath}} /t /cGet-LocalGroupMember Administrators
ResolutionRemove the broad grant, restore the reviewed ACL, invalidate sessions if urgent, and retest an allowed action plus adjacent denied write/delete.
SMB clients fail after encryption is required.
Likely causeA legacy client negotiates below SMB 3.x, uses unsupported encryption, connects through an appliance, or reaches a different server/share.
Get-SmbConnection | Format-Table ServerName,ShareName,Dialect,Encrypted,SigningRequiredGet-SmbSession | Format-Table ClientComputerName,Dialect,EncryptedGet-WinEvent -LogName Microsoft-Windows-SMBServer/Operational -MaxEvents 50
ResolutionKeep encryption required for sensitive data, upgrade or isolate the client, and do not weaken the entire server for one undocumented dependency.
The client negotiates NTLM instead of Kerberos.
Likely causeIt connects by IP/alias without SPN, DNS or time is wrong, the server is outside the domain path, or Kerberos fails and NTLM fallback is allowed.
klistResolve-DnsName {{fileServerFqdn}}setspn -Q cifs/{{fileServerFqdn}}Get-SmbSession | Format-Table ClientUserName,ClientComputerName
ResolutionFix canonical DNS/SPN/time and reconnect using the approved FQDN; block or monitor NTLM according to the Windows Server 2025 rollout plan.
New-SmbShare fails because the path or name is invalid.
Likely causeThe directory is missing, the volume is not mounted, another share owns the name, or the path is not supported for the intended FSRM policy.
Test-Path {{sharePath}}Get-SmbShare -Name {{shareName}} -ErrorAction SilentlyContinueGet-Volume
ResolutionCreate the approved owned directory and choose a unique share; never repoint an existing name to unknown data.
Inheritance creates unexpected ACL entries below the share.
Likely causeParent ACLs were not reviewed, inheritance was disabled inconsistently, an application rewrote ACLs, or users own subfolders with CREATOR OWNER semantics.
icacls {{sharePath}}icacls {{sharePath}} /t /cGet-Acl {{sharePath}} | Format-List
ResolutionRestore the versioned ACL model, change inheritance deliberately at the correct root, and avoid per-file emergency grants that cannot be audited.
FSRM quota does not stop writes at the expected threshold.
Likely causeThe quota is soft, applies to another path, FSRM role/service is absent, a nested quota differs, or testing used cached client values.
Get-FsrmQuota -Path {{sharePath}} | Format-List *Get-Service SrmSvcGet-FsrmQuota | Sort-Object Path
ResolutionCorrect the exact hard quota path and service state, then test with controlled data while preserving headroom for administrators and recovery.
A hard quota fills and an application fails partially.
Likely causeCapacity alerts were absent, quota excludes growth forecast, temporary files are large, or application error handling is unsafe.
Get-FsrmQuota -Path {{sharePath}}Get-ChildItem {{sharePath}} -File -Recurse | Measure-Object Length -SumGet-WinEvent -LogName Application -MaxEvents 100
ResolutionStop writes safely, preserve application state, extend quota only through approved capacity change, archive/delete through retention policy, and verify transactional consistency.
Open handles prevent a maintenance move or restore.
Likely causeClients retain sessions, durable handles reconnect, antivirus/indexing holds files, or the application was not quiesced.
Get-SmbOpenFile | Where-Object ShareRelativePath -like '*'Get-SmbSessionGet-Process
ResolutionNotify owners, quiesce the application, close only identified handles in the maintenance window, and never mass-close production sessions without impact approval.
Backup succeeds but ACLs, alternate streams, or share configuration are absent after restore.
Likely causeThe backup captured file content but not NTFS security metadata, share registry/configuration, FSRM policy, or the restore target changed inheritance.
icacls {{restorePath}}Get-SmbShare -Name {{restoreShareName}}Get-FsrmQuota -Path {{restorePath}}Get-Item {{restoreTestFile}} -Stream *
ResolutionCorrect backup component selection, export share/FSRM/ACL definitions, and repeat a clean isolated restore with identity-based access tests.
Access-Based Enumeration hides or exposes unexpected folders.
Likely causeABE is disabled, users have List Folder permissions, group nesting changed, or administrators are testing with privileged tokens.
Get-SmbShare -Name {{shareName}} | Select-Object FolderEnumerationModeicacls {{sharePath}}whoami /groups
ResolutionSet the reviewed enumeration mode and NTFS list permissions, then retest with a fresh nonprivileged token; remember ABE is presentation, not authorization.
SMB performance drops after encryption or signing enforcement.
Likely causeClients lack acceleration, workload packet size/CPU is sensitive, multichannel/RDMA path changed, or capacity was never benchmarked.
Get-SmbConnectionGet-SmbMultichannelConnectionGet-Counter '\SMB Server Shares(*)\*'Get-Counter '\Processor(_Total)\% Processor Time'
ResolutionKeep the security requirement, measure the exact bottleneck, update supported hardware/client paths, and capacity-plan rather than disabling encryption globally.
Reference
Frequently asked questions
Which permission wins, share or NTFS?
Network access must pass both. The effective result is constrained by the most restrictive applicable permissions, with deny and nested-group effects evaluated in the user's token.
Does ABE secure hidden folders?
No. It changes enumeration only. NTFS and share permissions remain the authorization controls.
Does SMB encryption encrypt the disk?
No. It protects SMB traffic. Use BitLocker or approved storage encryption for data at rest and protect recovery keys separately.
Recovery
Rollback
Remove only the newly published share, restore the saved NTFS ACL, and remove the new quota after preserving evidence. Never delete or overwrite the data directory as a shortcut.
- Disable client writes and preserve sessions, SMB/NTFS/FSRM state, events, and the exact data path.
- Remove-SmbShare for the new share only after confirming its name/path; this does not delete data.
- Restore ACLs with the reviewed `icacls /restore` export at the correct parent and retest fresh reader/writer/denied tokens.
- Remove or change the quota only through FSRM after capacity owner approval; do not delete data outside retention policy.
- Re-publish only when encryption, Kerberos, ABE, ACL precedence, quota, backup, and isolated restore all pass.
Evidence