SMB 签名与 LDAP 通道绑定 ── 用实务收紧 NTLM 对策的「另一半」

「已经开始对 NTLM 进行审核了，直接写死 IP 地址的地方也在修正。那么，在把所有依赖全部消除干净之前，该如何应对中继攻击？」──在发布上一篇文章「NTLM 停用会导致业务应用停止运行吗」之后，这是收到最多的问题。

答案就是本文要探讨的SMB 签名与LDAP 签名・LDAP 通道绑定。这两者都不是「停用 NTLM」的对策，而是「即便 NTLM 仍然存在的期间，也不让盗用认证信息进行中继的攻击（中继攻击）得逞」的防御手段。其中一方的 SMB 签名，在 Windows 11 24H2 / Windows Server 2025 上默认值已经实际发生了变化，即使我们什么都不做，它也会随着操作系统更新一同到来。另一方的 LDAP 签名・通道绑定，默认值本身并未改变，只要管理员不去收紧，它就会一直保持宽松状态。也就是说，SMB 面临的是「提前应对，还是等 OS 更新引发事故后再处理」的问题，而 LDAP 面临的则是「自己何时去收紧」的问题。

本文是 NTLM 系列的第 3 篇。NTLM 的审核步骤整理在第 1 篇中，协议的机制整理在第 2 篇中。

1. 先说结论

• SMB 签名是为 SMB 的所有消息附加篡改检测签名的机制。签名中包含消息整体的哈希值以及发送方・接收方的身份信息，可以防御中继攻击与冒充攻击。¹
• 默认值已经发生了变化。Windows 11 版本 24H2 的 Enterprise・Pro・Education 默认发送与接收两端都要求签名，Windows Server 2025 默认仅发送端要求签名（Home 版两端都不要求）。²
• 签名的必须化与来宾访问的禁用是配套的。不支持签名的 NAS，以及以来宾连接为前提的设备，会在操作系统更新时出现连接错误。错误代码是 0xc000a000（STATUS_INVALID_SIGNATURE）或来宾被阻止的提示信息（4.3 节）。²
• LDAP 签名是让域控制器能够拒绝「不要求签名的 SASL 绑定」与「明文的简单绑定」的机制。这是因为未签名的 LDAP 流量容易受到重放攻击・中间人攻击的影响。³
• LDAP 通道绑定是把 LDAPS（SSL/TLS）之上的 Windows 认证（SASL 绑定）与 TLS 通道绑定在一起的机制。用于这种绑定的值称为通道绑定令牌（CBT）。不具备 CBT 的简单绑定不在验证对象之列（第 6 章）。通过注册表值 LdapEnforceChannelBinding（0/1/2）或组策略进行控制。⁴
• 两者都按照「解读审核事件→修复连接来源→切换为强制」这三个阶段推进。LDAP 签名可以通过事件 2887・2889，通道绑定可以通过事件 3039・3040 以及审核事件 3074・3075 来确定连接来源（第 5 章・第 6 章）。³⁴
• 一个重要的前提是，这些更新并不会擅自改变默认值。微软已经明确表示，2020 年 3 月以来的一系列 LDAP 更新「不会改变 LDAP 签名・通道绑定的默认策略」。收紧策略是管理员的工作。⁴

2. 为什么是签名 ── 中继攻击的「另一半」

正如第 2 篇文章中所写的那样，NTLM 的根本弱点在于没有相互认证。由于客户端无法验证服务器的身份，攻击者可以「冒充真正的服务器」让客户端进行认证，然后把收到的认证响应原封不动地转发给真正的服务器。这就是中继攻击，微软自身也明确指出 NTLM 及 NTLMv2 认证对 SMB 中继・中间人攻击是脆弱的。⁵

如果完全停用 NTLM，这种攻击就不再成立，但正如第 1 篇文章中所看到的那样，梳理和修复依赖需要花费数月量级的时间。在此期间的防御手段就是签名。

flowchart LR
    CL["客户端"]
    AT["攻击者<br/>伪造的服务器"]
    SV["真正的服务器"]

    CL -->|"① 认证响应"| AT
    AT -->|"② 原样中继"| SV
    SV -.->|"③ 若签名为必须:<br/>不掌握会话密钥的攻击者<br/>无法生成正确的签名，导致失败"| AT

图 1：中继攻击与 SMB 签名的关系

