SMB Signing and LDAP Channel Binding — Closing the "Other Half" of NTLM Defense in Practice

“We have started auditing NTLM, and we are fixing the connections that hard-code IP addresses too. So how do we prepare for relay attacks during the months it takes to remove every dependency?”

The defense for that interval is SMB signing, together with LDAP signing and LDAP channel binding. These are not settings that stop NTLM itself; they are settings that block, at each destination, attacks that relay authentication onto a different connection. Run them in parallel with reducing NTLM, and treat them as hardening that stays in place after NTLM is retired.¹²

The approach is the same for both: audit, fix the applications and devices that connect, then enforce. The settings you check and the events you read differ between SMB and LDAP, though. This article separates their roles first, and then explains the check, fix, and rollout procedure for each.

This is the third article in the NTLM series. For the NTLM auditing procedure, see “Will NTLM Deprecation Stop Your Business Apps?”; for how the authentication protocols work, see “NTLM and Kerberos Explained with Diagrams”.

1. The Bottom Line First: Separate the Three Defenses by Destination

LDAP signing is integrity verification, LDAPS is TLS encryption of the whole connection, and channel binding is the tie between authentication and the TLS channel. “We moved to LDAPS” does not mean the same thing as “we validate CBTs.” A simple bind, moreover, has no CBT and falls outside channel binding validation. Chapters 5 and 6 cover each of these separately.³⁴

For SMB, Windows 11 24H2 Enterprise, Pro, and Education require signing by default in both directions, and Windows Server 2025 requires it by default on the outgoing side. Home is outside the scope of this change, so check the edition as well as the OS version.⁵

