Windows Server 2025 / How to Check SMB Signing and Test Share Encryption
SMB signing protects message integrity; SMB encryption protects the transmitted content. For connection failures, inspect names, authentication, protocol support, and the negotiated session before weakening either protection.
| Control | Purpose |
|---|---|
| Signing | Detect message tampering and help protect authenticated communication |
| Encryption | Protect file traffic content on the network |
| Share and NTFS permissions | Limit the operations an authenticated user can perform |
Signed does not mean encrypted, and encrypted traffic does not repair excessive file permissions. Server, client, and negotiated-session behavior all matter. SMB signing guidance distinguishes Windows Server 2025 outbound requirements from inbound service settings. Domain roles and GPO can change the effective configuration.
Query requirements before changing them
On FS1, inspect the SMB client role used to access other servers separately from the SMB server role serving its own files:
Get-SmbClientConfiguration | Select-Object RequireSecuritySignature Get-SmbServerConfiguration | Select-Object RequireSecuritySignature,EncryptData,RejectUnencryptedAccess Get-SmbShare -Name 'LabRead' | Select-Object Name,Path,EncryptData
RequireSecuritySignature reports a requirement, not every detail of one active connection. Encryption can involve share, server, and client policy. Consult SMB security hardening for version-specific conditions.
Use the working LabRead share and domain identity. Close active files and retain the original value in the same FS1 PowerShell session:
$previousEncryption = (Get-SmbShare -Name 'LabRead').EncryptData Set-SmbShare -Name 'LabRead' -EncryptData $true Get-SmbShare -Name 'LabRead' | Select-Object Name,EncryptData
SMB encryption requires supported SMB 3.x endpoints and compatible policy. A device advertising SMB 3 still needs the specific encryption support. After saving work, close only the relevant client connection and reconnect by the normal server name.
Open \\fs1.ad.example.test\LabRead on CLIENT1 and inspect its actual connection there:
Get-SmbConnection | Where-Object ShareName -eq 'LabRead' | Select-Object ServerName,ShareName,Dialect,Encrypted
Check the target row, negotiated Dialect, and Encrypted=True. If no row exists, first open a file to establish the connection. Read-only permissions remain read-only even when encryption works.
Separate compatibility and authentication failures
| Symptom | First checks |
|---|---|
| Name connection failure | DNS, actual server name, domain connectivity |
| Credential or guest error | Actual identity, stored connections, device authentication support |
| Signing failure | Peer support and client signing requirement |
| Failure after encryption change | SMB dialect, encryption capability, policy, and event details |
Prefer domain names and Kerberos when appropriate rather than bypassing identity problems through IPs or arbitrary aliases. For an older NAS, check updates, signing capability, replacement, or isolation instead of globally disabling signing, enabling insecure guest use, or turning on SMB1.
Inspect SMBClient and SMBServer event logs and record the time, share, and account. Authorization denial and security negotiation failure are different diagnoses.
Restore only the measured test change
In the same FS1 shell, restore the saved value rather than always disabling encryption:
Set-SmbShare -Name 'LabRead' -EncryptData $previousEncryption
Reconnect and recheck both file access and negotiated protection. Broader policies can still require encryption after the share value is restored. For operational deployment, consider data sensitivity, compatibility, measured performance, and recovery access together.