要点在于，签名所用的密钥（会话密钥）作为认证的结果，只有客户端和真正的服务器才拥有。仅仅中继了认证响应的攻击者并不掌握会话密钥，因此在要求签名的环境中，之后的消息无法被伪造。SMB 签名堵住了对 SMB 的中继，LDAP 签名与通道绑定则分别堵住了对域控制器 LDAP/LDAPS 的中继。

还有一点实务上需要注意。签名的效果并非与认证协议的选择无关。由于会话密钥来源于密码，如果用 NTLMv2 而不是 Kerberos 进行认证，作为签名基础的密钥就会变弱。微软也把使用 Kerberos、不通过 IP 地址或 CNAME 连接共享，列为让 SMB 签名效果最大化的条件。¹ 这是因为如果用 IP 地址，或者用没有注册对应 SPN 的别名进行连接，就会使用 NTLM 而不是 Kerberos（如果想继续使用别名，注册 SPN 的方法在第 1 篇文章中有说明）。也就是说，削减 NTLM 依赖与签名的必须化，并不是两项独立的对策，而是同一项对策的两个车轮。

3. SMB 签名 ── 机制，以及已经改变的默认值

3.1. 一分钟了解机制

SMB 签名利用会话密钥和加密套件，为流经连接的每条消息附加签名。签名中在 SMB 标头内包含了消息整体的哈希值，一旦中途遭到篡改，哈希值就会不一致。由于哈希值中还包含发送方和接收方的身份信息，因此也能检测出冒充行为。¹

算法在每一代都得到了强化。SMB1 使用的是 MD5，到了 SMB 2.02 变为 HMAC-SHA-256，SMB 3.0 变为 AES-CMAC，Windows Server 2022 和 Windows 11 还引入了基于 AES-128-GMAC 的签名加速。¹ 如果「签名 = 变慢」这种印象还停留在 SMB1 时代，那么值得先把它放下，重新实测一次。

对于设置，不应以「启用/禁用」来考虑，而应以「是否必须（Require）」来考虑。在 SMB 2.x 及以后的版本中，EnableSecuritySignature 设置会被忽略，真正起作用的只有 RequireSecuritySignature。而且只要客户端和服务器中有一方设为必须，该连接就会被签名。只有在双方都未设为必须时，才不会进行签名。¹

3.2. 默认值判断表

这张表并不需要全部读完。请先确认本公司终端与服务器的操作系统及版本，只阅读自己对应的那一行即可。版本（Edition）与版本号可以在「设置 > 系统 > 关于」中确认（「版本」对应 Pro/Home/Enterprise/Education 等，「版本号」对应 24H2 等显示）。

上面三行是微软文档中明确写明的默认值。² 最下面一行则是一直以来的行为：域控制器会对所有前来连接的对象要求 SMB 签名。组策略和登录脚本的分发，一直都是以签名为前提运行的。¹

只有 Home 版本不在此次默认值变更的范围之内。由于发送和接收都不会被设为必须，即使更新到 24H2，Home 终端也不会因签名必须而出现连接错误（这并不保证未来不会变化，但至少在 24H2 这个时间点上的「截止期限」中不包含 Home 版）。² 反过来说，即使同样是 24H2，行为也会因版本而不同。在排查「更新之后连不上共享」这类反馈时，不要只看版本号，请优先确认版本（Edition）。

这张表在实务上的意义是这样的。更新到 Windows 11 24H2（Enterprise・Pro・Education）后，该 PC 发出的所有 SMB 连接都会变为要求签名（Home 版不在此列）。如果公司内部的文件服务器是 Windows，就不会出现任何问题（因为 Windows 在所有版本上都支持签名）。会出问题的，是与不支持签名或已禁用签名的第三方设备打交道的时候，也就是旧款 NAS、复合机的扫描保存目标设置、内嵌 Linux 的 Samba 等对象。

4. 把 SMB 签名推进到「必须」的步骤

4.1. 确认现状

# 客户端（发送）的签名要求
Get-SmbClientConfiguration | FL RequireSecuritySignature

# 服务器端（接收）的签名要求
Get-SmbServerConfiguration | FL RequireSecuritySignature

True 表示必须，False 表示非必须。² 如果用组策略进行管理，位置在 计算机配置\Windows 设置\安全设置\本地策略\安全选项 下的「Microsoft 网络客户端: 始终对通信进行数字签名」（客户端）与「Microsoft 网络服务器: 始终对通信进行数字签名」（服务器）。策略名称中的「始终（always）」即代表「必须」。¹

