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

“We’ve started auditing NTLM, and we’re fixing the places that hard-code IP addresses too. So — until we’ve finished killing off every dependency — how do we defend against relay attacks in the meantime?” That was the single most common question after we published the previous article, “Will NTLM Deprecation Stop Your Business Apps?”.

The answer is what this article covers: SMB signing, and LDAP signing together with LDAP channel binding. Neither is a measure for “stopping NTLM” — both are defences for making sure that, while NTLM is still around, relay attacks (forwarding stolen authentication on to another target) do not succeed. One of the two, SMB signing, has already had its default value actually changed in Windows 11 24H2 / Windows Server 2025, and it arrives together with the OS update whether you do anything or not. The other, LDAP signing and channel binding, has not had its defaults changed, and stays loose indefinitely unless an administrator tightens it. In short: for SMB the question is “do you get ahead of it, or deal with it after the OS update causes an incident”; for LDAP the question is “when do you choose to tighten it yourself”.

This is the third article in the NTLM series. The NTLM auditing procedure is covered in the first article, and how the protocol works is covered in the second article.

1. The Bottom Line First

• SMB signing attaches a tamper-detecting signature to every SMB message. The signature includes a hash of the whole message and the identities of the sender and receiver, giving protection against relay attacks and impersonation attacks.¹
• The default has already changed. In Windows 11 version 24H2 Enterprise, Pro, and Education, signing is now mandatory for both outgoing and incoming connections; on Windows Server 2025, it is mandatory outgoing only (Home does not make either mandatory).²
• Making signing mandatory also disables guest access. A NAS that doesn’t support signing, or any device that assumes a guest connection, will start failing to connect the moment the OS is updated. The error codes are 0xc000a000 (STATUS_INVALID_SIGNATURE) and the guest-blocking message (Section 4.3).²
• LDAP signing lets a domain controller refuse “SASL binds that don’t require signing” and “plaintext simple binds”. Unsigned LDAP traffic is vulnerable to replay attacks and man-in-the-middle attacks.³
• LDAP channel binding ties Windows authentication (a SASL bind) over LDAPS (SSL/TLS) to the TLS channel. The value used for this binding is called the channel binding token (CBT). Simple binds, which have no CBT, are outside the scope of this validation (Chapter 6). It is controlled by the registry value LdapEnforceChannelBinding (0/1/2) or by Group Policy.⁴
• Both proceed through the same three stages: read the audit events, fix the sources, then switch to enforcement. For LDAP signing, events 2887 and 2889 identify the sources; for channel binding, events 3039/3040 plus the audit events 3074/3075 do the same (Chapters 5 and 6).³⁴
• A crucial premise: none of these updates change the defaults on their own. Microsoft states explicitly, for the whole series of LDAP updates from March 2020 onward, that they do not change the default policy for LDAP signing or channel binding. Tightening it is the administrator’s job.⁴

2. Why Signing — The “Other Half” of the Relay Attack

As described in the second article, NTLM’s fundamental weakness is that it has no mutual authentication. A client cannot verify a server’s identity, so an attacker can pose as a genuine server, get the client to authenticate against it, and simply forward the resulting authentication response on to the real server. This is the relay attack, and Microsoft itself states explicitly that NTLM and NTLMv2 authentication are vulnerable to SMB relay and man-in-the-middle attacks.⁵

Stopping NTLM entirely would render this attack impossible, but as the first article showed, inventorying and fixing every dependency takes months. Signing is the defence for the time in between.

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,<br/>so it cannot forge a valid signature and fails"| AT

Figure 1: How relay attacks relate to SMB signing

The key point is that the signing key (the session key) is held, as a result of authentication, only by the client and the real server. An attacker who has merely relayed the authentication response does not have the session key, so in an environment where signing is mandatory it cannot forge later messages. SMB signing closes off relays against SMB; LDAP signing and channel binding close off relays against a domain controller’s LDAP/LDAPS.

