Require SMB signing and disable SMBv1 domain-wide

SMB relay is the classic NTLM relay: an attacker captures an authentication attempt, often from LLMNR poisoning or authentication coercion, and replays it to a server that accepts unsigned SMB. If the relayed identity is a local admin on the target, the attacker gets remote code execution. Requiring SMB signing makes the relayed session fail, because the attacker does not have the session key needed to sign. SMBv1, meanwhile, is the protocol behind EternalBlue and WannaCry and has no business on a modern network.

The NTLM and legacy protocols pillar gives the two signing settings. This guide covers the full rollout: the four policy settings and what each one really does, what Windows 11 24H2 and Windows Server 2025 change by default, how to find the devices that will break, and how to audit and remove SMBv1.

The four settings, and which ones count

All four live under:

Computer Configuration > Policies > Windows Settings > Security Settings >
  Local Policies > Security Options

Registry paths are under HKLM\SYSTEM\CurrentControlSet\Services\. With SMB 2 and 3, only the "always" settings change behaviour: signing is used whenever either side requires it. That also means requiring signing on the server protects that server from relay regardless of client configuration, while requiring it on the client protects the client against rogue or downgraded servers.

Defaults by version

• Domain controllers have required server-side signing for a long time through the Default Domain Controllers Policy. Check that nobody weakened it.
• Windows 11 24H2 requires SMB signing by default for both outbound and inbound connections.
• Windows Server 2025 requires signing by default for outbound (client) connections. Inbound signing is only required by default on domain controllers, so member file servers still need the policy.
• Older versions (Windows 10, Windows 11 before 24H2, Windows Server 2022 and earlier) require it only where policy says so.

Upgraded machines follow policy if one is set. If your GPO explicitly sets "always" to Disabled, which some old baselines did to "fix" performance, it overrides the new default. Search for that before assuming 24H2 fixed anything.

Signing, encryption and performance

Signing adds a message authentication code to every SMB packet, keyed from the session key established during authentication. A relaying attacker never learns that key, which is why a relayed session dies as soon as signing is required. The algorithm depends on the negotiated dialect:

AES-GMAC and AES-CMAC benefit from AES-NI hardware acceleration, so the overhead on modern servers is far lower than the "signing halves throughput" warnings written in the SMB 1 and 2 era. The remaining cost is CPU on the file server, most visible on hosts that serve large sequential transfers to many clients at once, such as software distribution points, profile servers and backup targets.

SMB encryption (Set-SmbShare -EncryptData $true or Set-SmbServerConfiguration -EncryptData $true) also provides integrity, so an encrypted session does not need separate signing. It protects the data in transit as well, but it requires SMB 3.x on both ends, which excludes older clients and many appliances. The practical baseline is: signing required everywhere, encryption added for shares that hold sensitive data or are accessed across untrusted links.

Signing does not fix the underlying problem that NTLM authentication can be captured at all. It removes SMB as a relay target, which is the part that turns a captured authentication into code execution.

Measure: find what cannot sign

On Windows clients, Get-SmbConnection shows whether each active session is signed. Run it across a sample of workstations and servers to see which file servers, NAS devices and appliances are reached without signing today.

# On a client: current SMB sessions and their protection
Get-SmbConnection | Select-Object ServerName, ShareName, Dialect, Signed, Encrypted, UserName

# Across machines
$targets = Get-ADComputer -Filter 'OperatingSystem -like "*Windows*"' -SearchBase 'OU=Workstations,DC=corp,DC=example,DC=com' |
    Select-Object -First 50 -ExpandProperty DNSHostName
Invoke-Command -ComputerName $targets -ScriptBlock {
    Get-SmbConnection | Where-Object { -not $_.Signed -and -not $_.Encrypted } |
        Select-Object @{n='Client';e={$env:COMPUTERNAME}}, ServerName, ShareName, Dialect
} -ErrorAction SilentlyContinue | Sort-Object ServerName -Unique

For the server side, inventory the current setting on every Windows server:

$servers = (Get-ADComputer -Filter 'OperatingSystem -like "*Server*"').DNSHostName
Invoke-Command -ComputerName $servers -ScriptBlock {
    $s = Get-SmbServerConfiguration
    $c = Get-SmbClientConfiguration
    [PSCustomObject]@{
        Host = $env:COMPUTERNAME
        ServerRequire = $s.RequireSecuritySignature
        ClientRequire = $c.RequireSecuritySignature
        SMB1 = $s.EnableSMB1Protocol
    }
} -ErrorAction SilentlyContinue | Export-Csv .\smb-posture.csv -NoTypeInformation

