- Knowledge base
- Active Directory management
- Active Directory reports
- Active Directoy integrations
- Active Directory automation
- Active Directory delegation
- Governance, risk, and compliance
- Microsoft 365 management and reporting
- AD migration
- Access certification
- Identity risk assessment
- Risk exposure management
- FAQs
- Pricing
- Online demo
- Request support
- Get quote
Why SMB signing matters
Server Message Block (SMB) is the protocol Windows uses for file and printer sharing, named pipe communication, and a long list of administrative operations between domain-joined machines. By default, in older Windows versions, SMB packets travel without any cryptographic signature, which means an attacker in the same network segment can intercept, modify, or relay them. SMB signing closes that gap by attaching a hash of each packet, computed with the session key, so any tampering or replay is detected, and the connection is dropped.
The most common attack that SMB signing prevents is the SMB relay attack, in which an attacker forwards a victim's authentication to a third machine and inherits their privileges. Tools like PetitPotam and Responder are built around this attack technique, and unsigned SMB sessions are a prerequisite for these tools to succeed.
Microsoft now requires SMB signing by default on Windows 11 (version 24H2) and Windows Server 2025, but the setting is still off or only optional on Windows Server 2022 and earlier. That's why centralized Group Policy management is the practical way to enforce SMB signing consistently across a mixed estate.
The 4 GPO settings that govern SMB signing
Group Policy exposes SMB signing through four Security Options: two for the SMB client and two for the SMB server. Each Windows machine acts as both a client and a server for SMB, so all four settings can apply to the same computer object.
Microsoft network client
1. Digitally sign communications (always): The client requires signing for every outbound SMB connection. Connections to servers that cannot sign will fail.
2. Digitally sign communications (if server agrees): The client negotiates signing only when the destination server supports it; this is typically used as a fallback when full enforcement isn't possible.
Microsoft network server
3. Digitally sign communications (always): The server requires signing on every inbound SMB connection. Clients that cannot sign will be refused.
4. Digitally sign communications (if client agrees): The server negotiates signing only when the connecting client supports it.
For a hardened configuration, enable both always settings. The if client/server agrees settings are useful in mixed environments where some endpoints still need to negotiate, but they do not provide the same level of protection since an attacker who controls the negotiation can downgrade the session.
Considerations before rolling out SMB signing broadly
Enabling SMB signing on the always settings is a security improvement, but it can break access to file shares hosted on devices that do not support SMBv2 signing or that have it disabled by default. Inventory the following before pushing the policy domain-wide:
- Linux file servers running older Samba builds, especially those configured for SMBv1 only
- NAS appliances such as older QNAP, Synology, and Buffalo devices that ship with SMB signing disabled in the default configuration
- Embedded devices, multifunction printers, and industrial systems that mount Windows shares
- Backup software and imaging tools that use SMB and may not have been tested with mandatory signing
The safest rollout is to enable signing in monitor-only mode first by setting only the if client/server agrees policies, observing SMB connection logs for failures, remediating the third-party endpoints, and then moving to the always policies. Once these are enforced domain-wide, also confirm that SMBv1 is disabled, since SMBv1 signing relies on the broken MD5 hash and provides little real protection.
Prerequisites
You need:
- Domain Admin privileges or an equivalent delegated permission to create and link GPOs at the domain or organizational unit (OU) level.
- The Group Policy Management Console (GPMC), which is available through the Remote Server Administration Tools feature set in Windows 10 and 11 or is installed by default on Windows Server.
- A test OU with a representative mix of clients and servers; enabling SMB signing always carries a compatibility risk for older third-party file servers, NAS appliances, and SMBv1-only devices, so a pilot rollout is strongly recommended.
Step 1: Create or edit a GPO in the GPMC
- Open the GPMC by pressing Win + R, typing gpmc.msc, and pressing Enter.
- On the left pane, expand the forest and domain, then locate the OU you want to apply the policy to. Start with a small pilot OU rather than the domain root.
- Right-click the OU and select Create a GPO in this domain, and Link it here.
- Give the GPO a descriptive name such as SMB Signing Enforcement and click OK.
- Right-click the new GPO in the linked GPOs list and select Edit to open the Group Policy Management Editor.
Step 2: Configure the SMB signing security options
Step 3: Apply and refresh the policy
Step 4: Verify that SMB signing is enforced
How to manage SMB signing GPOs at scale
ADManager Plus provides a centralized, web-based GPO management console that complements the work you do in the Group Policy Management Editor. Once your SMB Signing Enforcement GPO is created with the four Security Options configured, ADManager Plus helps you operationalize it across the domain without giving every admin direct GPMC access.
- Bulk GPO linking: Link the SMB signing GPO to multiple OUs, sites, or domains in a single action, instead of repeating the process for each container.
- Link order management: Adjust GPO precedence where another policy might conflict with your SMB signing settings, ensuring the right configuration wins.
- On-demand policy refreshes: Trigger an immediate GPO update on selected computers—no waiting for the 90-minute refresh interval or running gpupdate /force machine by machine.
- GPO replication: Copy the SMB signing baseline into a child domain or test environment without rebuilding it from scratch, keeping configurations consistent across environments.
- Application visibility: Use the All GPOs and Linked AD Objects report to confirm exactly where the SMB signing GPO is applied across your environment.
- Drift detection: Compare GPO versions side by side to spot unintended changes between the production policy and your established baseline.
- Delegation oversight: Run the delegation reports to verify that only authorized administrators can edit the GPO. Use role-based access to scope GPO link, update, and reporting tasks to help desk technicians without granting Domain Admin privileges.