There is one more practical point to note. The effectiveness of signing is not independent of which authentication protocol you use. The session key derives from the password, so if you’re authenticating with NTLMv2 rather than Kerberos, the key underpinning the signature is weaker. Microsoft itself lists using Kerberos and not connecting to a share by IP address or CNAME as conditions for maximising the effectiveness of SMB signing.¹ That’s because connecting by IP address, or by an alias for which no matching SPN is registered, causes NTLM to be used instead of Kerberos (registering an SPN if you want to keep using an alias is covered in the first article). In other words, reducing NTLM dependency and making signing mandatory are not separate initiatives — they are two sides of the same one.

3. SMB Signing — How It Works, and the Default That Has Already Changed

3.1. The Mechanism in One Minute

SMB signing uses the session key and the cipher suite to attach a signature to each message that flows over the connection. The signature includes, in the SMB header, a hash of the entire message, so tampering along the way causes the hash to stop matching. The hash also includes the identities of the sender and receiver, so impersonation can be detected as well.¹

The algorithm has been strengthened with every generation. SMB1 used MD5; SMB 2.02 moved to HMAC-SHA-256; SMB 3.0 moved to AES-CMAC; and Windows Server 2022 and Windows 11 introduced signing acceleration with AES-128-GMAC.¹ If your memory of “signing = slow” dates from the SMB1 era, it’s worth setting that aside and measuring again.

Think of the setting not as “enabled/disabled” but as “is it required (Require) or not”. From SMB 2.x onward, the EnableSecuritySignature setting is ignored, and only RequireSecuritySignature has any meaning. And if either the client or the server requires signing, that connection is signed. Signing is skipped only when neither side requires it.¹

3.2. A Decision Table for the Defaults

You don’t need to read all of this table. First check the OS and edition of your own machines and servers, and read only the row that applies to you. You can check the edition and version under Settings > System > About (“Edition” shows Pro/Home/Enterprise/Education and so on, “Version” shows something like 24H2).

The top three rows are the defaults explicitly documented by Microsoft.² The bottom row is longstanding behaviour: a domain controller requires SMB signing from every peer that connects to it. Group Policy and logon-script distribution have always operated on the assumption that signing is in use.¹

The Home edition alone is exempt from this default change. Neither outgoing nor incoming signing becomes mandatory, so updating to 24H2 does not, on a Home machine, cause connection failures due to mandatory signing (this isn’t a guarantee against future changes, but at least as of 24H2 it’s not part of the “deadline”). ² Put another way, behaviour diverges by edition even within the same 24H2 release. When triaging a report of “we updated and can no longer reach the share”, check the edition before you even check the version.

The practical upshot of this table is this: updating to Windows 11 24H2 (Enterprise, Pro, or Education) makes every SMB connection from that PC require signing (Home is exempt). If your in-house file server is Windows, nothing happens (Windows has supported signing across every version). Incidents happen with third-party devices that don’t support signing, or have it disabled — an old NAS, an MFP’s scan-to-share destination setting, an embedded Linux box running Samba, and so on.

4. Moving SMB Signing to “Required”

4.1. Checking the Current State

# Client-side (outgoing) signing requirement
Get-SmbClientConfiguration | FL RequireSecuritySignature

# Server-side (incoming) signing requirement
Get-SmbServerConfiguration | FL RequireSecuritySignature

True means required; False means not required.² If you manage this by Group Policy, the location is Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options, under “Microsoft network client: Digitally sign communications (always)” (client) and “Microsoft network server: Digitally sign communications (always)” (server). “Always” in the policy name means “required”.¹

4.2. Find “Peers That Can’t Sign” First (Auditing)

From Windows 11 version 24H2 onward, you can enable auditing that detects third-party clients and servers that don’t support signing or encryption.¹

# Server side: detect clients that don't support signing
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# Client side: detect servers that don't support signing
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

The same mechanism also provides auditing that detects peers that don’t support encryption (-AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption),¹ but that’s preparation for a future roadmap toward mandatory SMB encryption, separate from the signing track. Devices that support signing but not encryption are not unusual, so don’t mix encryption-audit events into your decision about whether the signing work is done.

Here’s where events are recorded.¹

Checking events takes three steps.

1. Open Event Viewer (eventvwr.msc) and, in the left-hand tree, open Event Viewer > Applications and Services Logs > Microsoft > Windows > SMBClient > Audit (to look at the server side, open SMBServer > Audit at the same level).
2. In the right-hand pane choose “Filter Current Log” and enter 31998,31999 (server side: 3021,3022) in the “All Event IDs” field.
3. Open the remaining events, which contain information about the peer that didn’t support signing. Feed this into your device inventory.

