SMB Signing Not Enforced? How to Fix It in Active Directory (Guide + Key Risks)

Background

Server Message Block (SMB) Signing is not new, but we still encounter many environments where it is either disabled or only partially enforced. This configuration creates a gap that our consultants regularly exploit during internal penetration tests. Even though Microsoft has steadily strengthened SMB Signing support over the years, organizations must take deliberate steps to enforce it.

What is SMB Signing?

SMB Signing ensures the authenticity and integrity of SMB traffic between clients and servers. Each SMB message carries a cryptographic signature generated using the session key. The receiving system verifies this signature, preventing tampering or impersonation.

A quick timeline:

• Introduced as early as Windows NT 4.0 and Windows 98
• Enforced by default on Domain Controllers, but not on most member servers or workstations
• Enforced by default on Windows 11 since version 24H2

Without SMB Signing, attackers can often intercept and relay SMB traffic to gain unauthorized access to servers and workstations within an Active Directory network.

Why it's Dangerous to Leave SMB Unsigned

If SMB Signing is not required on both client and server sides, the environment remains vulnerable to SMB relay attacks. This is where an attacker intercepts authentication attempts and relays them to another service to gain elevated access. A prerequisite for an SMB relaying attack is a successful network traffic response spoofing attack (i.e., LLMR/NBT-NS/mDNS Response Spoofing or DNS Spoofing via IPv6) or an authentication coercion attack.

Key risks associated with leaving SMB unsigned:

• Unauthorized administrator-level access to systems in a domain environment
• Credential theft and reuse
• May result in lateral movement or escalation of privileges in Active Directory

We often exploit SMB signing misconfigurations during internal penetration tests, even when the setting appears enabled. We explain how this happens in practice, including how “enabled but not required” still allows attack chains, here → The Real-World Risk of Not Enforcing SMB Signing in Internal Networks.

How to Check if SMB Signing is Enforced

On a single host, administrators can use PowerShell:

Get-SmbServerConfiguration | FL RequireSecuritySignature
Get-SmbClientConfiguration | FL RequireSecuritySignature

To check across the domain:

$adcomputers = Get-ADComputer -Filter * | Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $adcomputers -ScriptBlock {
    Get-SmbServerConfiguration | Select-Object EnableSecuritySignature, RequireSecuritySignature
}

Registry inspection also works by querying the HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters and HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters Registry keys.

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" -Name "RequireSecuritySignature","EnableSecuritySignature"

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" -Name "RequireSecuritySignature","EnableSecuritySignature"

The values map to the SMB Signing status as follows:

Enabling SMB Signing

Registry using PowerShell

Each setting can then be set using PowerShell to modify the associated Registry keys:

SMB Server:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
 -Name "RequireSecuritySignature" -Value 1

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
 -Name "EnableSecuritySignature" -Value 1

SMB Client:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" `
 -Name "EnableSecuritySignature" -Value 1

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters" `
 -Name "RequireSecuritySignature" -Value 1

Though not ideal, these commands could be used with the Invoke-Command cmdlet used above to enable SMB Signing on all hosts in the domain.

Via Group Group Policy

The most surefire way to enable SMB Signing is via Group Policy within Active Directory. Applying a Group Policy Object (GPO) to specific Organizational Units (OUs) in the domain makes it possible to ensure better coverage and validate that no hosts are missed. The exact settings can be found under Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options. The two settings are highlighted below.

The related settings (if the server and client agree) only apply to SMBv1, which should already be turned off in modern environments! Once these are set, you will enable client- and server-side SMB signing. This can be done by editing the Default Domain Policy GPO, but ideally, create a new GPO for easier management and auditing and apply it to the necessary OUs where your servers/workstations live.

Additional Considerations

As with any change in Active Directory, testing is critical. Enforcing SMB Signing could impact legacy applications, devices, or file-sharing workflows that rely on unsigned SMB communications. After enabling, you may see a slight increase in CPU usage on servers and clients and lower transfer speeds.

What Could Break?

• Older applications that do not support SMB Signing
• Third-party appliances or legacy devices still using SMBv1
• Some cross-platform interoperability scenarios
• If there is a client that does not support SMB signing, but it is required on the server, and vice versa

If unsure, test enforcement on a subset of systems before a domain-wide rollout. Ideally, start with servers first, which will help identify legacy client devices that do not support signing and may need to be retired. Once this is done and everything is working as expected, roll the change out to clients as well.

Final Thoughts

Enforcing SMB Signing is a low-effort, high-impact control. It disrupts a common attacker technique, SMB Relay, and strengthens Active Directory security. At the time of writing, lack of SMB Signing remains a top 5 finding in internal penetration tests, sitting comfortably in position # 6 in our Top 10 Internal Penetration Test Findings of 2024. As of August 2025, it is looking to remain in the top 10 for another year.

Our Active Directory Security Hardening & Hygiene Checklist covers the most common issues we see during internal assessments and how to properly address them.

Want to test your environment for risks like this?

Vilkas Cybersecurity helps organizations uncover and fix real-world exposures, not just theoretical ones.

Have a question about this article or a security challenge of your own? Fill out the form and we’ll get back to you shortly.