For LDAP, on the other hand, the series of updates in KB4520412 that this article cites does not change the default policy for signing or channel binding. You have to distinguish between having installed the update and having configured enforcement. Do not generalize what this update says into a default value for every OS and deployment condition; check the configuration of the environment in front of you.⁴

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (28 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Why Signing Is Needed: Protection While You Reduce NTLM

2.1. An Attacker Can Relay the Authentication, but Cannot Produce a Valid Signature

NTLM’s fundamental weakness is that it has no mutual authentication. Because a client cannot verify a server’s identity, an attacker can pose as the real server, have the client authenticate against it, and relay that authentication response on to the real server. This is the relay attack. Microsoft, too, documents that NTLM and NTLMv2 authentication are vulnerable to SMB relay and man-in-the-middle attacks.²

Stopping NTLM entirely makes this NTLM relay impossible. Inventorying and fixing the dependencies covered in the first article takes months, however. Signing is what protects the destinations in the meantime.

flowchart LR
    CL["Client"]
    AT["Attacker<br/>(fake server)"]
    SV["Real server"]

    CL -->|"1. Authentication response"| AT
    AT -->|"2. Relayed as-is"| SV
    SV -.->|"3. If signing is required:<br/>the attacker has no session key and<br/>cannot produce a valid signature, so it fails"| AT

Figure 1: An attacker that has merely relayed the authentication response cannot produce a valid signature from the session key

As a result of authentication, the parties holding the session key used for signing are the client and the real server. An attacker that has merely relayed the authentication response does not hold that key and cannot forge later messages on a connection where signing is required. The division of labor is SMB signing for relays into SMB, and LDAP signing plus channel binding for relays into a domain controller’s LDAP/LDAPS.

2.2. Keep Migrating to Kerberos Even After You Require Signing

To get more out of signing, check the authentication method as well. Because the session key derives from the password, the recommendation is to use Kerberos rather than NTLMv2 so that you start from a stronger key. Microsoft also lists not using IP addresses or CNAMEs to connect to a share.¹

The reason is that connecting by IP address, or by an alias with no matching SPN registered, causes NTLM rather than Kerberos to be used. SPN registration for aliases you intend to keep using is covered in the first article.

Reducing NTLM dependencies and requiring signing are measures you carry out at the same time. Tamper detection through signing, and channel binding, both apply to Kerberos-authenticated sessions as well, so they are not settings you remove once NTLM is retired.¹

3. SMB Signing: Check How It Works and What the Defaults Are

3.1. Separate “Supports Signing” From “Requires Signing”

SMB signing attaches a signature to each message using the session key and a cipher suite. The signature in the SMB header includes a hash of the entire message plus the identities of the sender and the receiver, so it stops matching if anything is tampered with along the way. That is the tamper detection, and it is what defends against impersonation and relay.¹

The axis to look at in the configuration is not simply enabled versus disabled, but whether signing is required. From SMB 2.x onward, EnableSecuritySignature is ignored and only RequireSecuritySignature carries meaning. If either the client or the server requires it, that connection is signed. A connection goes unsigned only when neither side requires it.¹

Signing does cost computation, but the algorithm has moved from MD5 in SMB1 to HMAC-SHA-256 in SMB 2.02 and AES-CMAC in SMB 3.0, and Windows Server 2022 and Windows 11 added acceleration based on AES-128-GMAC. Do not defer it on the strength of an old impression that signing is slow; measure it on a pilot machine and decide from that.¹

3.2. Check the OS, the Edition, and the Outgoing and Incoming Directions

Start by checking the OS edition and version under Settings > System > About. In the table below, outgoing means the PC connecting as an SMB client, and incoming means it accepting connections as an SMB server. Find the row your own machines and servers fall into.

The top three rows are defaults Microsoft states explicitly.⁵ The bottom row, the domain controller, is a separate long-standing condition: it requires SMB signing from anything that connects to SYSVOL or NETLOGON. Group Policy and logon script distribution have run on the assumption of signing for a long time.¹

Even on Windows 11 24H2, Home requires signing in neither direction and is outside the scope of this default change. The claim that merely updating a Home machine makes signing required does not apply. This table does not guarantee future changes or individual settings, so when you hit a connection failure, check the edition and then check the actual configured values from Section 4.1 as well.⁵

On Enterprise, Pro, and Education, updating to 24H2 makes SMB connections from that PC require signing by default. Windows itself supports signing, so the peers to inventory first are third-party devices that do not support it or have it disabled. Check older NAS units, the settings involved in scan-to-folder on multifunction printers, Samba on embedded Linux, and the like.

4. SMB Signing: Audit, Fix the Devices, Then Require It

4.1. Check the Current Signing Requirement and the Policies That Manage It

# Signing requirement on the client side (outgoing)
Get-SmbClientConfiguration | FL RequireSecuritySignature

# Signing requirement on the server side (incoming)
Get-SmbServerConfiguration | FL RequireSecuritySignature

True means required, False means not required. Check the outgoing and the incoming side separately.⁵

In Group Policy, these are managed under Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Use the following two settings for their respective roles.¹

The word “always” in the policy name is what means “required.” If you do not yet know which devices lack support, do not enforce this everywhere at this stage; move on to the auditing below.

4.2. Use Auditing to Find the Peers That Cannot Sign

From Windows 11 24H2 onward, auditing is available that detects third-party clients and servers which do not support signing or encryption. The following commands enable it for signing.¹

# Server side: detect clients that do not support signing
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# Client side: detect servers that do not support signing
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

The server side examines the clients that connect to it; the client side examines the servers it connects to. In Group Policy, the equivalents are settings such as “Audit client does not support signing” under Lanman Server and Lanman Workstation in Computer Configuration\Administrative Templates\Network.¹

The same auditing feature also has -AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption for finding peers that do not support encryption. Those are preparation for requiring SMB encryption in the future, though. Some devices support signing but not encryption, so do not mix the encryption audit results into your decision that signing enforcement is ready.¹

The logs and event IDs used by the signing and encryption audits are as follows. Read the body of each event as well, and confirm that it is the signing problem you are investigating here.¹

In Event Viewer, check them as follows.

1. Open eventvwr.msc and go to Applications and Services Logs > Microsoft > Windows > SMBClient > Audit. For the server side, open SMBServer > Audit at the same level.
2. Use “Filter Current Log” in the right pane and specify event IDs 31998,31999, or 3021,3022 on the server side.
3. Open the events, check the type of problem and the information about the peer, and build a list of devices that cannot sign.

To collect them in bulk with PowerShell, use the following example.

# Client side: audit events that detected servers not supporting signing
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

# Server side: audit events that detected clients not supporting signing
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBServer/Audit'; Id=3021,3022 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

This example retrieves the signing and encryption audit IDs together. Do not treat every event shown as a case of missing signing support; separate signing from encryption using Message.

If there are no matching events — right after you enable auditing, for instance — Get-WinEvent returns a “no events found” error. The -ErrorAction SilentlyContinue in the example is there to suppress it. For how to write the filters, see also “Investigating Event Logs in Practice with Get-WinEvent”.

Run the audit, as with the NTLM audit, until the business cycle has come around once. Logs from immediately after you enable it do not amount to having checked every destination.

4.3. Fix Signing Errors and Guest Blocking Separately

Connecting from an environment that requires signing to a peer that cannot sign produces the following error.⁵

0xc000a000
STATUS_INVALID_SIGNATURE
The cryptographic signature is invalid.

The other case is a refusal of guest access. Guest access cannot be used on a connection that requires signing either, so a NAS used without authentication produces an error like the following.⁵

You can't access this shared folder because your organization's security policies
block unauthenticated guest access.

The first remedy is to enable SMB signing on the device and connect with credentials rather than as a guest. If necessary, consider a firmware update or a change to the connection path.

The workaround of setting Set-SmbClientConfiguration -RequireSecuritySignature $false on the client relaxes the signing-error side. Guest blocking is also governed by a separate client setting that disallows insecure guest logons, so removing the signing requirement alone does not clear the refusal of guest connections.

Microsoft recommends neither disabling signing as a workaround for third-party devices nor trying to use signing with a guest account.⁵ Even where you do need to relax something, do not make it normal practice; manage it as a time-limited exception until the device is replaced.

4.4. Move From a Pilot to a Full Rollout

The more editions fall under 24H2 and later, the more clients require signing by default. The effective deadline is set by your OS update plan, so include this auditing and these device fixes in the prerequisite work for migrating to Windows 11. Migration strategy from Windows 10 is covered in “Options After Windows 10 End of Support”.

5. LDAP Signing: Check the Bind Types Before You Enforce

After SMB come LDAP connections to domain controllers and AD LDS. Unsigned LDAP traffic is weak to replay attacks and man-in-the-middle attacks, and the server risks making decisions based on requests that have been intercepted and altered.³

Start by separating the kinds of “bind” used for authentication.

Requiring LDAP signing rejects SASL binds that do not require signing and simple binds over plaintext (non-SSL/TLS) connections. Signing is integrity verification, which is separate from encryption. A simple bind has no signing framework, so for anything that has to keep using simple binds, the decision is to move it to LDAPS.³

5.1. Read the Events as “Counts” and “Sources” Separately

LDAP signing, and channel binding in the next chapter, both use the domain controller’s Directory Service log. In Event Viewer, open Applications and Services Logs > Directory Service.

The distinction to draw is between aggregate events that show how much remains (2887 and 3040) and individual events that identify the source (2889, 3039, 3074, and 3075). While problematic connections remain, fix them instead of moving to enforcement.

The phrase “available without manual enablement” in the table describes the update making the auditing feature usable. Do not read it as meaning the events always appear in every configuration; check the OS, the updates applied, and the diagnostics settings against KB4520412. Chapter 6 also separates out the point that simple binds fall outside CBT validation.⁴

5.2. Use 2887 to See What Remains, and 2889 to Identify the Source

For LDAP signing you use 2886, 2887, 2888, and 2889. 2886 is a reminder prompting you to configure it, 2887 is the 24-hourly count of problem binds, and 2888 is the count after rejection is configured. Only 2889, the one that tells you the source, is absent by default.³

First check 2887 for whether unsigned binds remain. If the count is non-zero, set the “16 LDAP Interface Events” diagnostics setting to 2 (Basic) so that 2889 is recorded, and find the source IP address and the identity used to authenticate.³

2889 is not an aggregate but a record for each affected bind. In an environment where high-frequency connections remain, it fills the Directory Service log quickly, so return the diagnostics setting to its original level (0 by default) once you have identified the sources. If you intend to keep recording it, arrange log forwarding and retention capacity first.

The things to investigate are AD authentication and HR system integration in business systems, LDAP address book lookups on multifunction printers, LDAP authentication on network appliances, and the like. Devices in particular are often configured for plaintext simple binds, so check their LDAP settings. The fix is to switch to LDAPS (port 636) or to a signed SASL bind. Chapter 7 collects concrete examples.

5.3. Require Signing After the Fixes, and Verify the Rejection Behavior

Once the sources are fixed, configure the following in Group Policy.³

Use ldp.exe to verify the configuration. Connect to port 389 without TLS and attempt a simple bind; if you get the following error, the rejection setting is in effect. This is a test of the rejection behavior, not a procedure for using plaintext binds in production. Do it with credentials meant for testing.³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAP Channel Binding: Check Authentication Over LDAPS Too

6.1. TLS Encryption and Tying Authentication to the Channel Are Different Things

LDAPS encrypts the traffic with TLS. Encryption alone is not enough, however, against a relay that has the client authenticate and then forwards that authentication onto a separate TLS connection of the attacker’s own. The channel binding token (CBT) is a value that ties authentication to that TLS channel itself, making a relay onto another channel detectable.⁴

What it covers is connections that perform Windows authentication (a SASL bind) such as NTLM or Kerberos over LDAPS. A simple bind has no CBT and falls outside this validation. What protects a simple bind over LDAPS is TLS encryption and credential management; setting the value to Always does not make simple-bind clients show up in the CBT audit events.

6.2. Map the Values 0, 1, and 2 to the Policy Settings

Control this through the registry on the domain controller, or through the corresponding Group Policy setting.⁴

When supported and Always are not the same. Keep the stage that validates clients which support it separate from the stage that always requires validation on covered connections, and move to Always only after you have confirmed the state of support.

6.3. Use 3039, 3040, 3074, and 3075 to Find the Sources

Looking in more detail at the channel binding events in the quick-reference table in Section 5.1 gives the following. The March 10, 2020 update added the related events, and updates from 2023 onward expanded the auditing.⁴

Microsoft’s own rollout procedure follows the same order: monitor 2889, 3039, and 3074/3075 in the Directory Service log on every domain controller, identify the problematic devices, check with their vendors, and enforce once they are handled.⁴

Do not treat using LDAPS as the end of the job; look at the authentication method and CBT support as well. The distinction drawn in Section 6.1 also tells you not to go looking for out-of-scope simple binds in the CBT events alone.

6.4. Do Not Conclude That Applying the Update Means Enforcement Is Done

KB4520412 states that the March 10, 2020 update, and the series of updates the document covers, do not change the default policy for LDAP signing or channel binding.⁴

In an environment where the update has merely been applied and nothing has been enforced, therefore, the configuration work still falls to the administrator. Do not confuse this with the SMB default change in 24H2; confirm separately that the auditing feature is available and that the defense is enforced. While you can still choose when to enforce, plan and carry out the fixes on the connecting side.

7. Fix Business Applications and Devices by Cause

7.1. Match the Peers That Appear in the Events to a Fix

Missing signing support, guest operation, plaintext simple binds, and missing CBT support all need fixing in different places. Even when the symptom is the same “cannot connect,” do not relax settings across the board; choose the response from the event and the connection method.

7.2. For .NET Applications, Check the Authentication Method and the TLS Settings

In an in-house .NET application, first check whether it is sending an AuthType.Basic simple bind to plaintext port 389. The following is a bad example, one that gets rejected once LDAP signing is enforced. It is not an example meant to be run with real credentials.

// Bad example: a simple bind to plaintext port 389. Rejected once LDAP signing is enforced
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));

