SMB 签名与 LDAP 通道绑定——在实务中收紧 NTLM 对策的“另一半”

“NTLM 的审计已经开始，直接写 IP 地址的连接也在改。那么，在把依赖全部消除之前，中继攻击要怎么防？”

这段期间的防御手段，就是 SMB 签名，以及 LDAP 签名和 LDAP 通道绑定。它们不是停用 NTLM 本身的设置，而是在各个连接目标上阻止“把认证中继到另一条连接”的攻击。它们与削减 NTLM 并行推进，并且在废除 NTLM 之后仍然保留，属于长期的加固措施。¹²

推进方式是共通的：先审计 → 再修复连接来源的应用和设备 → 最后强制。不过，SMB 和 LDAP 要检查的设置不同，要读的事件也不同。本文先把三者的职责区分开，之后再分别说明各自的检查、修复和部署步骤。

这是 NTLM 系列的第 3 篇。NTLM 的审计步骤请参见“NTLM 停用会导致业务应用停止运行吗”，认证协议的机制请参见“图解 NTLM 与 Kerberos”。

1. 先说结论：三种防御按连接目标分工

LDAP 签名是完整性验证，LDAPS 是整条连接的 TLS 加密，通道绑定是把认证与 TLS 通道绑在一起。“已经改用 LDAPS”和“正在验证 CBT”不是一个意思。另外，简单绑定不携带 CBT，不在通道绑定验证的范围内。详细内容分别放在第 5 章和第 6 章说明。³⁴

在 SMB 方面，Windows 11 24H2 的 Enterprise、Pro、Education 在收发两个方向上默认要求签名，Windows Server 2025 则在发送侧默认要求签名。Home 不在这次变更的范围内，所以不能只看操作系统版本，还要确认版本类型。⁵

另一方面，本文引用的 KB4520412 所涉及的一系列 LDAP 更新，并不改变签名和通道绑定的默认策略。必须把“装了更新”和“配置了强制”区分开。不要把这份更新的说明泛化成所有操作系统和部署条件下的默认值，请确认目标环境自身的配置。⁴

图中实线表示始终成立的关系，虚线表示带条件的关系（成立条件写在详情页各关系的说明中）。关系的完整列表（共 28 条，附依据与确信度）以及主要概念的定义，汇总在知识地图详情页（日文）。数据：JSON-LD / Turtle

2. 为什么需要签名：与削减 NTLM 并行防守

2.1. 即使能中继认证，也伪造不出正确的签名

NTLM 的根本弱点是没有相互认证。客户端无法验证服务器的身份，于是攻击者可以冒充真正的服务器让客户端完成认证，再把认证响应中继给真正的服务器。这就是中继攻击。微软也说明了 NTLM 和 NTLMv2 认证在 SMB 中继和中间人攻击面前的脆弱性。²

彻底停用 NTLM，这种 NTLM 中继就不再成立。不过，第 1 篇文章所讲的依赖排查和修复，通常要花几个月。在这期间保护连接目标的，正是签名。

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

    CL -->|"① 认证响应"| AT
    AT -->|"② 原样中继"| SV
    SV -.->|"③ 若要求必须签名<br/>没有会话密钥的攻击者<br/>造不出正确的签名而失败"| AT

图1：只是中继了认证响应的攻击者，做不出用会话密钥计算的正确签名

作为认证的结果，持有签名所用会话密钥的是客户端和真正的服务器。只是中继了认证响应的攻击者没有这把密钥，在要求签名的连接上无法伪造后续消息。分工是这样的：针对 SMB 的中继由 SMB 签名挡住，针对域控制器 LDAP/LDAPS 的中继由 LDAP 签名和通道绑定挡住。

2.2. 即使把签名设为必须，也要继续迁移到 Kerberos

要提高签名的效果，还要检查认证方式。会话密钥来自密码，因此推荐使用 Kerberos 而不是 NTLMv2，从更强的密钥开始。微软还提到，连接共享时不要使用 IP 地址或 CNAME。¹

这是因为，用 IP 地址或者没有登记对应 SPN 的别名连接时，使用的不是 Kerberos 而是 NTLM。要继续使用别名时如何登记 SPN，第 1 篇文章中有说明。

削减 NTLM 依赖和把签名设为必须，是同时推进的两项措施。签名带来的篡改检测和通道绑定对 Kerberos 认证的会话同样有效，所以它们不是废除 NTLM 之后就该撤掉的设置。¹

3. SMB 签名：确认机制与默认值

3.1. 把“支持”和“设为必须”分开看

SMB 签名用会话密钥和加密套件给每条消息附加签名。SMB 标头中的签名包含整条消息的哈希以及发送方和接收方的身份，中途被篡改就会对不上。这就构成篡改检测，也就成了针对冒充和中继的防御。¹