4.2. 先筛查出「无法签名的对象」（审核）

在 Windows 11 版本 24H2 及以后版本中，可以启用用于检测不支持签名或加密的第三方客户端・服务器的审核。¹

# 服务器端: 检测不支持签名的客户端
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# 客户端: 检测不支持签名的服务器
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

同样的机制中也存在用于检测不支持加密的对象的审核（-AuditClientDoesNotSupportEncryption / -AuditServerDoesNotSupportEncryption），¹ 但那是为将来把 SMB 加密设为必须做准备，与签名的路线图是不同的轨道。支持签名但不支持加密的设备并不罕见，因此请不要把加密的审核事件混入签名完成与否的判断中。

记录位置如下。¹

确认事件的步骤有以下 3 个。

1. 通过 eventvwr.msc 打开事件查看器，在左侧树状目录中打开 事件查看器 > 应用程序和服务日志 > Microsoft > Windows > SMBClient > Audit（查看服务器端时，则打开同一层级下的 SMBServer > Audit）。
2. 在右侧窗格中选择「筛选当前日志」，在「所有事件 ID」栏中输入 31998,31999（服务器端为 3021,3022）。
3. 打开筛选后剩下的事件，其中记录着不支持签名的对象信息。把这些信息逐一整理到设备清单中。

如果要用 PowerShell 批量获取，方法如下。

# 客户端: 检测到不支持签名的服务器的审核事件
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBClient/Audit'; Id=31998,31999 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

# 服务器端: 检测到不支持签名的客户端的审核事件
Get-WinEvent -FilterHashtable @{ LogName='Microsoft-Windows-SMBServer/Audit'; Id=3021,3022 } -ErrorAction SilentlyContinue |
    Select-Object TimeCreated, Id, Message

刚启用审核、还没有任何记录的情况下，Get-WinEvent 会返回「无匹配事件」的错误（上面之所以加上 -ErrorAction SilentlyContinue，正是为了这个原因）。筛选条件的写法整理在「用 Get-WinEvent 实务排查事件日志」一文中。

在组策略中，对应的是 计算机配置\管理模板\网络 下 Lanman Server / Lanman Workstation 中的「Audit client does not support signing」等设置。¹ 第 1 篇文章中提到的审核周期的考虑方式（运行到业务走完一轮为止），在这里同样原样适用。

4.3. 提前了解事故的模式

在要求签名的环境中连接到无法签名的对象时，会出现以下错误。²

0xc000a000
STATUS_INVALID_SIGNATURE
加密签名无效。

还有一点容易被忽视，那就是来宾访问。签名的必须化还伴随着来宾访问的禁用。连接到设置为无需认证（来宾）即可访问的 NAS 时，会出现如下错误。²

由于组织的安全策略阻止了未经身份验证的来宾访问，
无法访问此共享文件夹。

应对的优先顺序很明确。首先应在设备一侧启用 SMB 签名，改用凭据而非来宾进行认证。虽然在客户端一侧执行 Set-SmbClientConfiguration -RequireSecuritySignature $false 可以规避签名错误（0xc000a000）这一侧的问题，但来宾被阻止是由与签名无关的另一项客户端设置（禁止不安全的来宾登录）造成的，仅仅放宽签名并不能解决这个问题。微软既不推荐把禁用签名作为应对第三方设备的规避方法，也不推荐试图在来宾账户上使用签名。² 如果要放宽限制，请将其作为「直到该设备更换为止、设有期限的例外」来处理。

4.4. 部署顺序

另外，随着 24H2 及以后版本的终端不断增多，「客户端默认要求签名」的比例也会随之上升，因此实质上的截止期限由操作系统更新计划来决定。正在因 Windows 10 支持终止而向 Windows 11 24H2 及以后版本迁移的组织，请把这项验证纳入迁移的前提工作之中（「Windows 10 支持终止后的现实解法」）。

5. LDAP 签名 ── 守护通往域控制器的路径

本章与下一章都以「绑定」的种类为讨论主线，因此先确认两个术语。

也就是说，「把 LDAP 签名设为必须」意味着对 SASL 绑定要求签名，并拒绝明文连接的简单绑定。