For the fix, where a domain environment lets you choose, make Negotiate plus a request for signing and encryption the baseline. If a simple bind is required, use LDAPS. The two examples below are excerpts that contrast these options. They are not meant to be run following on from the bad example above.

// Good example 1: request Negotiate plus signing and encryption (Kerberos is chosen when the SPN and name resolution line up)
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Negotiate;
conn.SessionOptions.Signing = true;
conn.SessionOptions.Sealing = true;
conn.Bind();  // Authenticate as the account the process is running under

// Good example 2: if you use a simple bind, always use LDAPS
var id = new LdapDirectoryIdentifier("dc01.corp.example.com", 636);
var conn2 = new LdapConnection(id);
conn2.SessionOptions.SecureSocketLayer = true;
conn2.AuthType = AuthType.Basic;
conn2.Bind(new NetworkCredential(user, password));

Negotiate in good example 1 prefers Kerberos, but does not force it. Under conditions such as connecting by IP address, or an SPN being unregistered or duplicated, it falls back to NTLM. Even then, the signing and encryption the code asked for still take effect.

To confirm that Kerberos authentication is working, use klist to check that a ticket for the service in question has been obtained. If you set the outgoing NTLM auditing in the first article to “Audit all,” the absence of event 8001 is corroborating evidence as well. Concluding that “there is no 8001” while the audit policy is still disabled means nothing, however.