看设置时的关键不是单纯的启用或禁用，而是有没有把签名设为必须（Require）。SMB 2.x 之后 EnableSecuritySignature 会被忽略，真正有意义的是 RequireSecuritySignature。只要客户端或服务器有任何一方设为必须，这条连接就需要签名。只有双方都没有设为必须时才不签名。¹

签名的计算是有成本的，但算法从 SMB1 的 MD5 演进到 SMB 2.02 的 HMAC-SHA-256、SMB 3.0 的 AES-CMAC，Windows Server 2022 和 Windows 11 又引入了基于 AES-128-GMAC 的加速。不要只凭“签名很慢”这种过去的印象就搁置，应该在试点终端上实测之后再判断。¹

3.2. 确认操作系统、版本类型以及发送与接收的方向

首先在“设置 > 系统 > 系统信息”中确认操作系统的版本类型和版本号。下表中的发送指这台电脑作为 SMB 客户端发起连接的一侧，接收指它作为 SMB 服务器接受连接的一侧。请找到本单位终端和服务器对应的那一行。

上面三行是微软明确写出的默认值。⁵ 最后一行的域控制器属于一直存在的另一套条件，它要求连接 SYSVOL 和 NETLOGON 的对端进行 SMB 签名。组策略和登录脚本的分发，一直以来就是以签名为前提运行的。¹

即使是 Windows 11 24H2，Home 在收发两个方向上都不要求签名，不在这次默认值变更的范围内。“只要升级到 Home 就会要求签名”的说法并不成立。这张表也不保证今后的变更和个别配置，因此遇到连接故障时，先确认版本类型，再确认 4.1 节讲的实际设置值。⁵

在 Enterprise、Pro、Education 上，升级到 24H2 之后，这台电脑发起的 SMB 连接默认就要求签名。Windows 自身是支持签名的，所以要优先排查的对端是不支持签名或禁用了签名的第三方设备。请检查老旧 NAS、多功能一体机扫描保存相关的设置、嵌入式 Linux 上的 Samba 等。

4. SMB 签名：审计、修复设备，再设为必须

4.1. 确认当前的签名要求以及管理用的策略

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

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

True 表示必须，False 表示非必须。检查时要把发送侧和接收侧分开做。⁵

组策略中的管理位置是 计算机配置\Windows 设置\安全设置\本地策略\安全选项。下面两项要分开使用。¹

策略名中的“始终（always）”就是“必须”的意思。如果还没有摸清不支持签名的设备，这一步不要一次性强制，先进入下一步的审计。

4.2. 用审计把无法签名的对端排查出来

在 Windows 11 24H2 及以后版本上，可以使用发现不支持签名或加密的第三方客户端和服务器的审计功能。下面是针对签名启用该功能的命令。¹

# 服务器侧：发现不支持签名的客户端
Set-SmbServerConfiguration -AuditClientDoesNotSupportSigning $true

# 客户端侧：发现不支持签名的服务器
Set-SmbClientConfiguration -AuditServerDoesNotSupportSigning $true

服务器侧查的是连进来的客户端，客户端侧查的是连出去的服务器。在组策略中，计算机配置\管理模板\网络 下的 Lanman Server / Lanman Workstation 里的“Audit client does not support signing”等项与之对应。¹

同一套审计功能里还有查加密不支持情况的 -AuditClientDoesNotSupportEncryption 和 -AuditServerDoesNotSupportEncryption。不过这是为将来把 SMB 加密设为必须做准备的。有些设备支持签名却不支持加密，因此判断签名必须化是否完成时，不要把加密的审计结果混进来。¹

签名和加密的审计所用的日志与事件 ID 如下。还要读事件正文，确认是不是本次要查的签名问题。¹

在事件查看器中按以下步骤查看。

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

这个示例会把签名和加密的审计 ID 一起取回来。不要把显示出来的全部数量都当作“不支持签名的数量”，请用 Message 把签名和加密分开。

刚启用审计之后等情况下，如果没有对应的事件，Get-WinEvent 会返回“未找到匹配项”的错误。示例中的 -ErrorAction SilentlyContinue 就是用来抑制它的。筛选条件的写法也可以参考“用 Get-WinEvent 实务排查事件日志”。

审计周期和 NTLM 审计一样，要取到业务走完一个完整周期为止。不能只凭刚启用后那一段日志，就认为已经确认了全部连接目标。

4.3. 把签名错误和来宾阻止分开修

从要求签名的环境连接无法签名的对端时，会出现下面的错误。⁵

0xc000a000
STATUS_INVALID_SIGNATURE
加密签名无效。

另一种是来宾访问被拒。要求签名的连接上无法使用来宾访问，因此在不需要认证就能使用的 NAS 等设备上，会出现下面这样的错误。⁵

