SMBv1 dependency evidence: attempts, dialects and scope

SMBv1 dependency evidence should connect an observed client attempt to a server, a workflow and an owner. An old operating-system label in Active Directory can help prioritize investigation, but it cannot establish which SMB dialect a device uses today. Before removing SMBv1, build a record that distinguishes configuration, attempted use, established connections and gaps in observation.

This guide describes a verification and remediation workflow for AD environments. The commands below are documented examples for an authorized Windows administrator to run on the intended systems; they were not executed against a real domain for this article. No sample output is presented as a measured result.

What Is SMBv1 Dependency Evidence?

A dependency is an operational claim: a named business workflow still needs SMBv1 to complete. That claim needs stronger support than a directory attribute, a component installed on disk or a statement that a device is old. Treat each of those as an investigation input and record what observation would confirm or weaken the claim.

The review should answer three questions. Which server and client are involved? What operation needs to succeed? What evidence connects the protocol observation to that operation? If the owner cannot answer them, the dependency remains unverified. That does not make removal harmless; it means the decision needs a scoped pilot and further collection.

Use an evidence record with separate entries for configuration, server attempts, client snapshots and workflow results. Keeping these entries separate prevents a familiar error: using a modern connection captured from one desktop to close a finding about another device, another identity or an overnight job.

How the Evidence Fits Together

Start from the workflow rather than from an estate-wide switch. Ask the service owner to list its destinations and callers, including periodic tasks that might not run during an interactive test. Record which Windows systems can supply server auditing or client observations and which devices need another collection method. An appliance that cannot run the proposed commands belongs in the unresolved population until its owner supplies suitable evidence.

Choose a collection window that includes the relevant operational cycle. A daily foreground test does not exercise a monthly export. There is no universal duration prescribed here: the owner must justify the window using the actual schedule and any unusual or recovery operations that matter. Record start and end times, excluded workflows, missing hosts and interruptions in collection.

For each observation, preserve the source host and context before drawing a conclusion. A timestamp alone is insufficient if the server and client records cannot be tied to the same destination and operation. Where the link cannot be established, mark the correlation as unresolved instead of treating proximity in time as proof.

Detection: Verify Configuration, Attempts and Connections

Step 1: Inspect the Windows component and server setting

Microsoft documents these checks in its SMB protocol management guide. Use the commands appropriate to the Windows system under review, and keep their outputs as separate evidence items. Run the optional-feature commands in an elevated PowerShell session, as the Learn guide requires.

Get-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Get-SmbServerConfiguration | Select EnableSMB1Protocol

The first reports the optional feature state; the second reports the SMB server setting. Record the returned state and the role of the inspected host. A server setting does not describe every outbound connection from that host, and a feature state does not establish whether a business operation used it. If a command is unavailable or fails on the target, preserve the failure and choose an applicable inspection method before declaring the host covered.

Avoid using a historical default to fill in a missing observation. The decision record should contain the actual result from the inspected system, its collection time and the reviewer who interpreted it. Keep the pre-change results for comparison after remediation.

Step 2: Enable server auditing and preserve Event 3000

For the approved server scope, Microsoft documents this audit setting:

Set-SmbServerConfiguration -AuditSmb1Access $true

Verify the setting:

Get-SmbServerConfiguration | Select AuditSmb1Access

The same Learn guide identifies Event ID 3000 in Microsoft-Windows-SMBServer/Audit as a client attempt to connect using SMBv1 after auditing is enabled. Preserve the event and the audit-state evidence together. An Event 3000 is not proof of successful share access, exploitation or a complete dependency inventory.

Assign each attempt to an investigation record. Use the client information actually available in the event and supporting inventory to identify an owner; do not invent a client identity when the correlation is missing. Ask the owner what operation was running and obtain its result. Classify the record as a mapped attempt, an unresolved attempt or a workflow requiring more observation.

An unsuccessful attempt still deserves explanation, but it does not establish that the workflow requires SMBv1 to succeed. Conversely, a workflow that was never exercised cannot be cleared simply because the server log has no relevant entries.

Step 3: Capture the active client's connections

Run the documented client check while the identified operation is active:

Get-SmbConnection

Microsoft's Get-SmbConnection reference describes established client-to-server connections and exposes the Dialect field in its examples. Rows are distinguished by share, user logon and credentials used. Preserve that context rather than collapsing all rows into a single answer for the machine.