Non-Windows targets need a separate check. Samba servers are configured with server signing = mandatory in smb.conf; many NAS vendors expose it as "SMB signing" or "strict signing" in their admin console. Check printers and scanners that "scan to folder" too: they are SMB clients and some old firmware cannot sign.

Audit and remove SMBv1

SMBv1 has not been installed by default since Windows 10 1709 and Windows Server 2019, but upgraded systems and older servers often still have it. Before removing it from file servers, audit who uses it:

# On each file server: log SMB1 access attempts
Set-SmbServerConfiguration -AuditSmb1Access $true -Force

# After a few weeks, read who connected with SMB1
Get-WinEvent -LogName 'Microsoft-Windows-SMBServer/Audit' -FilterXPath '*[System[EventID=3000]]' -MaxEvents 500 |
    Select-Object TimeCreated, Message

Event 3000 records the client address of each SMB1 connection. Typical sources are old copiers, embedded Linux devices with outdated Samba, legacy medical or industrial equipment, and Windows XP or Server 2003 systems that should not exist anymore.

Then remove it:

# Servers and clients: disable the SMB1 server component
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force

# Remove the feature entirely (reboot required)
Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -NoRestart

On Windows Server you can also use Uninstall-WindowsFeature FS-SMB1. For fleet-wide control, the MS Security Guide ADMX from the Microsoft security baselines adds "Configure SMB v1 server" and "Configure SMB v1 client driver" settings; see deploying Microsoft security baselines.

Enforce: rollout order

1. Domain controllers. Confirm server and client "always" are Enabled. DCs are the highest value relay target and are already signing in most domains.
2. Tier 0 and management servers: AD CS, backup, SCCM/MECM, hypervisor management. Relaying to these gives admin on critical systems; see identifying Tier 0 assets.
3. All member servers, server side first. This removes SMB relay as a lateral movement technique against them.
4. Workstations, server side (workstations share ADMIN$ and C$, and relaying to them is common) and client side.
5. Client side on servers, once you know every SMB destination they use can sign.

Use one GPO per ring, linked to the relevant OUs, so you can roll back a ring without touching the others. Changes take effect for new SMB sessions; existing ones continue until they disconnect, so a reboot or logoff makes testing deterministic.

Verify

Invoke-Command -ComputerName $servers -ScriptBlock {
    [PSCustomObject]@{
        Host          = $env:COMPUTERNAME
        ServerRequire = (Get-SmbServerConfiguration).RequireSecuritySignature
        ClientRequire = (Get-SmbClientConfiguration).RequireSecuritySignature
        SMB1Feature   = (Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol -ErrorAction SilentlyContinue).State
    }
} | Where-Object { -not $_.ServerRequire -or -not $_.ClientRequire } | Format-Table

The output should be empty. Re-run the Get-SmbConnection sample: no session should be unsigned and unencrypted. Many internal scanners, and the relay checks in tools like PingCastle and NetExec used by your red team, list hosts that do not require signing; the list should shrink to zero or to a documented exception set.

What it breaks

• NAS and Samba servers that do not support or require signing keep working only if the Windows client side does not require it. When you require client signing, those shares fail with "the specified network name is no longer available" or similar errors until signing is enabled on the device.
• Guest and anonymous SMB access does not work with signing, because a guest session has no key to sign with. Windows 11 24H2 already blocks guest fallback; cheap NAS devices and some "scan to folder" configurations relied on it.
• Multifunction printers scanning to SMB shares with old firmware may fail to connect when the server requires signing. Update firmware or move scan destinations to a dedicated share on a server with an exception plan.
• SMBv1-only devices stop working entirely once SMBv1 is removed: old copiers, embedded controllers, legacy medical and industrial systems. Isolate those that cannot be replaced on a separate network segment with a dedicated, non-domain file drop.
• High-throughput file servers on older hardware may show lower transfer rates with signing required. Measure before and after; consider SMB encryption on 3.1.1 as an alternative for specific shares.

Related reading: the NTLM & Legacy Protocols topic, the SMB signing glossary entry, disabling LLMNR, NBT-NS and WPAD to remove the most common source of relayable authentications, and restricting NTLM for the longer-term fix of removing NTLM itself.