If you’d rather collect them in bulk with PowerShell:

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

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

If there are no records yet right after you enable auditing, Get-WinEvent returns an error saying no matching events were found (that’s why -ErrorAction SilentlyContinue is used above). How to write filters is covered in “Investigating Event Logs in Practice with Get-WinEvent”.

In Group Policy, the equivalent settings are “Audit client does not support signing” and similar entries under Lanman Server / Lanman Workstation, located under Computer Configuration\Administrative Templates\Network.¹ The approach to audit duration described in the first article (run it until the business has gone round once) applies here just as it did there.

4.3. Know the Failure Patterns

Connecting to a peer that can’t sign, in an environment where signing is required, produces the following error.²

0xc000a000
STATUS_INVALID_SIGNATURE
The cryptographic signature is invalid.

There’s another easy-to-miss case: guest access. Making signing mandatory also disables guest access. Connecting to a NAS configured for unauthenticated (guest) access produces an error like the following.²

You can't access this shared folder because your organization's security policies
block unauthenticated guest access. These policies help protect your PC from
unsafe or malicious devices on the network.

The order of priority for fixing this is clear. First, enable SMB signing on the device itself and authenticate with credentials instead of as a guest. Setting Set-SmbClientConfiguration -RequireSecuritySignature $false on the client avoids the signing error (0xc000a000), but the guest block comes from a different client setting (disallowing insecure guest logons), and merely relaxing signing does not resolve it. Microsoft recommends neither disabling signing nor trying to use signing with a guest account as a workaround for third-party devices.² If you do relax it, treat it as a time-boxed exception until that device is replaced.

4.4. Rollout Order

Note that, as more machines run 24H2 or later, “the client requires signing by default” becomes true for a growing share of the estate, so your effective deadline is really set by your OS update plan. If your organisation is moving to Windows 11 24H2 or later as part of Windows 10 end-of-support work, include this verification in the prerequisites for that migration (“Practical Options After Windows 10 End of Support”).

5. LDAP Signing — Protecting the Path to the Domain Controller

This chapter and the next revolve around the kind of “bind” involved, so let’s fix two terms first.

In other words, “making LDAP signing mandatory” means requiring signing on SASL binds and refusing simple binds over plaintext connections.

After SMB comes LDAP. Unsigned LDAP traffic to a domain controller (or AD LDS) is vulnerable to replay attacks and man-in-the-middle attacks. If an attacker intercepts and modifies a packet and forwards it to the server, the server may act on that forged request.³

Enforcing LDAP signing means getting the directory server to refuse the following two kinds of bind.³

1. SASL binds that don’t require signing (integrity verification) (SASL here covers Negotiate, Kerberos, NTLM, and Digest)
2. Simple binds carried out over a plaintext (non-SSL/TLS) connection

5.1. Event ID Quick Reference (Common to LDAP Signing and Channel Binding)

Let’s collect up front the event IDs that appear in this chapter and the next. All of them are recorded in the domain controller’s “Directory Service” log (Event Viewer > Applications and Services Logs > Directory Service). This table is written so you can build your audit design straight from it.

The distinction is simple. The count events (2887, 3040) show “how many are still left”; the individual events (2889, 3039, 3074, 3075) show “where they’re coming from”. You don’t move to enforcement until the count reaches zero. From here, Section 5.2 looks in detail at LDAP signing, and Chapter 6 at channel binding.

5.2. Audit First — Events 2886/2887/2889

The domain controller’s Directory Service log already gives you a starting point. Of the events in the Section 5.1 table, 2886, 2887, 2888, and 2889 relate to LDAP signing; of these, 2887 shows “how many unsigned binds there still are”, and 2889 shows “where they’re coming from” (2888 is the count taken after rejection has been configured).³

2889 alone is not recorded by default. Raising the “16 LDAP Interface Events” diagnostics setting to 2 (Basic) makes it record.³ The procedure, then, is: first check the 2887 count to see whether there are any unsigned binds at all, and if it isn’t zero, enable 2889 to identify the sources. One thing to watch is that 2889 isn’t a count — it’s recorded for every occurrence of the bind in question — so in an environment where legacy binds are frequent, it can fill up the Directory Service log fast. Once you’ve identified the sources, put the diagnostics setting back to its previous level (0 by default). If you plan to keep it running continuously, arrange log forwarding and retention first.