The simple bind in good example 2 is encrypted by TLS, but it is not subject to CBT validation. What matters is not treating it as the same defense as good example 1. If you use DirectoryEntry (ADSI), specify AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing explicitly.

The principle of writing the destination as an FQDN rather than an IP address applies to SASL binds with Kerberos too. Fix name resolution and SPNs along with it, rather than stopping once you have changed only the authentication method in the code.

8. Summary: Complete the Audit, the Fixes, and the Enforcement on Each Path

SMB signing, LDAP signing, and LDAP channel binding are not a substitute for the settings that stop NTLM. They are defenses that prevent relays while you reduce NTLM dependencies, and permanent hardening that stays in place after the migration to Kerberos.¹²

For SMB, check the OS, the edition, and the outgoing and incoming defaults, and fix the devices that do not support signing and the guest-based setups first. Your plan for updating to the affected editions of Windows 11 24H2 becomes the deadline for that preparation. For LDAP, investigate unsigned binds through 2887 and 2889 and CBT-related problems through 3039, 3040, 3074, and 3075, and enforce only after the sources are fixed.⁵³⁴

Applying an update, enabling an auditing feature, and enforcing a defense are separate stages. In particular, do not conclude that enforcement is done merely because you installed the LDAP updates from KB4520412. Check it with the fact that simple binds fall outside CBT validation in mind as well.⁴