继 SMB 之后是 LDAP。发往域控制器（以及 AD LDS）的未签名 LDAP 流量，对重放攻击和中间人攻击是脆弱的。如果攻击者把截获・篡改后的数据包转发给服务器，服务器就有可能基于伪造的请求做出判断。³

强制 LDAP 签名，就是让目录服务器拒绝以下两种绑定。³

1. 不要求签名（完整性验证）的 SASL 绑定（SASL 包括 Negotiate、Kerberos、NTLM、Digest）
2. 在明文（非 SSL/TLS）连接上进行的简单绑定

5.1. 事件 ID 速查表（LDAP 签名・通道绑定共通）

先把本章与第 6 章中出现的事件 ID 汇总起来。这些事件全部记录在域控制器的「Directory Service」日志（事件查看器 > 应用程序和服务日志 > Directory Service）中。审核方案的设计可以直接从这张表着手。

区分使用方式很简单。用来查看「还剩多少件」的是汇总事件（2887・3040），用来查看「来自哪里」的是单条事件（2889・3039・3074・3075）。在件数没有归零之前，不推进到强制。接下来，5.2 节详细说明 LDAP 签名一侧，第 6 章详细说明通道绑定一侧。

5.2. 先做审核 ── 事件 2886/2887/2889

域控制器的 Directory Service 日志中，从一开始就已经给出了线索。5.1 节速查表中与 LDAP 签名相关的有 2886・2887・2888・2889 这 4 个，其中 2887 表示「未签名绑定还有多少件」，2889 表示「它们来自哪里」（2888 是配置拒绝之后的汇总）。³

只有 2889 默认不会出现。把诊断设置「16 LDAP Interface Events」调高到2（Basic）之后，才会开始记录。³ 步骤是：先用 2887 的汇总查看「未签名绑定到底有多少件」，如果不是零，就启用 2889 来确定连接来源。需要注意的是，2889 不是汇总，而是每次发生该绑定就记录一次，因此在遗留绑定高频残留的环境中，会一下子把 Directory Service 日志填满。确定完连接来源之后，请把诊断设置恢复到原来的级别（默认是 0）。如果打算一直开着不关，就要先确保日志的转发与保留。

连接来源的典型代表，是与 LDAP 联动的业务系统（认证联动、人事系统联动）、复合机的 LDAP 通讯录搜索、网络设备的 LDAP 认证。特别是复合机・设备类的「LDAP 服务器设置」大多是明文的简单绑定，请首先怀疑这一点。修复方法是把设备・应用一侧的设置切换为 LDAPS（636 端口）或已签名的 SASL 绑定。

5.3. 实施强制

把连接来源全部修复之后，就用组策略进行强制。³

• 域控制器一侧: 在 Default Domain Controller Policy 的 安全选项 中，把「域控制器: LDAP 服务器签名要求」设置为「需要签名」
• 客户端一侧: 把「网络安全: LDAP 客户端签名要求」设置为「需要签名」

可以用 ldp.exe 进行确认。连接到 389 端口并尝试简单绑定，如果出现以下错误，就说明配置已经生效。³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAP 通道绑定 ── LDAPS 一侧的防御

「我们用的是 LDAPS，所以没问题」── 而堵住这里残留漏洞的，正是通道绑定。LDAPS 会对通信进行加密，但仅凭这一点，无法完全防止「让客户端进行认证，再把该认证信息中继到攻击者自己的另一个 TLS 连接」这种形式的中继。通道绑定令牌（CBT）通过把认证与该 TLS 通道本身绑定在一起，使得向另一个通道的中继变得可以被检测出来。

准确地说，对象是在 LDAPS 之上进行 NTLM 或 Kerberos 等 Windows 认证（SASL 绑定）的连接。简单绑定本来就不具备 CBT，因此不在这项验证的对象范围内。保护 LDAPS 上简单绑定的，是 TLS 加密以及凭据管理本身，即使设置为 Always，使用简单绑定的客户端也不会出现在 CBT 的审核事件中。

控制方式是通过域控制器的注册表值，或与之对应的组策略进行。⁴

用于审核的事件如下（这是把 5.1 节速查表中通道绑定一侧的内容详细展开）。2020 年 3 月 10 日的更新中新增了与通道绑定相关的事件，之后 2023 年以后的更新又进一步扩充了审核事件。⁴

推进方式与 LDAP 签名相同，微软的指导意见同样是「在全部域控制器的 Directory Service 日志中，监控签名失败的 2889、通道绑定失败的 3039、审核事件 3074・3075，锁定有问题的设备并向提供方确认，确认对应方案后再进行强制」。⁴