你不能访问此共享文件夹，因为你组织的安全策略
阻止未经身份验证的来宾访问。

首要的处理办法是在设备一侧启用 SMB 签名，并改用凭据而不是来宾身份连接。必要时可以考虑固件更新或改变连接路径。

在客户端执行 Set-SmbClientConfiguration -RequireSecuritySignature $false 这种规避手段，缓解的是签名错误这一半。来宾阻止还受“禁止不安全的来宾登录”这项另外的客户端设置控制，因此只是去掉签名要求，来宾连接被拒的问题不会消失。

微软既不推荐为了迁就第三方设备而禁用签名，也不推荐用来宾账户去做签名。⁵ 即便确实需要缓解，也不要把它变成常态运维，而应作为设备更换之前的限期例外来管理。

4.4. 从试点推进到全面部署

24H2 之后涉及的版本类型越多，客户端侧默认要求签名的比例就越高。实质上的截止时间由操作系统更新计划决定，所以请把这项审计和设备修复纳入迁移到 Windows 11 的前置工作。从 Windows 10 迁移的方针，在“Windows 10 停止支持后的现实解决方案”中有讨论。

5. LDAP 签名：先确认绑定方式再强制

SMB 之后是到域控制器和 AD LDS 的 LDAP 连接。未签名的 LDAP 流量在重放攻击和中间人攻击面前很脆弱，服务器有可能基于被窃听和篡改过的请求做出判断。³

首先要区分认证所用的“绑定”类型。

把 LDAP 签名设为必须之后，会拒绝不要求签名的 SASL 绑定和明文（非 SSL/TLS）连接上的简单绑定。签名是与加密不同的完整性验证。简单绑定没有签名框架，所以要继续使用简单绑定，就只能改到 LDAPS 上。³

5.1. 读事件时把“数量”和“连接来源”分开

LDAP 签名和下一章的通道绑定，都使用域控制器的 Directory Service 日志。在事件查看器中打开应用程序和服务日志 > Directory Service。

用法上的区别是：看剩余数量的汇总事件（2887、3040），和查连接来源的单条事件（2889、3039、3074、3075）。只要还有问题连接，就不要推进到强制，先去修复。

表中的“无需手动启用即可使用”，说的是那次更新之后可以使用该审计功能。不要把它理解成任何配置下都一定会产生相应事件，请对照 KB4520412 确认操作系统、已安装的更新和诊断设置。简单绑定不在 CBT 验证范围内这一点，也放在第 6 章分辨。⁴

5.2. 用 2887 看剩余数量，用 2889 定位连接来源

LDAP 签名使用的是 2886、2887、2888、2889。2886 是促使配置的提醒，2887 是每 24 小时的问题绑定汇总，2888 是配置为拒绝之后的汇总。只有用来了解连接来源的 2889 默认不会出现。³

先用 2887 确认是否还有未签名绑定。如果有数量，就把诊断设置“16 LDAP Interface Events”改为 2（Basic） 来记录 2889，查出连接来源 IP 地址和认证所用的 ID。³

2889 不是汇总，而是逐条绑定的记录。在高频连接仍然存在的环境里，它会迅速塞满 Directory Service 日志，因此定位到连接来源之后要把诊断设置改回原来的级别（默认是 0）。如果要持续记录，请先准备好日志转发和保留容量。

要排查的对端包括业务系统的 AD 认证和人事数据对接、多功能一体机的 LDAP 地址簿查询、网络设备的 LDAP 认证等。设备类尤其经常配置成明文的简单绑定，所以要检查它们的 LDAP 设置。修复方式是切换到 LDAPS（636 端口）或带签名的 SASL 绑定。具体例子汇总在第 7 章。

5.3. 修复之后要求签名，并验证拒绝行为

修复连接来源之后，用组策略做下面的配置。³

确认配置可以使用 ldp.exe。不使用 TLS 连接 389 端口并尝试简单绑定，如果出现下面的错误，说明拒绝的配置已经生效。这是对拒绝行为的验证，不是在业务中使用明文绑定的步骤。请用验证专用的凭据来做。³

Ldap_simple_bind_s() failed: Strong Authentication Required

6. LDAP 通道绑定：LDAPS 上的认证也要确认

6.1. TLS 加密和把认证绑定到通道是两回事

LDAPS 用 TLS 加密通信。但是，对于“让客户端完成认证，再把这次认证中继到攻击者自己另一条 TLS 连接上”这种形式的中继，光有加密是不够的。通道绑定令牌（CBT）就是把认证绑定到这条 TLS 通道本身、从而能够发现中继到其他通道的值。⁴