In your own applications, simply eliminating plaintext simple binds and hard-coded IP addresses is already a large improvement. Judge the finish line not by “we changed the setting” but by whether you completed a full business cycle of auditing and fixing, confirmed the behavior in a pilot, and then moved to enforcement.

Related Articles

• Will NTLM Deprecation Stop Your Business Apps? — How to Collect Audit Logs, and the Order in Which to Kill Dependencies
• NTLM and Kerberos Explained with Diagrams — Why Authentication Falls Back to NTLM
• Pitfalls of Network Drives and UNC Paths — Working With File Servers (Shared Folders) From a Business Application
• Investigating Event Logs in Practice with Get-WinEvent — Filtering Speed Decides How Long the Investigation Takes
• Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement
• A Minimum Security Checklist for Windows App Development

Related Consulting Areas

KomuraSoft LLC handles modifications to business applications that come with enforcing SMB signing and LDAP signing, and investigation of connection failures around authentication and file sharing.

• Windows App Development
• Bug Investigation & Root Cause Analysis
• Legacy Asset Reuse & Migration Support
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

If we require SMB signing, won't the file server get slower?

The computational cost of signing is not zero, but the algorithm has improved with every generation. Against MD5 in SMB1, SMB 2.02 uses HMAC-SHA-256 and SMB 3.0 uses AES-CMAC, and Windows Server 2022 and Windows 11 added signing acceleration based on AES-128-GMAC. Domain controllers have also long required SMB signing from every peer that connects to SYSVOL and NETLOGON, so Group Policy distribution has always run on the assumption that signing is in use. Before ruling it out for performance reasons, we recommend requiring it on a pilot machine first and measuring the result. Any perceptible difference is confined to specific usage patterns, such as transferring large files continuously.

Our NAS stopped connecting after we moved to Windows 11 24H2. Is SMB signing the cause?

Typically, yes. Windows 11 version 24H2 Enterprise, Pro, and Education require SMB signing by default for both outgoing and incoming connections, so connecting to a third-party NAS that does not support signing (or has it disabled) fails with 0xc000a000 (STATUS_INVALID_SIGNATURE). Because requiring signing also disables guest access, a NAS configured for unauthenticated use produces the error "You can't access this shared folder because your organization's security policies block unauthenticated guest access." The first remedy is to enable SMB signing on the NAS and connect with credentials rather than as a guest. There is a client-side workaround that disables the signing requirement, but it only clears the signing-error side. Guest connections are blocked by a separate client setting that disallows insecure guest logons, not by signing, so they keep failing unless that setting is relaxed as well. Microsoft recommends neither disabling signing nor operating with guest accounts.

What is the difference between LDAP signing and LDAPS (LDAP over SSL/TLS)?

They are different things. LDAP signing requires integrity verification (signing) on the SASL binds (Negotiate, Kerberos, NTLM, Digest) carried over an LDAP connection on port 389; it does not encrypt the traffic. LDAPS encrypts the entire connection with SSL/TLS. LDAP channel binding is a further layer on top of LDAPS: by tying authentication to the TLS channel, it prevents attacks that relay only the credentials onto a different TLS connection. To protect a domain controller, think of it as three measures together: stop plaintext simple binds, require signing on SASL binds, and require channel binding token validation for Windows authentication (SASL binds) over LDAPS. Note that a simple bind has no CBT and falls outside channel binding validation; what protects a simple bind over LDAPS is the TLS encryption itself.

In what order should we tighten these?

The order is audit, then fix, then enforce, the same as it was for restricting NTLM. Start with SMB: enable the auditing available from Windows 11 24H2 onward that detects peers which do not support signing, and use it to inventory the devices that cannot sign. For LDAP, check event 2887 (the 24-hourly count of unsigned binds) in the domain controller's Directory Service log; if the count is non-zero, set the "16 LDAP Interface Events" diagnostics setting to 2 and identify the clients from event 2889. For channel binding, do the same with events 3039 and 3040 plus the audit events 3074 and 3075 added by updates from 2023 onward. Once every problematic source is fixed, switch over: require SMB signing, require LDAP signing, and move channel binding to Always. The one principle is never to jump straight to enforcement.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.