有一点想特别强调，那就是微软并没有通过这些更新改变默认值。2020 年 3 月 10 日的更新以及当前为止的更新，都被明确说明不会改变 LDAP 签名・LDAP 通道绑定的默认策略。⁴ 与 24H2 中默认值发生了变化的 SMB 签名形成对照，LDAP 一侧只要管理员不自行收紧，就会一直保持宽松。反过来说，正因如此，才可以在自己还能选择收紧时机的阶段有计划地推进。

7. 业务应用与设备的修复方法（判断表）

把审核中发现的连接来源，按原因分类整理如下。

如果自主开发的 .NET 应用中涉及 LDAP 操作，首先应怀疑的是「是否在用明文发送简单绑定」。

// 不良示例: 向明文 389 端口进行简单绑定。强制 LDAP 签名后会被拒绝
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));

// 良好示例 1: 要求 Negotiate + 签名・加密（只要 SPN 与名称解析齐备，就会选用 Kerberos）
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Negotiate;
conn.SessionOptions.Signing = true;
conn.SessionOptions.Sealing = true;
conn.Bind();  // 用当前运行的账户进行认证

// 良好示例 2: 如果要使用简单绑定，必须改用 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));

良好示例 1 中的 Negotiate 会优先选择 Kerberos，但并不强制。如果连接目标是 IP 地址，或者 SPN 未注册・存在重复，就会悄悄回退到 NTLM（即便如此，签名・加密的要求本身依然有效）。要确认是否用 Kerberos 完成了认证，最可靠的方法是用 klist 确认已经获取了对应服务的票据。如果启用了第 1 篇文章中提到的 NTLM 审核（发送 NTLM 流量 = 全部审核）的环境，那么「没有出现事件 8001」也可以作为旁证。但要注意，如果审核策略本身处于禁用状态，「没有出现 8001」这件事本身就没有意义。另外，良好示例 2 中的简单绑定虽然会通过 TLS 加密，但正如第 6 章所述，CBT 验证的对象是 Windows 认证一侧。如果在域环境中可以选择，请以良好示例 1 为基本方案。如果通过 DirectoryEntry（ADSI）操作，明确指定 AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing 是最可靠的做法。NTLM 系列第 1 篇文章中写到的原则（连接目标不要用 IP 地址而要用 FQDN 书写），作为让基于 Kerberos 的 SASL 绑定得以成立的前提，在这里同样发挥着作用。

8. 总结

• SMB 签名与 LDAP 签名・通道绑定，是在彻底消除 NTLM 依赖之前不让中继攻击得逞的防御手段，同时也是在 NTLM 停用之后仍会保留下来的永久性强化对策（签名的篡改检测与通道绑定，对 Kerberos 认证的会话同样有效）。请将其作为与削减 NTLM 相同对策的两个车轮来推进。¹⁵
• SMB 签名的默认值已经发生了变化。Windows 11 24H2（Enterprise/Pro/Education）发送与接收两端都是必须，Windows Server 2025 是发送必须。操作系统更新计划本身就成了截止期限。²
• 事故的模式是固定的：不支持签名设备的 0xc000a000，以及来宾访问的阻断。可以通过 24H2 及以后的审核功能提前筛查出来。²¹
• LDAP 方面，通过事件 2887・2889（签名）以及 3039・3040・3074・3075（通道绑定）确定连接来源，修复之后再实施强制。³⁴
• LDAP 一侧的默认值不会随更新而改变。只要管理员不去收紧，它就会一直保持宽松。请趁还能有计划地推进时尽早行动。⁴
• 自主开发的应用，只要消除「明文简单绑定」和「直接写死 IP 地址」这两点，大部分问题就能解决。

相关文章

• NTLM 停用会导致业务应用停止运行吗 ── 审核日志的获取方法与消除依赖的顺序
• 图解 NTLM 与 Kerberos ── 为什么认证会「回退」到 NTLM
• 网络驱动器与 UNC 路径的陷阱 ── 业务应用中处理文件服务器（共享文件夹）的实务
• 用 Get-WinEvent 实务排查事件日志 ── 筛选速度决定调查时间
• Windows 10 停止支持后的现实解决方案 ── ESU・LTSC・更换设备的判断表
• Windows 应用程序开发安全性最低限度检查清单