Typical sources are business systems doing LDAP integration (authentication federation, HR system links), an MFP’s LDAP address-book lookup, and LDAP authentication on network devices. In particular, the “LDAP server settings” on MFPs and other devices are often set to plaintext simple binds, so those should be your first suspects. The fix is to switch the device’s or application’s setting over to LDAPS (port 636) or a signed SASL bind.

5.3. Enforcing It

Once you’ve fixed every source, enforce it with Group Policy.³

• On the domain controller side: set “Domain controller: LDAP server signing requirements” under Security Options in the Default Domain Controller Policy to “Require signing”
• On the client side: set “Network security: LDAP client signing requirements” to “Require signing”

You can verify this with ldp.exe. Connect to port 389 and attempt a simple bind; if the configuration is in effect you should get the following error.³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAP Channel Binding — Defence on the LDAPS Side

“We’re already on LDAPS, so we’re fine” — channel binding closes the hole left behind by that assumption. LDAPS encrypts communication, but on its own it can’t fully prevent a relay in which “a client is made to authenticate, and that authentication is relayed on to a separate TLS connection controlled by the attacker”. The channel binding token (CBT) ties the authentication itself to that TLS channel, making a relay to a different channel detectable.

To be precise about the target: this is a connection performing Windows authentication (NTLM, Kerberos, or similar, via a SASL bind) over LDAPS. Simple binds have no CBT to begin with, so they fall outside this validation. What protects a simple bind over LDAPS is the TLS encryption and credential handling themselves — even with the setting at Always, a client using a simple bind will never show up in the CBT audit events.

Control is via a registry value on the domain controller, or the corresponding Group Policy setting.⁴

The events used for auditing are as follows (this expands on the channel-binding side of the Section 5.1 quick reference). Channel-binding events were added by the update of 10 March 2020, and the auditing events were further expanded by updates from 2023 onward.⁴

The approach is the same as for LDAP signing, and Microsoft’s own guidance is the same shape: “watch event 2889 for signing failures, 3039 for channel binding failures, and the auditing events 3074/3075, on the Directory Service log of every domain controller; identify the problem devices; confirm with their vendors; verify a fix; and only then enforce.”⁴

One thing worth emphasising: Microsoft has not changed the default for these updates. It is stated explicitly that the update of 10 March 2020 and the updates that followed it do not change the default policy for LDAP signing or LDAP channel binding.⁴ In contrast to SMB signing (whose default changed with 24H2), LDAP stays loose for as long as the administrator leaves it that way. Put positively, this means you can plan the timing of enforcement yourself, while you still have the choice.

7. How to Fix Business Applications and Devices (Decision Table)

Here’s how to sort the sources your audit turns up by cause.

If you’re working on an in-house .NET application that touches LDAP, the first thing to suspect is whether it’s sending a simple bind over plaintext.

// Bad: simple bind over 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));

// Good, option 1: require Negotiate with signing and sealing
// (Kerberos is selected once 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 running account

// Good, option 2: if you must 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));

Option 1’s Negotiate prefers Kerberos, but does not force it. If the destination is an IP address, or an SPN is unregistered or duplicated, it silently falls back to NTLM (even then, the request for signing and sealing itself still applies). The reliable way to confirm whether Kerberos authentication is happening is to check with klist that a ticket for the relevant service has actually been obtained. If you’ve enabled the NTLM audit from the first article (auditing all outgoing NTLM traffic), the absence of event 8001 is corroborating evidence — but note that “8001 isn’t appearing” means nothing if that audit policy was never enabled in the first place. Option 2’s simple bind is encrypted by TLS, but as noted in Chapter 6, it’s the Windows-authentication side that CBT validation applies to. Where you have a choice in a domain environment, treat option 1 as the default. If you’re going through DirectoryEntry (ADSI), the reliable approach is to explicitly set AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing. The principle from the first article in the NTLM series — write destinations as an FQDN rather than an IP address — matters here too, as the prerequisite for getting a SASL bind to succeed over Kerberos.