Attach the snapshot to the workflow record with the collection time and actual returned values. A modern dialect on a matching connection supports that observed path at that moment. It does not clear other shares, identities, devices or scheduled runs. A missing row is not a historical record of all SMBv1 activity; another observation method may be needed for the unresolved path.

Step 4: Reconcile the evidence before deciding

Compare the event, client snapshot and workflow result. If they refer to different callers or operations, keep separate records. If an attempt is visible on the server but no matching established connection is captured, preserve both observations without manufacturing a success or a dialect.

Remediation: Replace the Dependency and Revalidate SMB2/3

Step 1: Make the dependency decision reviewable

For each affected workflow, record whether it will be retired, upgraded or moved to a replacement device or service. Name the owner, intended completion date, approved pilot scope and recovery plan. If the dependency is unresolved, state exactly which observation is missing and who will obtain it.

The pilot should include the client and server paths discovered during collection. Do not base an estate-wide change on a single successful connection. Include the periodic operations identified at the planning stage, or document that their validation is still pending.

Step 2: Apply the approved SMBv1 change

Microsoft documents the following command for disabling SMBv1 on the server component:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

For the applicable Windows optional feature, the documented command is:

Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol

Select the method appropriate to the target and intended scope. These changes are not interchangeable evidence: disabling the server protocol and disabling an optional feature address different configuration layers. The Learn guide describes a restart for the optional-feature change, while Set-SmbServerConfiguration does not require a restart. Schedule any restart impact with the owner and retain the returned result rather than assuming the change completed.

If compatibility fails, return to the workflow record and the intended replacement. A recovery decision should identify the specific affected service and owner; it should not silently redefine the baseline for unrelated hosts.

Step 3: Repeat observations on the changed scope

Repeat the applicable feature and server checks, then exercise the intended operations. Capture client connections during those operations and retain server audit coverage across the justified window. Compare the pre-change and post-change records using the same host, share and workflow identifiers.

Close a dependency record only when the owner can explain what changed and supply evidence that the required workflow still works on the intended SMB2/3 path. Keep untested periodic operations and unavailable devices open. A configuration result, a passing business test and a connection snapshot answer different questions; the closure record needs the relevant combination.

Record residual attempts after the change and investigate their callers. Their presence does not automatically mean that a business workflow failed, and their absence does not establish full coverage. Keep the interpretation tied to the original audit scope and window.

How EtcSec Detects This

In the reviewed etc-collector implementation, COMPUTER_LEGACY_PROTOCOL is a directory-based triage signal. Its Detect method examines enabled computer accounts. It first matches five case-insensitive OS patterns: Windows XP, Windows 2000, Windows NT, Server 2003 and Windows Vista. A match adds the computer to the affected list and continues to the next computer.

For computers that do not match that branch, the detector checks whether SupportedEncryptionTypes is nonzero and has neither AES bit in the 0x18 mask. The OS branch takes precedence: a computer matched there does not also contribute to the weak-encryption reason count. The method returns one aggregated finding, including when its affected count is zero.

The LDAP provider reads operatingSystem and msDS-SupportedEncryptionTypes into the computer model. These are directory attributes, not measurements of live SMB traffic. The integer parser returns zero for an absent value and discards conversion errors, so its result does not preserve those cases as distinct collection outcomes. The detector skips a zero encryption value; that does not establish modern protocol use.

The check does not observe an SMB dialect, an NTLM version, actual DES/RC4 use, Event 3000 or business-workflow success. An affected computer requires further investigation, and a zero count cannot close the SMBv1 dependency review. Use the finding to prioritize the evidence workflow above.

If the reason is the encryption attribute, follow the separate Kerberos RC4 fallback guide for distinguishing directory settings from ticket evidence. If the review raises a signing question, use the SMB signing guide for signature requirements and relay exposure. Neither review substitutes for the SMBv1 attempt and dependency evidence collected here.

Decision Record and Primary References

Before closing the review, retain explicit answers to these review questions:

1. Which servers and workflows were audited, and did the window include their periodic tasks?
2. Which Event 3000 attempts were mapped to a client and owner, and what outcome was verified for each operation?
3. Which dependency was removed or replaced, and what evidence revalidates the required SMB2/3 workflows?

Attach the original configuration results, audit window, events, client snapshots, owner decisions and post-change validation. Where evidence remains missing, state the gap and next action. This is a proposed review method, not a claim that any domain has passed these checks.

• Microsoft Learn: Detect, enable, and disable SMBv1, SMBv2, and SMBv3
• Microsoft Learn: Get-SmbConnection