相关咨询领域

合同会社小村软件承接因强制实施 SMB 签名・LDAP 签名而产生的业务应用改造，以及认证・文件共享相关连接故障的调查。

• Windows 应用开发
• 故障排查・原因分析
• 现有资产利用・迁移支持
• 联系我们

参考链接

相关文章

共享相同标签的最新文章。可以围绕相近的主题进一步加深理解。

相关主题

与本文相近的主题页面。以本文为起点，可以进一步了解相关服务和其他文章。

与本主题相关的服务

本文与以下服务页面相关联，欢迎从最接近的入口查看。

常见问题

汇总了咨询这一主题时常见的问题。

把 SMB 签名设为必须后，文件服务器会变慢吗？

签名的计算成本并非为零，但算法在每一代都得到了改进。相对于 SMB1 使用的 MD5，SMB 2.02 改为 HMAC-SHA-256，SMB 3.0 改为 AES-CMAC，Windows Server 2022 和 Windows 11 还引入了基于 AES-128-GMAC 的签名加速。此外，域控制器一直以来都要求所有连接到 SYSVOL 和 NETLOGON 的对象进行 SMB 签名，组策略的分发也一直是以签名为前提运行的。在以性能为由搁置之前，建议先在试点终端上设为必须并实测。能够切实感受到差异的情况，大多偏向大容量文件连续传输之类的特定使用方式。

升级到 Windows 11 24H2 之后连不上 NAS 了，是 SMB 签名的原因吗？

通常正是这个原因。Windows 11 版本 24H2 的 Enterprise・Pro・Education 版默认在发送和接收两端都将 SMB 签名设为必须，因此连接到不支持签名（或已禁用签名）的第三方 NAS 时，会以 0xc000a000（STATUS_INVALID_SIGNATURE）失败。此外，由于签名的必须化还伴随着来宾访问的禁用，对于设置为无需认证即可使用的 NAS，会出现「由于组织的安全策略阻止了未经身份验证的来宾访问」这样的错误。首要的应对方法，是在 NAS 一侧启用 SMB 签名，并改用凭据而非来宾进行连接。虽然也可以在客户端一侧禁用签名要求来作为规避方法，但这样只能解决签名错误这一侧的问题。来宾连接被阻止，是由与签名无关的另一项客户端设置（禁止不安全的来宾登录）造成的，只要不放宽那项设置，连接就会一直失败。微软既不推荐禁用签名，也不推荐以来宾方式运营。

LDAP 签名与 LDAPS（LDAP over SSL/TLS）有什么区别？

两者是不同的东西。LDAP 签名是要求在 389 端口的 LDAP 连接之上进行的 SASL 绑定（Negotiate、Kerberos、NTLM、Digest）附带完整性验证（签名）的机制，并不对通信本身进行加密。LDAPS 是用 SSL/TLS 对整个连接进行加密的机制。而 LDAP 通道绑定则是在 LDAPS 之上的进一步防御，通过把认证与 TLS 通道绑定在一起，来防止「只把认证信息中继到另一个 TLS 连接」的攻击。要保护域控制器，请按以下三件套来考虑：停止使用明文的简单绑定、对 SASL 绑定要求签名、对 LDAPS 之上的 Windows 认证（SASL 绑定）要求验证通道绑定令牌。另外，不具备 CBT 的简单绑定不在通道绑定验证的对象范围内，保护 LDAPS 上简单绑定的是 TLS 加密本身。

应该按照怎样的顺序来收紧？

审核→修正→强制的顺序，与限制 NTLM 时是一样的。首先在 SMB 方面，启用 Windows 11 24H2 及以后版本可用的、用于检测不支持签名对象的审核，筛查出无法签名的设备。LDAP 方面，在域控制器的 Directory Service 日志中确认事件 2887（每 24 小时的未签名绑定汇总），如果有件数出现，就把诊断设置「16 LDAP Interface Events」调为 2，通过事件 2889 确定客户端。通道绑定则用事件 3039・3040，以及 2023 年以后的更新中新增的审核事件 3074・3075，用同样的方式进行筛查。把所有有问题的连接来源全部修复之后，再依次切换为 SMB 签名必须、LDAP 签名必须、通道绑定设为 Always。唯一的原则是不要一开始就直接转向强制。

作者简介

本文作者的个人简介页面。

Go Komura

小村软件有限公司 代表

以 Windows 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。