8. Summary

• SMB signing and LDAP signing/channel binding defend against relay attacks while you work through killing off NTLM dependency, and they are also a permanent hardening measure worth keeping even after NTLM is gone (both the tamper detection in signing and channel binding also protect sessions authenticated with Kerberos). Pursue them together with NTLM reduction, as two sides of the same effort.¹⁵
• SMB signing’s default has already changed. Windows 11 24H2 (Enterprise/Pro/Education) requires it both ways; Windows Server 2025 requires it outgoing. Your OS update plan sets the deadline.²
• The failure patterns are predictable: 0xc000a000 on devices that don’t support signing, and the guest-access block. The auditing available from 24H2 onward lets you find these ahead of time.²¹
• For LDAP, identify sources with events 2887/2889 (signing) and 3039/3040/3074/3075 (channel binding); fix them, then enforce.³⁴
• LDAP’s defaults don’t change with updates. They stay loose until an administrator tightens them. Move forward with a plan while you still have the choice.⁴
• For in-house applications, clearing out “plaintext simple binds” and “hard-coded IP addresses” resolves the vast majority of cases.

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 the business-application changes that come with enforcing SMB signing and LDAP signing, and investigation of connection failures around authentication and file sharing.

• Windows Application Development
• Bug Investigation & Root-Cause Analysis
• Legacy Asset Reuse & Migration Support
• Contact Us

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 make SMB signing mandatory, won't the file server slow down?

The computational cost of signing is not zero, but the algorithm has improved with every generation. Where SMB1 used MD5, SMB 2.02 moved to HMAC-SHA-256 and SMB 3.0 to AES-CMAC, and Windows Server 2022 and Windows 11 added signing acceleration using AES-128-GMAC. Domain controllers have also long required SMB signing from everyone 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 on performance grounds, we recommend making signing mandatory on a pilot machine first and measuring the actual effect. Any perceptible difference tends to be confined to specific usage patterns, such as continuous transfer of large files.

After upgrading to Windows 11 24H2, our NAS stopped connecting. Is SMB signing the cause?

Typically, yes. In Windows 11 version 24H2 Enterprise, Pro, and Education, SMB signing became mandatory by default for both outgoing and incoming connections, so connecting to a third-party NAS that doesn't support signing (or has it disabled) fails with 0xc000a000 (STATUS_INVALID_SIGNATURE). Because making signing mandatory also disables guest access, a NAS configured to allow unauthenticated use produces the error "You can't access this shared folder because your organization's security policies block unauthenticated guest access." The first fix is to enable SMB signing on the NAS itself and connect with credentials rather than as a guest. There is a client-side workaround that disables the signing requirement, but that only resolves the signing-error side of things. The block on guest connections comes from a separate client setting (disallowing insecure guest logons), not from signing, and stays in force unless that setting is also relaxed. Microsoft recommends neither disabling signing nor operating over guest accounts.

What's 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 communication. LDAPS encrypts the entire connection with SSL/TLS. LDAP channel binding is a further layer of defence on top of LDAPS: it ties authentication to the TLS channel, which prevents attacks that relay only the credentials to a separate TLS connection. To protect a domain controller, think of it as three measures taken together: stop plaintext simple binds, require signing on SASL binds, and require validation of the channel binding token for Windows authentication (SASL binds) carried over LDAPS. Note that simple binds have no CBT and so fall outside the scope of channel binding validation — what protects a simple bind over LDAPS is the TLS encryption itself.

In what order should we tighten these?

The order — audit, then fix, then enforce — is the same as it was for restricting NTLM. Start with SMB: enable the auditing available from Windows 11 24H2 onward that detects peers that don't support signing, and use it to identify which devices can't sign. For LDAP, check event 2887 (the daily count of unsigned binds) in the domain controller's Directory Service log; if the count isn't zero, set the "16 LDAP Interface Events" diagnostics setting to 2 and use event 2889 to identify the clients. For channel binding, do the same with events 3039/3040, plus the auditing events 3074/3075 added by updates from 2023 onward. Once every problematic source has been fixed, switch over: make SMB signing mandatory, make LDAP signing mandatory, and set 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.