SMBv1 Enabled on Domain Controllers: Risks & Remediation
SMBv1 Enabled on Domain Controllers: Risks & Remediation
Microsoft deprecated SMBv1 in 2014, and it's still the protocol that let WannaCry and NotPetya spread across entire networks in minutes. When it's enabled on a domain controller, one of the most sensitive assets in the environment is running a file sharing protocol with no meaningful protection against tampering or downgrade. Here is why SMBv1 keeps showing up on domain controllers, how attackers use it, and how to turn it off for good.
Quick Summary
SMBv1 is a legacy file-sharing protocol with known security weaknesses and none of the security improvements introduced in modern SMB versions. Leaving it enabled on a domain controller allows the system to continue accepting SMBv1 connections even when the environment normally uses SMBv2 or SMBv3.
| Priority | Low |
| Risk | A domain controller continues to accept an obsolete SMB protocol with known security weaknesses |
| Impact | Loss of data integrity on a Tier 0 asset, exposure to known SMBv1 exploits, and an easy signal to attackers that the environment isn’t hardened |
| Exploitation | Attackers detect SMBv1 with common open-source tools, then pair it with network poisoning techniques to escalate privileges |
| Fix | Disable or remove SMBv1 from every domain controller after identifying any systems that still depend on it |
What Is SMBv1, and Why Does It Still Show Up on Domain Controllers?
Server Message Block, or SMB, is the Windows protocol used for network file and resource sharing. Domain controllers use SMB for functions such as SYSVOL and NETLOGON access, Group Policy processing, and administrative file access.
SMBv1 is the original version, first introduced in the 1990s for file and printer sharing on Windows networks. Microsoft replaced it with SMBv2 in 2006 and SMBv3 in 2012, and formally recommended disabling SMBv1 starting with Windows 8.1 and Windows Server 2012 R2.
Despite that, SMBv1 remains installed and enabled on a surprising number of domain controllers. It usually isn’t a deliberate choice. Older print devices, legacy applications, or file shares set up years earlier can quietly depend on it, and nobody revisits the setting once it’s working.
The protocol lacks the security features added in later versions, most notably pre-authentication integrity and reliable SMB signing. Without those protections, SMBv1 traffic can be intercepted, downgraded, or tampered with in ways that SMBv2 and SMBv3 are built to prevent. On a regular workstation, it’s just a problem. On a domain controller, it affects authentication for the entire domain.
How SMBv1 on a Domain Controller Poses a Risk
Leaving SMBv1 enabled on a domain controller introduces risk that has nothing to do with whether anyone is actively using the protocol day to day.
Common risks include:
- Integrity issues on a Tier 0
asset SMBv1 lacks the signing and integrity checks that protect SMBv2 and SMBv3 traffic, leaving domain controller communications open to tampering. - Downgrade attacks
An attacker positioned on the network can attempt to force a downgrade to SMBv1 to bypass the protections available in newer SMB versions. - Known exploit exposure
SMBv1 vulnerabilities, including the ones exploited by WannaCry and NotPetya, remain a viable path for attackers against any system where the protocol is still active. - Unhardened environment signaling
SMBv1 enablement is easy to detect with open-source tooling. Its presence tells an attacker the domain controller likely has other unaddressed legacy settings worth checking.
Real-World Context
SMBv1 rarely gets left on because someone decided it was needed. It’s usually a holdover from a domain controller built years ago with the feature enabled by default, a print server that never got tested against SMBv2, or a legacy application nobody wants to touch during a maintenance window. The setting goes unnoticed because domain controllers don’t get rebuilt often, and SMBv1 doesn’t announce itself the way an expired certificate or a failed login does.
How Attackers Exploit SMBv1 on Domain Controllers
An attacker does not need SMBv1 to be actively used by users before it becomes interesting. After gaining internal network access, an attacker can enumerate SMB services and determine which protocol versions a system supports. This can be done with common network scanners and offensive security tools.
A typical sequence looks like this:
- The attacker identifies the domain controllers.
- SMB services are enumerated.
- The attacker determines that SMBv1 is supported.
- The server’s operating system, patch level, SMB configuration, and other reachable services are investigated.
- If an exploitable condition exists, the attacker attempts to use it.
SMBv1 should also be considered separately from related SMB weaknesses. For example, SMB signing configuration, name-resolution poisoning, and NTLM relay can all affect the security of SMB-based authentication, but they are not the same condition as SMBv1 being enabled.
Leaving SMBv1 enabled gives an attacker another legacy protocol surface to investigate. It should not be treated as proof that SMB relay, poisoning, or remote code execution will succeed.
How to Detect SMBv1 on Domain Controllers
Checking the SMB server configuration directly is straightforward.
PowerShell Method
Run the following command from an elevated PowerShell prompt on a domain controller:
# Check whether SMBv1 client and server components are enabled
Get-SmbServerConfiguration | Select-Object EnableSMB1Protocol
Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol
What it does: Reports whether the SMBv1 server component is currently enabled and whether the SMB1Protocol feature is installed at the OS level.
How to interpret results: EnableSMB1Protocol : True, or a feature state of Enabled, means SMBv1 is active on that domain controller and should be scheduled for remediation
Server Manager
For manual verification on a single server:
- Open Server Manager.
- Click Manage, then Remove Roles and Features.
- Navigate to Features.
- Locate SMB 1.0/CIFS File Sharing Support.
- Check whether the feature is currently selected.
If the feature is present and checked, SMBv1 is enabled on that domain controller.
Find Out Whether Anything Still Uses SMBv1
One of the most useful steps before removal is determining whether any clients are actually trying to use the protocol.
To enable SMBv1 access auditing, run the following:
# Enables SMBv1 access auditing
Set-SmbServerConfiguration -AuditSmb1Access $true -Force
Then review the following logs: Applications and Services Logs, Microsoft, Windows, SMBServer, and Audit.
Event ID 3000 is generated when a client attempts to connect to the server using SMBv1. This will help answer “What will break if we turn it off?”. Instead of guessing, administrators can identify the systems still requesting SMBv1 and deal with those dependencies directly.
Finding This Risk with Insight Recon
Insight Recon’s Active Directory security assessment checks every domain controller for SMBv1 enablement across the domain in minutes.
It also provides:
- Visibility into every domain controller with SMBv1 still active
- Risk prioritization alongside other directory services findings
- Step-by-step remediation guidance
- Validation guidance to confirm the finding is resolved after remediation
This gives your team immediate visibility into whether the issue is isolated to one system or reflects a broader configuration baseline problem.
How to Disable SMBv1 on Domain Controllers
Prerequisites
Before disabling SMBv1:
- Complete an inventory of systems and applications that may rely on SMBv1 by enabling SMBv1 auditing and review Event ID 3000 activity.
- Obtain change control approval.
- Document a rollback plan (re-enabling SMBv1 via registry if a compatibility issue arises).
- Ensure Domain Admin or local administrator rights on the domain controller.
PowerShell Method
From an elevated PowerShell prompt, run the following command on the affected domain controller. The change requires a restart to take full effect.
# Disable SMBv1 on a domain controller
Set-SmbClientConfiguration -EnableSMB1Protocol $false -Force
Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force
Server Manager
- Open Server Manager.
- Select Manage, Select Remove Roles and Features.
- Select the affected domain controller.
- Continue to the Features page.
- Clear SMB 1.0/CIFS File Sharing Support.
- Complete the wizard.
- Restart the server when required.
For domain controllers, use the organization’s normal change-management and maintenance procedures.
Preventing SMBv1 Drift Going Forward
The long-term fix is to remove whatever dependency caused SMBv1 to remain enabled. If an old device or application still needs it, give that dependency an owner and a replacement or upgrade plan. Re-enabling SMBv1 on a domain controller should not become the permanent compatibility solution.
Domain controller build standards should also explicitly disable or remove SMBv1 so that newly deployed or restored servers do not reintroduce it.
SMB configuration is worth checking periodically along with other legacy protocol settings. Configuration drift, old deployment templates, restored virtual machines, and troubleshooting changes can all bring back settings administrators thought had already been eliminated.
Quick Validation Checklist
Can you confidently answer “yes” to all of these?
✓ Do you know if your domain controllers have SMBv1 enabled?
✓ Have you inventoried devices or applications that still depend on SMBv1?
✓ Do you have monitoring in place to alert on SMBv1 traffic?
If any of these are unclear, your domain controllers may be exposed to a protocol attackers specifically look for.
Risk & Compliance Mapping
Business Impact: The consequences can include remote code execution, credential exposure, lateral movement, service disruption, or broader compromise of the domain.
| Framework | Reference |
|---|---|
| NIST CSF 2.0 | PR.IP-1 (Baseline Configuration), PR.DS-2 (Data-in-Transit is Protected) |
| CIS Controls | Control 4 (Secure Configuration of Enterprise Assets and Software), Control 7 (Continuous Vulnerability Management) |
| MITRE ATT&CK / DEFEND | T1210 (Exploitation of Remote Services), T1021.002 (Remote Services: SMB/Windows Admin Shares) |
| DISA STIG | V-254275, V-254276, V-254277 |
| Microsoft Security Baselines | Remove or disable SMBv1 and migrate legacy dependencies to supported SMB versions |
Frequently Asked Questions
No. SMBv1 is not installed by default on Windows Server 2019 and later. Microsoft has publicly deprecated the protocol since 2014. If SMBv1 is present on a newer domain controller, determine why it was installed or retained.
It can, if a legacy device or application genuinely depends on it. That's why it's important to create an inventory of dependencies before disabling the protocol, along with a documented rollback plan.
Complete removal is preferable when nothing depends on it.
Disabling the SMBv1 server protocol prevents the server from accepting SMBv1 connections. Removing the optional Windows feature eliminates the legacy component from the operating system.
It depends on the method. Utilizing Set-SMBServerConfiguration does not require a restart. However, removing or disabling the SMBv1 Windows optional feature does require a restart.
Close the Gap Legacy Protocols Leave Open
A single legacy protocol setting on a domain controller can be the difference between a hardened environment and an easy target. Insight Recon flags SMBv1 and the other legacy configuration issues attackers look for first.
See exactly where your Active Directory is exposed and what to fix first.