它的适用范围是在 LDAPS 之上进行 NTLM、Kerberos 等 Windows 认证（SASL 绑定）的连接。简单绑定不携带 CBT，不在这项验证的范围内。保护 LDAPS 之上简单绑定的是 TLS 加密和凭据管理，即使把设置改成 Always，使用简单绑定的客户端也不会出现在 CBT 的审计事件里。

6.2. 把设置值 0、1、2 与策略对应起来

通过域控制器的注册表或对应的组策略来控制。⁴

When supported 和 Always 不是一回事。要把“验证支持该功能的客户端”这一步和“对适用连接始终要求验证”这一步分开，确认支持情况之后再推进到 Always。

6.3. 用 3039、3040、3074、3075 查连接来源

把 5.1 节速查表中通道绑定一侧事件的含义展开来看，就是下面这样。2020 年 3 月 10 日的更新加入了相关事件，2023 年之后的更新又扩充了审计。⁴

微软的部署步骤也是这个顺序：在全部域控制器的 Directory Service 日志中监视 2889、3039、3074、3075，定位有问题的设备并向供应商确认，处理完之后再开启强制。⁴

不要只因为已经在用 LDAPS 就认为完成了，还要看认证方式和 CBT 的支持情况。从 6.1 节的区分也能看出，不该只靠 CBT 事件去找不在验证范围内的简单绑定。

6.4. 不要只因为装了更新就认定已经强制

KB4520412 说明，2020 年 3 月 10 日的更新以及该文档涉及的一系列更新，不会改变 LDAP 签名和通道绑定的默认策略。⁴

因此，在只装了更新而未开启强制的环境里，管理员仍然有配置工作要做。不要把它和 SMB 在 24H2 上的默认值变更混为一谈，请把“能用审计功能”和“已经强制防御”分开确认。趁还能自己选择强制时机的时候，把连接来源的修复计划好并推进下去。

7. 按原因分别修复业务应用和设备

7.1. 把事件中出现的对端与修复方法对应起来

不支持签名、来宾使用方式、明文简单绑定、不支持 CBT，这四类要修的地方各不相同。即使表面上同样是“连不上”，也不要一律放宽设置，而要根据事件和连接方式选择处理办法。

7.2. .NET 应用要检查认证方式和 TLS 配置

在自研的 .NET 应用中，首先要查的是有没有把 AuthType.Basic 的简单绑定发往明文的 389 端口。下面是强制 LDAP 签名之后会被拒绝的反面例子。它不是用来拿真实凭据去执行的示例。

// 反面例子：发往明文 389 端口的简单绑定。强制 LDAP 签名后会被拒绝
var conn = new LdapConnection("dc01.corp.example.com");
conn.AuthType = AuthType.Basic;
conn.Bind(new NetworkCredential(user, password));

修复时，如果在域环境中可以选择，就以使用 Negotiate 并要求签名和加密为基本做法。确实需要简单绑定时，就使用 LDAPS。下面两个例子是用来对比这两种选项的摘录，不是要接在上面的反面例子后面连续执行的。

// 正面例子 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 审计设为了“审计所有”，那么没有出现事件 8001 也可以作为旁证。不过，在审计策略仍然关闭的情况下判断“没有 8001”是没有意义的。

正面例子 2 的简单绑定虽然被 TLS 加密，却不在 CBT 验证的范围内。重要的是不要把它当作和正面例子 1 同等的防御。使用 DirectoryEntry（ADSI）时，要显式指定 AuthenticationTypes.Secure | AuthenticationTypes.Signing | AuthenticationTypes.Sealing。

连接目标写 FQDN 而不是 IP 地址，这条原则对 Kerberos 的 SASL 绑定同样适用。请连同名称解析和 SPN 一起修好，不要只改了代码里的认证方式就算完。

8. 总结：按路径分别走完审计、修复、强制

SMB 签名、LDAP 签名和 LDAP 通道绑定，不是停用 NTLM 的替代品。它们是在削减 NTLM 依赖期间也能挡住中继的防御，并且是迁移到 Kerberos 之后仍然保留的长期加固措施。¹²

在 SMB 方面，要确认操作系统、版本类型以及收发两个方向的默认值，先修好不支持签名的设备和来宾使用方式。升级到 Windows 11 24H2 相关版本类型的计划，就是准备工作的截止时间。在 LDAP 方面，用 2887、2889 查未签名绑定，用 3039、3040、3074、3075 查通道绑定相关问题，修复连接来源之后再开启强制。⁵³⁴

安装更新、启用审计功能、强制防御，是三个不同的阶段。尤其不要因为装了 KB4520412 的 LDAP 更新，就判断强制已经完成。也要把简单绑定不在 CBT 验证范围内这一点考虑进去再确认。⁴

在自研应用中，先消除明文的简单绑定和直接写死的 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 软件开发、技术咨询与故障排查为中心，擅长难以复现的故障调查，以及既有资产仍在运行的项目。