Fix SMB Signing Not Required Vulnerability on Domain Controllers
This vulnerability means clients can talk to your DC without signing packets. The fix is a GPO tweak that forces signing. I'll show you exactly where.
Yeah, that SMB signing warning in your vulnerability scanner is annoying — every Windows admin has seen it. It's one of those things that feels like it should be on by default, but Microsoft leaves it off for legacy compatibility. Here's how to kill it for good on your domain controllers.
The Actual Fix: Group Policy Object
Open Group Policy Management Console on your DC. Create a new GPO or edit your existing Default Domain Controllers Policy. Navigate to:
Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
Find these two settings and set them both to Enabled:
- Microsoft network server: Digitally sign communications (always)
- Microsoft network server: Digitally sign communications (if client agrees)
The first one is the real fix. The second is a fallback — it lets older clients that can't sign still connect (which is why we keep it on). If you set only the first one and have legacy Windows 7 or XP machines, they'll lose access. So leave both enabled.
After applying the GPO, run gpupdate /force on the DC. Then verify with:
Get-SmbServerConfiguration | Select-Object RequireMessageSigning, EnableSecuritySignature
Both should return True.
Why This Fix Works
What's actually happening here is that SMB signing prevents man-in-the-middle attacks by cryptographically signing every packet between client and server. Without it, an attacker on the same network can inject packets or relay credentials — classic SMB relay attack path.
The GPO setting Microsoft network server: Digitally sign communications (always) translates to the registry key:
HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters\RequireSecuritySignature = 1
When this is set to 1, the DC refuses any SMB connection that doesn't sign its packets. The if client agrees setting (which maps to EnableSecuritySignature) tells the DC to attempt signing but accept non-signing clients. Both enabled means: require signing from modern clients, allow legacy ones that at least try.
The reason step 3 works is that the GPO writes directly to the LanmanServer registry branch. No reboot required — the SMB server service picks up the change within a minute or two. No service restart needed either.
Less Common Variations of This Issue
Mixed OS Environment
If you have Windows Server 2012 R2 or earlier DCs alongside newer ones, the GPO might not replicate the registry setting to older DCs. In that case, set it manually via registry on each older DC using the path above, then restart the Server service with net stop server && net start server.
Azure Domain Services
For Azure AD DS managed domains, you can't push a GPO. Instead, go to the Azure portal → Azure AD DS → Security settings → Enable SMB signing. It's a toggle. Wait 15 minutes for it to apply.
Read-Only Domain Controllers (RODCs)
RODCs don't allow GPO application from the main domain. You have to log into each RODC locally and set the registry key directly. Same path as above, then restart the Server service.
Clients That Can't Sign
If after enabling signing, some machines lose connectivity (usually network scanners, embedded devices, or old Linux Samba clients), check the client's SMB dialect. Devices using SMB 1.0 can't sign. Disable SMB 1.0 on the DC via PowerShell:
Set-SmbServerConfiguration -EnableSMB1Protocol $false
Then update the client to use SMB 2.0+ or replace the device. There's no workaround that preserves security.
Prevention Going Forward
Don't wait for a vulnerability scanner to flag this. Include SMB signing in your baseline security policy for every new DC deployment. I script it into my provisioning process:
# PowerShell snippet to apply on new DC
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanmanServer\Parameters" `
-Name "RequireSecuritySignature" -Value 1 -Type DWord
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\LanmanServer\Parameters" `
-Name "EnableSecuritySignature" -Value 1 -Type DWord
Also audit your domain every quarter using Ladon or BloodHound — both will flag SMB signing gaps in your domain. If you're running a modern network (Windows 10/11, Server 2016+), there's zero reason not to force signing. The only exception I've seen is with some industrial control systems that use ancient SMB implementations — and those should be isolated on their own VLAN anyway.
One last thing: after you apply this, run another scan. Some scanners (like Nessus) check both the GPO and the effective registry. If the registry shows 0 but the GPO shows 1, the GPO hasn't applied yet. Force a gpupdate and check again.
Was this solution helpful?