NTLM 停用会导致业务应用停止运行吗 ── 审核日志的获取方法与消除依赖的顺序

「听说 NTLM 要停用了，我们公司没问题吧？」── 自从微软在 2024 年 6 月宣布将 NTLM 的所有版本标记为弃用（deprecated）以来，被问到这个问题的机会明显增多了。答案是：是否没问题，一查便知；而且现在去查，还来得及。

NTLM 的停用并不是「某天打了补丁全公司就停摆」那种变更，而是每次操作系统更新时都会逐步收紧的变更。而且唯有在 NTLM 目前仍在运行的当下，才能安全地把「本公司哪些地方依赖 NTLM」列成清单。先把一切都停掉，再去找哪里坏了 ── 这是最不应该采取的顺序。

本文将聚焦于制作并逐一消除这份清单的实务步骤。协议机制本身（为什么 NTLM 存在风险、为什么会回退到 NTLM）则拆分到了配套文章「图解 NTLM 与 Kerberos ── 为什么认证会「回退」到 NTLM」中。

1. 先说结论

• NTLM 已于 2024 年 6 月被标记为弃用。对象是包括 LANMAN、NTLMv1、NTLMv2 在内的所有版本，这是一项「不再进行积极功能开发」的声明。同时文中也写明「在下一版 Windows Server 与下一个年度发行版 Windows 中，NTLM 仍将继续可用」。¹
• 已经有部分被移除。NTLMv1 已在 Windows 11 版本 24H2 与 Windows Server 2025 中被移除。¹
• 停用分 3 个阶段推进。阶段 1 是使用情况的可视化与审核，阶段 2（2026 年下半年）是用于消除不得不依赖 NTLM 的场景的功能（IAKerb、本地 KDC），阶段 3 是在下一个主要版本中默认禁用网络 NTLM 认证。²
• 现在应该做的只有一件事。运行审核模式，制作出「哪台设备的哪个应用，针对哪台服务器」在使用 NTLM 的清单（第 4 章）。
• 域账户的调查从域控制器开始。按照事件 8004 → 成员服务器的 8003 → 客户端的 8001 的顺序追踪，最终就能追到应用名称（4.2 节）。不过本地账户的认证不经过域控制器，因此不会产生 8004。这类路径需要从服务器端的 8003 和客户端的 8001 中拾取。³
• 大多数原因都出在「名称」上。直接写死 IP 地址与 SPN 未注册是两大主因，两者都无需重新开发应用即可修复（第 5 章）。³²
• 有一种可以只在一台设备上安全试验的方法。在 Windows 11 24H2 / Windows Server 2025 上，可以用 NET USE \\server\share /BLOCKNTLM，在完全不改动任何策略的情况下确认「不使用 NTLM 是否也能连接」（第 7 章）。⁴
• 自研应用应把明确指定 NTLM 的地方改为 Negotiate。微软自己也写明「不要直接访问 NTLM 安全包」（第 8 章）。⁵

2. 「弃用」意味着什么

首先梳理一下术语。如果把这里含糊不清地拿去向公司内部说明，「好像已经不能用了」和「好像还能撑好几年」这两种说法会同时流传开来，导致讨论陷入混乱。

微软「已弃用功能」列表中关于 NTLM 的记述，概括起来主要是以下 3 点。¹

1. 包括 LANMAN、NTLMv1、NTLMv2 在内的所有版本的 NTLM 均不再是积极功能开发的对象，已被弃用。
2. NTLM 的使用在下一版 Windows Server 与下一个年度发行版 Windows 中仍将继续可用。
3. 对 NTLM 的调用应替换为对 Negotiate 的调用。Negotiate 会尝试用 Kerberos 认证，仅在必要时才回退到 NTLM。

作为更新信息，文中还补充说明：NTLMv1 已在 Windows 11 版本 24H2 及 Windows Server 2025 中被移除。¹

也就是说，目前的状态是「弃用（deprecated）」而非「移除（removed）」。不过唯独 NTLMv1，已经越过弃用阶段，进入了移除阶段。如果旧款复合机或 NAS 只能用 NTLMv1 进行认证，那么升级到 Windows 11 24H2 就会直接造成故障。这不是未来的事，而是现在正在发生的事。

还有一点需要掌握：NTLM 仍保留着「没有替代方案的用途」。微软明确指出，配置为工作组成员的系统上的 Windows 认证，以及域控制器以外的本地登录认证，今后仍会使用、也必须使用 NTLM。⁶ 阶段 2 计划推出的本地 KDC，正是为了填补这个「本地账户需要 NTLM」的空缺而设计的功能。²

2.1. 三个阶段的现状

停用的路线图分为 3 个阶段。由于这是随时间变化的信息，下面整理时会附上基准日期（下表是截至 2026 年 7 月的状况）。

希望通过这张表确认的是：现在能靠自己推动的只有阶段 1。阶段 2 的功能在第 6 章的判断表中有些地方写着「可能成为解决方案」，但这些都以确认提供状况为前提。提供时间可能发生变化，因此在本公司做判断的那一刻，请务必重新核实本表的内容。

3. 为什么会被淘汰 ── 只用 3 分钟

作为迁移判断的依据，这里只梳理最基本的内容。详细图解请参阅配套文章。

微软在策略设置文档中明确写道：NTLM 与 NTLMv2 认证，对包括 SMB 中继、中间人攻击、暴力破解在内的各种恶意攻击都很脆弱。⁷ 究其根源，是与 Kerberos 相比而言的以下几项特性。⁸

• 没有相互认证。在 NTLM 中，客户端无法验证服务器的身份，服务器也无法验证另一台服务器的身份。NTLM 是为可以假定「服务器是真实的」这一前提的网络环境而设计的，Kerberos 则不做这样的假设。这一差异，正是让攻击者能够诱使受害者向伪造服务器发送凭据的中继攻击得以成立的条件。
• 服务器每次都要向域控制器发起查询（域账户的情况下）。在 NTLM 中，应用程序服务器每次对域账户的客户端进行认证时，都需要连接域控制器（如果是服务器本地的账户，则由服务器查询自身的账户数据库来判定）。⁶ 在 Kerberos 中，可续订的会话票证取代了这种直通认证，除非需要验证 PAC（特权属性证明），否则服务器无需再访问域控制器。
• 认证材料本身就是密码的哈希值。NTLM 凭据由域名、用户名以及密码的单向哈希构成，客户端用这个哈希值加密质询（challenge）并返回响应。⁵ 由此便产生了一个特性：只要窃取了哈希值，即便不知道明文密码，也能够冒充该用户。

「没有相互认证」在实务上的含义是：仅仅是尝试连接一个 SMB 共享，就可能把凭据交给伪造的服务器。微软之所以提供 SMB 客户端侧的 NTLM 拦截功能，官方给出的解释也是「防止诱使受害者向恶意服务器发送 NTLM 请求的手法」。⁴

4. 审核 ── 列出 NTLM 被使用的位置

这里才是正题。微软的指南也明确指出，在实施限制策略之前，必须先发现并审核当前 NTLM 认证流量的状态。⁹

4.1. 启用审核模式

需要设置的策略共有 3 个，位置都在 计算机配置\Windows 设置\安全设置\本地策略\安全选项，无需重启。无论是保存在本地，还是通过组策略下发，设置一旦生效即会立即启用。⁷

不过「无需重启」和「立即对所有设备生效」是两回事。通过域的 GPO 下发时，保存 GPO 那一刻更新的只是 AD/SYSVOL 上的策略，各终端实际开始审核要等到下一次后台更新，或是执行 gpupdate /force 之后。请把审核期间的起点算作「应用已推送到目标终端的时间」，而不是「保存 GPO 的时间」。如果在这一点上搞错，就会以「第一次汇总时对象设备数偏少」的形式使结果失真。

第 3 项「到远程服务器的传出 NTLM 流量」共有全部允许 / 全部审核 / 全部拒绝 / 未定义这 4 个取值，未定义与「全部允许」等同处理。微软的建议也很明确：不要一开始就选择「全部拒绝」，而是先设为「全部审核」，确认运行日志，掌握哪些服务器在接收认证请求，然后再制作例外列表。⁷

记录位置是事件查看器 > 应用程序和服务日志 > Microsoft > Windows > NTLM（Microsoft-Windows-NTLM/Operational）。由于这项审核并不存在对应的安全审核事件策略，因此要查看的不是安全日志，而是这个通道。⁷

在现场最容易搞混的，是「在哪台机器上设置哪项策略、要看哪个事件」的对应关系。把上表中的 3 项策略分别记作①②③，整理成如下检查清单。

无论哪台机器，日志都是同一个 Microsoft-Windows-NTLM/Operational。①只对域控制器生效，忘记设置②③的终端并不是「没有使用 NTLM 的终端」，而是「没有记录的终端」。这个区别正是导致统计结果失真的最大原因。

注意： 审核模式只负责记录，不会阻止任何操作。另一方面，在设备数量较多的环境中，日志量会一下子暴增。如果没有使用事件收集（WEF），请先重新审视日志大小上限与保留期限，再启用审核。微软的指南也表示，根据部署环境的复杂程度，分析可能需要耗时数月。³

4.2. 追踪要「从域控制器往下游走」

如何解读收集到的事件，有一套固定的顺序。微软指南给出的追踪路径如下。³

flowchart TD
    DC["域控制器<br/>事件 8004"]
    MS["成员服务器<br/>事件 8003"]
    CL["客户端<br/>事件 8001"]
    APP["罪魁祸首应用"]

    DC -->|"安全通道名称 =<br/>应查的服务器"| MS
    MS -->|"工作站名称 =<br/>应查的客户端"| CL
    CL -->|"客户端进程名"| APP
    MS -.->|"PID 为 4(SYSTEM)时<br/>经由 SMB"| CL

图 1：NTLM 审核事件的追踪顺序

各事件中应查看的项目如下。³

在这条路径中，特别有价值的是事件 8001 中的「目标服务器」与「客户端进程名」。前者直接告诉我们「为什么没有走成 Kerberos」，后者直接告诉我们「谁是罪魁祸首」。微软的指南也说明，通过这些信息可以判断出用户连接的是 Web 服务器的 IP 地址，而没有使用本来可以让 Kerberos 生效的 NetBIOS 名称或 FQDN。³

另外，也存在域控制器不产生 8004 的情况。当使用本地用户账户连接文件服务器时，该认证不会经过域控制器。³ 不能因为「查看了 DC 的日志、数量很少」就判断没问题。

4.3. 用 PowerShell 汇总

在事件查看器的 GUI 中逐条查看数千条记录并不现实，因此改用 Get-WinEvent 来汇总。首先确认该机器上各事件分别出现了多少条。

# 按事件 ID 汇总 NTLM/Operational 中的事件(以管理员权限运行)
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Sort-Object Count -Descending |
    Select-Object Count, @{ N = 'EventId'; E = { $_.Name } }

确认有事件产生之后，把客户端一侧的 8001 按「连接目标服务器 × 调用方进程」进行归并。由于字段结构因事件 ID 而异，先用 Format-List 打开一条记录确认结构，再决定索引会更安全。

# 先只确认一条的内容
$sample = Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-NTLM/Operational'
    Id      = 8001
} -MaxEvents 1

$sample | Format-List TimeCreated, Id, Message
# 如果要查看结构化字段
([xml]$sample.ToXml()).Event.EventData.Data |
    Select-Object Name, '#text'

了解结构之后，就通过 XML 的 Name 属性取值再汇总。由于属性名会因操作系统版本而异，用名称检索比用位置索引更不容易出错。

# 汇总最近 7 天内、以「连接目标 × 调用方进程」归并的 8001
$events = Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 8001
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue

$rows = foreach ($e in $events) {
    $data = @{}
    foreach ($d in ([xml]$e.ToXml()).Event.EventData.Data) {
        $data[$d.Name] = $d.'#text'
    }
    [pscustomobject]@{
        Time    = $e.TimeCreated
        # 只按优先级顺序拾取实际存在的字段名
        Target  = @('TargetName', 'TargetServer', 'ServerName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
        Process = @('ClientProcessName', 'ProcessName', 'ApplicationName') |
                  Where-Object { $data.ContainsKey($_) } |
                  ForEach-Object { $data[$_] } | Select-Object -First 1
    }
}

$rows | Group-Object Target, Process |
    Sort-Object Count -Descending |
    Select-Object Count, Name

最后一步汇总返回 Count(件数) 与 Name(把「连接目标, 调用方进程」用逗号连接而成) 这两列。也就是说，输出会是这样的形式（数值只是用于说明的示例）。

Count Name
----- ----
  412 192.168.1.10, System
  118 fileserver.corp.example.com, System
   57 192.168.1.24, MyBizApp.exe
    9 legacy-nas, System

应该看的是 Name 的前半部分，也就是连接目标。逐行的解读方式如下。

件数的绝对值本身意义不大。请关注两点：「指向 IP 地址的行是否排在前面」「有多少行已经细化到可执行文件名」。前者是修复后一定会减少的依赖，后者是可以指派责任人处理的依赖。

由于字段名会因操作系统版本而异，这里采用把候选按优先级排成数组、只拾取实际存在的字段的做法。如果在这里使用 -match 'Process' 之类的部分匹配，会连 ClientProcessId 这样的 PID 字段也一并命中，导致汇总用的不是可执行文件名而是每次都会变化的 PID（由于哈希表的键顺序不固定，具体会取到哪一个也不稳定）。如果 Process 列全部为空，就是候选名称与实际架构不匹配的信号，请把前面步骤中确认到的名称加入数组。

如果要从多台设备收集，用 PowerShell Remoting 并行执行会更快（「PowerShell Remoting（WinRM）入门 ── 批量管理多台 Windows」）。Get-WinEvent 的筛选是否使用 -FilterHashtable，所需时间会有数量级的差异，这方面的要点整理在「用 Get-WinEvent 实务性地排查事件日志 ── 筛选速度决定调查耗时」中。

4.4. 从安全日志一侧查看 ── 确认是否仍在使用 NTLMv1

除了 NTLM/Operational 之外，还有一种方法是从安全日志的登录事件中确认 NTLM 的版本。具体做法是：在安全日志中搜索「认证包」，查看各事件的「详细认证信息」。³

详细认证信息:
    登录进程:            NtLmSsp
    认证包:              NTLM
    迁移的服务:          -
    包名称 (仅限 NTLM):  NTLM V1
    密钥长度:            128

这个「包名称 (仅限 NTLM)」字段，表明使用的是 NTLM 协议族中的哪个子协议。³ 出现 NTLM V1 的主机，若原样升级到 Windows 11 24H2 / Windows Server 2025，就有可能无法通过认证，因为 NTLMv1 已在这些版本中被移除。¹ 运行审核时，请把这一项的优先级单独提高来重点排查。

4.5. PID 全都是 4(SYSTEM)、无法继续排查时

一旦开始审核，几乎必然会撞上这堵墙。像 SMB（共享文件夹）这样经由重定向器通信的应用，发起认证的主体是内核模式的重定向器，因此事件中留下的 PID 始终是 4（SYSTEM）。³

微软指南给出的应对方法如下。³

1. 在发送 NTLM 凭据的客户端（8001 中的「计算机」）上安装进程监视工具。
2. 用对端服务器的计算机名和 IP 地址两者来过滤路径。若需要长时间采集，则以后台模式运行。
3. 将采集结果与服务器端事件 8003 的时间戳进行比对。由于用户、路径、认证标识符是相互对应的，由此便可确定调用方应用。

使用的工具是 Process Monitor（ProcMon）。过滤方式与解读方法整理在「Process Monitor(ProcMon)实战指南 —— 10 分钟定位「配置未生效」「ACCESS DENIED」问题」中。

补充一个实务技巧：先仅凭事件日志把范围锁定到「是哪台设备」，再只对那一台设备安装 ProcMon，这种做法要压倒性地快。给所有设备都部署 ProcMon 并不现实。

5. 回退到 NTLM 的典型模式

通过审核确定位置之后，接下来就是对原因进行分类。微软的指南列举了理论上支持 Kerberos、实际却会使用 NTLM 的应用共 4 种情况。³

• 可以选择各种安全配置或提供程序的应用
• SPN（服务主体名称）未正确配置的应用
• 由于配置错误或供应商文档的原因，使用 IP 地址而非 DNS 名称的应用
• 拥有遗留代码库、其中残留 NTLM 专用部分的应用

微软日本支持博客列举了导致使用 NTLM 的代表性原因：以 IP 地址指定方式访问服务器、防火墙限制了 Kerberos 所需的端口、SPN 未注册、对信任关系对象的认证，以及工作组环境中的认证。²

把这些整理成现场实际遇到的形式，就是下面这张表。右侧两列是用于确定优先级的基准。「影响范围」表示一旦停摆会造成困扰的广度，「修复难易度」表示是否仅凭本公司自己的判断就能修复。掌握这两点，就能直接得出计划书中的着手顺序。

着手顺序，可以机械地根据这两列推导出来。

1. 无论影响范围如何，最优先处理的是只能使用 NTLMv1 的设备，以及记录到 NTLM V1 的主机（4.4 节）。唯独这一项「期限已经到来」，因此要排除在优先级计算之外。¹
2. 其次是影响范围=大、且修复难易度=高，也就是直接写死 IP 地址的情况。这类问题数量多，且仅凭本公司的判断即可修复。最初的 1 个月请集中处理这一类。
3. 再往下是修复难易度=中的 SPN 相关问题。与名称统一工作一并推进。
4. 修复难易度=低的项目（依赖设备、路径问题、等待阶段 2）并非要延后着手，而只是前置周期较长，所以对供应商的咨询和预算申请要与 1～3 并行提前启动。

被归类为「可立即修复」和「注册 SPN 即可修复」的项目，应该会占审核结果的大多数。仅仅消除这些，剩下的例外就会大幅减少。

6. 修复方式判断表

7. SMB 的 NTLM 拦截 ── 实地确认的最短路径

审核日志能告诉我们「正在被使用」，却无法告诉我们「停用之后会怎样」。这时能派上用场的，就是在 Windows Server 2025 与 Windows 11 版本 24H2 中新增的、SMB 客户端侧的 NTLM 拦截功能。⁴

该功能会拦截 SMB 客户端在对远程的传出连接中使用 NTLM 认证。微软表示，这样可以防止诱使用户向恶意服务器发送 NTLM 请求的手法，从而对抗暴力破解、密码破解、Pass-the-Hash 攻击，并将 NTLM 拦截定位为将组织的认证协议切换到 Kerberos 过程中的必要环节。同时也写明，即便不完全禁用 NTLM，也可以只启用这一层防护。⁴

前提条件有以下两项。⁴

• SMB 客户端为 Windows Server 2025 或更高版本，或 Windows 11 版本 24H2 或更高版本
• 连接目标的 SMB 服务器能够使用 Kerberos（SMB 服务器一侧的操作系统，只要能使用 PKU2U 或 Kerberos 即可，不限具体版本）

7.1. 先只用 1 台设备、1 个连接来试验

不要一上来就下发策略，而是利用可以按连接单位指定拦截这一特性。这就是实地确认的最短路径。

# 只对该连接禁止 NTLM 并尝试连接(如果能连上,说明该共享不需要 NTLM 也能满足)
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

# 用 PowerShell 的映射也能做到同样的事
New-SmbMapping -RemotePath \\fileserver.corp.example.com\share -BlockNTLM $true

如果能连上，就说明这条路径不使用 NTLM 也能成立。如果失败，那里就是依赖 NTLM 之处。在完全不改动任何策略的情况下，就能逐个连接地确认「在生产环境中是否会停摆」，因此很适合用来核实审核日志。

结果的确认位置有 3 处。（1）连接成败就是命令本身的结果，成功则会建立映射，出现在 net use 的列表和 Get-SmbConnection -ServerName <服务器名> 中；失败则以错误结束，不会留下映射。（2）是否真的是 NTLM 造成的，需要与下面步骤 3（不带标志的连接）配合判断。如果不带标志也会失败，那就是另一个问题。（3）如果要确定究竟是用什么方式进行的认证，请使用本节最后提到的方法（klist 与服务器端的安全日志）。请不要仅凭错误消息的文字就断定是依赖 NTLM 造成的。

不过，这项确认是需要按步骤进行的。如果不加思考地直接执行，会在两个方向上都产生误判。

$server = 'fileserver.corp.example.com'

# 1. 把到该服务器的映射「一个不留」全部解除
#    只要还残留一个其他共享,针对该服务器的会话就会继续存活
net use | Select-String $server              # 先看看目前连接了什么
net use \\$server\share  /delete
net use \\$server\other  /delete             # 同一台服务器的其他共享也全部解除

# 2. 确认会话确实已经消失(在变为空之前不要进入下一步)
Get-SmbConnection -ServerName $server

# 3. 先确认不带标志也能连接(如果这里失败,就是 NTLM 以外的问题)
net use \\$server\share
net use \\$server\share /delete
Get-SmbConnection -ServerName $server        # 这里也要恢复为空

# 4. 在此基础上加上 /BLOCKNTLM 进行尝试
net use \\$server\share /BLOCKNTLM

• 需要步骤 1～2 的理由： SMB 的会话是按服务器为单位，而不是按共享为单位的。如果针对该服务器的已认证会话仍然存在，重定向器就不会重新进行认证，而是直接复用它。/BLOCKNTLM 生效的范围仅限于为该次映射所进行的认证，并不会追溯校验已经建立的会话（可能是用 NTLM 建立的）。也就是说，仅对测试对象的共享执行 /delete 是不够的。如果同一台服务器的其他共享仍处于连接状态，即便存在 NTLM 依赖也会成功。请让 Get-SmbConnection 的返回结果降到空为止。除了自己的映射之外，常驻应用或备份任务有时也会占用会话。要做到万无一失，最快的方法是从一台从未连接过该服务器的设备上进行试验。
• 需要步骤 3 的理由： 即便是名称解析失败、凭据错误、对共享本身的访问权限不足，带 /BLOCKNTLM 执行也同样会失败。如果不带标志也会失败，那就不是 NTLM 依赖，而是另一个问题。

请注意，这里能够断言的只是「不需要 NTLM」，还不能断言「已通过 Kerberos 完成认证」。该功能的前提条件是「能使用 Kerberos 的 SMB 服务器」，但据说连接目标使用能够支持 PKU2U 的操作系统也可以。⁴ 也就是说，成功的原因有可能不是 Kerberos，而是 PKU2U。如果对方是已加入域的文件服务器，通常不会成为问题；但如果要确定实际是用什么方式进行认证的，请在连接后于客户端执行 klist，查看是否获取到了针对该服务器的 cifs/ 票证，或在服务器端的安全日志中确认登录事件的认证包（4.4 节）。

7.2. 按设备单位启用

核实完成之后，就在试点设备上推进整机层面的拦截。⁴

# 在整个 SMB 客户端中拦截 NTLM(需要管理员权限)
Set-SmbClientConfiguration -BlockNTLM $true

如果使用组策略，则启用 计算机配置 > 管理模板 > 网络 > Lanman 工作站 中的「拦截 NTLM（LM、NTLM、NTLMv2）」。⁴

7.3. 实在无法消除的对象加入例外列表

对于未加入域的 SMB 服务器等实在需要 NTLM 的对象，可以将其设为例外。启用组策略中的 Lanman 工作站 > 拦截 NTLM 服务器例外列表，并列出允许的对象的 IP 地址、NetBIOS 名称、FQDN。⁴

由于没有提供用于创建例外列表本身的 PowerShell cmdlet，首次需要在组策略编辑器中进行设置，但一旦创建之后，逐条追加就可以通过注册表操作来完成。⁴

# 向现有的例外列表追加条目
$params = @{
  Path = "HKLM:\SOFTWARE\Policies\Microsoft\Windows\LanmanWorkstation"
  Name = "BlockNTLMServerExceptionList"
}
$Entries = "192.168.10.10", "corp.contoso.com", "CORP"

$CurrentValue = (Get-ItemProperty @params -ErrorAction SilentlyContinue).BlockNTLMServerExceptionList
$params["Value"] = if ($null -eq $CurrentValue) { $Entries }
                   else { $CurrentValue + $Entries }
Set-ItemProperty @params

注意： 微软文档中给出的示例，在值尚不存在时的分支只是设置了 @("")，导致原本想要追加的条目就这样被丢弃了。⁴ 因此会出现首次执行时一个例外都没有加入、要到第二次执行才终于加入的行为，上面的代码则把未创建时的追加对象也原样写入，以避免这个问题。不过，这个注册表值本来就是由组策略管理的区域。永久性的例外应交由组策略一侧管理，这里的操作请仅限于紧急情况下的临时应对。下一次策略应用时会被覆盖。

注意： 这项功能是SMB 客户端侧的功能。⁴ 对于 SMB 以外的路径（自研应用的 HTTP 通信、连接 SQL Server、WinRM 等）中的 NTLM，这个功能是无法拦截的。这些需要按照第 5 章的分类逐一单独消除。

8. 从开发者视角看 NTLM ── 使用 Negotiate

如果是自己公司在开发 Windows 应用，需要修复的地方是明确的。微软明确写道以下内容。⁵

应用程序不应直接访问 NTLM 安全包，而应使用 Negotiate 安全包。只要参与认证的系统支持，Negotiate 就能够使用更高级的安全协议。目前，Negotiate 安全包会在 Kerberos 与 NTLM 之间做出选择。除非参与认证的系统中有一方无法使用 Kerberos，否则 Negotiate 都会选择 Kerberos。

也就是说，原则是把写着「NTLM」的地方改为「Negotiate」。已弃用功能列表中的记述也是一样，写明应把对 NTLM 的调用替换为对 Negotiate 的调用。¹

8.1. .NET 中常见的「明确指定 NTLM」

// 不好的示例: 在认证类型中明确指定了 NTLM
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "NTLM", credential);

var handler = new HttpClientHandler { Credentials = cache };

// 好的示例: 只改变认证类型,凭据原样传入
var credential = new NetworkCredential(user, password, domain);
var cache = new CredentialCache();
cache.Add(new Uri("http://intra.example.local/"), "Negotiate", credential);

var handler = new HttpClientHandler { Credentials = cache };

这里要改变的只是认证类型的字符串。如果把 credential 替换成 CredentialCache.DefaultNetworkCredentials，那么改变的就不只是认证协议，连认证的主体都会变。届时将不再是原先指定的账户，而是以运行该进程的账户（服务账户或已登录的用户）去进行认证，根据连接目标的权限设置，可能会导致无法运行。协议的替换与凭据的重新审视，请作为两项独立的变更分开进行。

另一方面，如果本来就想使用已登录用户的凭据进行认证（集成 Windows 认证），可以写得更简单。这是有意要改变「以谁的身份进行认证」时的写法。

// 集成 Windows 认证(以当前登录用户进行认证)
var handler = new HttpClientHandler
{
    UseDefaultCredentials = true,
};

关于 HttpClient 本身的处理方式(不要用 using 包裹、创建模式、超时设计)，整理在「不要用 using 包裹 HttpClient —— C# 业务应用的 HTTP 通信实务(创建模式・超时设计・重试)」中。

如果需要直接操作 SSPI，可以使用 .NET 7 及以后新增的 System.Net.Security.NegotiateAuthentication，从托管代码中处理经由 Negotiate 的认证。这里的要点同样是不要在包名中指定 NTLM。

8.2. 比代码更应优先检查的「连接目标的写法」

即便修复了代码，只要连接目标仍然是 IP 地址，最终还是会回退到 NTLM。因为默认情况下，当主机名是 IP 地址时，Windows 不会对该主机尝试 Kerberos 认证，而是回退到 NTLM 等其他可用协议。¹⁰ 具体请排查以下各项。

• 写在配置文件（appsettings.json、App.config、ini 文件）中的服务器名
• SQL Server 连接字符串中的服务器指定（Data Source）
• 拼接 UNC 路径的地方，是否存在硬编码的 IP 地址
• 安装程序或装机手册中的默认值
• 以往在故障处理中因「名称解析不稳定」而改写成 IP、之后一直没有改回来的地方

最后一项真的经常能找到。直接写死 IP 地址在当时是正确的应急处置，但如今已成为技术债务。

8.3. 如果是在开发服务端

如果希望自研的 Windows 服务或 IIS 应用以 Kerberos 方式接受认证，就需要为解密票证的账户，用客户端访问时所使用的名称注册 SPN。正如微软自身所举的代表性示例：即便宣称支持 Kerberos，SPN 未注册的应用仍会回退到 NTLM。³

如果单纯地把注册对象理解为「运行该服务的账户」，在 IIS 上就会栽跟头。IIS 的 Windows 认证默认启用内核模式认证，此时解密 Kerberos 票证的并不是应用程序池的身份，而是 HTTP.sys 所使用的机器账户。即便应用程序池是以专用的域账户运行的，如果把站点的 HTTP SPN 注册到该账户上，就会导致 SPN 的持有者与实际解密的账户不一致，不仅不会回退到 NTLM，反而会因 KRB_AP_ERR_MODIFIED 导致认证本身失败。

要点在于要让「SPN 的注册对象与解密票证的身份保持一致」。可以采取的做法有以下两种。

• 以机器账户解密（维持默认）： 如果站点是以主机名对外发布的，就把该主机名的 HTTP SPN 注册到机器账户上。
• 以应用程序池的身份解密： 启用 useAppPoolCredentials，并把 HTTP SPN 注册到应用程序池的账户上。

选择哪一种，取决于多台服务器是否共享同一个服务账户（如果是共享的，采用池身份的方式会更好处理）。另外，SPN 只能注册到一个账户上，切换时请不要忘记删除旧的注册。重复注册会破坏 Kerberos 认证本身。

如果采用了伪装成客户端去访问其他服务器的设计（委派），NTLM 与 Kerberos 在这方面的处理会有所不同。Kerberos 支持服务代表客户端连接其他服务的委派机制，而 NTLM 所能提供的仅止于本地模拟所需的授权信息。⁸ 模拟相关的实现在「正确处理 Windows 的模拟令牌 ── 线程级权限借用与安全的还原方式」中有介绍。

9. 循序渐进收紧的路线图

综上所述，推进的顺序如下。每个阶段都以「可以撤回」为前提条件。

9.1. 即使停用 SMB，也只是 NTLM 对策的一半

阶段 4～6 处理的仅仅是 SMB。正如第 7 章所提到的，SMB 客户端的 NTLM 拦截是 SMB 客户端一侧的功能，⁴ 对其他路径不起作用。在阶段 2 中被归类为「用 HTTP 进行认证」「SQL Server 变成了 NTLM」「WinRM 在使用 NTLM」的项目，即使推进到阶段 6，仍会原封不动地留在那里。而且这些也不会出现在 SMB 的例外列表中，因此即便清点数量也看不出来。

阶段 6b 就是用来收紧这部分的。使用的正是第 4 章中设为审核模式的那 3 项策略本身。步骤遵循相同的形式。¹¹

1. 将「到远程服务器的传出 NTLM 流量」维持在全部审核状态，排查仍然残留的连接目标
2. 把实在需要的对象注册到「添加远程服务器例外」中
3. 在试点设备上切换为全部拒绝，等待业务运转完一轮
4. 如果没有问题就进行部署

对于域整体，则针对「此域中的 NTLM 认证」，同样按审核 → 例外（「添加此域中的服务器例外」）→ 拒绝的顺序推进。¹² 微软也表示，在选择拒绝选项之前，应先把对应的审核策略设置为同一选项来评估影响。¹²

并不是「拦截了 SMB，NTLM 对策就完成了」。如果要作为完成的指标，请同时清点 SMB 的例外列表与 Restrict NTLM 的服务器例外列表两者。

9.2. 审核期间应以「业务运转一整轮」而非「天数」来决定

阶段 1 中最容易出问题的，是期间的确定方式。如果以「已经收集了 2 周所以就算完成」草草了事，那 2 周内没有运行过的处理就不会出现在清单中。而没有出现在清单中的那些处理，要等到阶段 6 下发拦截之后才会第一次出问题。

具体来说，容易遗漏的有以下这些。

• 月度、季度的结算处理。月末批处理以直接写死的 IP 地址连接共享文件夹或数据库，是典型的例子。
• 年度处理。盘点、年度切换、结算相关。
• 仅在故障时才会经过的路径。从备份恢复的步骤、切换到备用服务器、DR（灾难恢复）演练。
• 长期离线的设备。外出携带的电脑、长期休假负责人的设备、平时不开机的备用机。
• 一年只使用几次的业务应用。

微软的指南自身也表示，根据部署环境的复杂程度，分析可能需要耗时数月。³ 现实中划定界限的方式有以下两种。

1. 让审核持续运行，直到业务运转完一整轮。至少跨过一次月结，最好能跨过一个季度。
2. 排查出低频处理，并有意识地执行它们。如果等不了那么长的时间，可以在验证环境中运行结算处理和 DR 步骤，把结果加入清单。要点在于，通过向负责人询问，事先列举出「只是因为没执行所以没出现」的那些处理。

无论哪种情况，都请先做到能够区分「没有产生事件」和「尚未执行」，再进入下一阶段。

9.3. 不要一步到位切到拒绝

这里的要点是不要一步到位地把「传出 NTLM 流量 = 全部拒绝」切换过去。微软也表示，把该策略设置为拒绝会导致大量 NTLM 认证请求失败，从而可能降低生产力，因此在实施之前应先用「全部审核」确认日志、分析服务器情况，并制作要排除的例外列表。⁷ 针对域整体的「此域中的 NTLM 认证」策略，也写有同样的警告。¹²

10. 总结

• NTLM 已于 2024 年 6 月全版本弃用。这并非会立即停止的变更，据称在下一版 Windows Server 及下一个年度发行版 Windows 中仍会继续可用。¹
• 另一方面，NTLMv1 已经被移除（Windows 11 24H2 / Windows Server 2025）。只能使用 NTLMv1 的设备，以及记录到 NTLM V1 的主机，是最迫近的期限。¹
• 停用分为 3 个阶段：阶段 1 是审核，阶段 2（2026 年下半年）是 IAKerb 与本地 KDC，阶段 3 是默认禁用。²
• 审核的做法是把 3 项策略设为审核模式，收集 Microsoft-Windows-NTLM/Operational。域账户的情况下，按 DC 的 8004 → 成员服务器的 8003 → 客户端的 8001 的顺序，最终能追到应用名称。本地账户的认证不会产生 8004，因此需要从服务器和客户端的事件中拾取。³⁷
• 经由 SMB 时 PID 始终为 4（SYSTEM）。请先用事件日志把范围缩小到设备，再用 ProcMon 追踪那一台。³
• 大多数原因都出在「名称」上。仅消除直接写死的 IP 地址与未注册的 SPN，剩余的例外就会大幅减少。³²
• NET USE \\server\share /BLOCKNTLM 是在不改动任何策略的情况下、仅用一个连接就能完成核实的、最安全的确认手段。⁴
• 自研应用应把明确指定 NTLM 的地方替换为 Negotiate，并把连接目标的写法统一为 FQDN。⁵
• 例外列表并非解决方案，而只是缓冲期。请以数量是否逐年减少作为指标。

相关文章

• 图解 NTLM 与 Kerberos ── 为什么认证会「回退」到 NTLM
• 网络驱动器与 UNC 路径的陷阱 ── 业务应用中处理文件服务器（共享文件夹）的实务
• 用 Get-WinEvent 实务排查事件日志 ── 筛选速度决定调查时间
• Process Monitor(ProcMon)实战指南 —— 10 分钟定位「配置未生效」「ACCESS DENIED」问题
• PowerShell Remoting(WinRM)入门 ── 批量管理多台 Windows
• PowerShell 中凭据的安全处理方式 ── 把明文密码逐出脚本
• 在 WinForms/WPF 应用中集成 Entra ID 认证 —— MSAL.NET 与 WAM Broker 的实务架构
• Windows的TPM是什么 ── 图解「不外泄密钥的保险柜」与度量启动

相关咨询领域

合同会社小村软件承接 NTLM 依赖的盘点、伴随向 Kerberos 前提迁移而来的业务应用改造，以及认证相关故障的排查工作。

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

参考链接

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

NTLM 停用之后，业务会从什么时候开始停止运行？

仅仅是「弃用（deprecated）」的公告，本身并不会导致任何停止。微软在 2024 年 6 月把 NTLM 的所有版本标记为弃用，但当时的说明是「在下一版 Windows Server 以及下一个年度发行版 Windows 中，NTLM 仍将继续可用」。已经确实失效的具体变更，是 Windows 11 版本 24H2 与 Windows Server 2025 中移除了 NTLMv1。未来版本中网络 NTLM 默认禁用的计划虽已公布，但届时据称仍可通过策略重新启用。也就是说，这并非「某一天突然全公司都停摆」的那类变更，而是每次操作系统更新都会逐步收紧的变更。正因如此，与其等到停摆之后再排查，不如趁 NTLM 目前仍在运行时，通过审核日志把依赖之处先梳理清楚，这才是唯一现实的应对方式。

怎样才能列出正在使用 NTLM 的位置？

把组策略中「网络安全：限制 NTLM」系列设置改为审核模式，并收集 NTLM/Operational 日志。在域控制器上设置「审核此域中的 NTLM 认证」，在服务器和客户端上设置「审核传入的 NTLM 流量」以及「到远程服务器的传出 NTLM 流量 = 全部审核」后，事件便会记录到事件查看器的「应用程序和服务日志 > Microsoft > Windows > NTLM」中。对于域账户的认证，追踪顺序是：先在域控制器的事件 8004 中确定用户与目标服务器（安全通道名称），再查看该服务器的事件 8003 中的进程 ID，最后在客户端的事件 8001 中确定「哪个应用、以哪个服务器名」发出了请求。事件 8001 中包含目标服务器名与客户端进程名，追到这一步就能确定罪魁祸首应用。不过本地账户的认证不经过域控制器，因此不会产生 8004。工作组机器或文件服务器上使用本地账户连接共享的这类路径，必须从服务器端的 8003 和客户端的 8001 中拾取。请不要只看域控制器的日志就判断「我们这边用得很少」。

审核之后事件的 PID 全都是 4（SYSTEM），无法判断是哪个应用。

这是因为通信经由 SMB（共享文件夹）。SMB 的认证由内核模式的重定向器执行，因此调用方应用会隐藏在 SMB 数据包的另一侧，事件中记录的 PID 始终是 4（SYSTEM）。微软的指南也明确提到了这种情况，并给出了应对步骤：在出现该事件的客户端上运行 Process Monitor（ProcMon），用对端服务器的计算机名和 IP 地址过滤路径，再与服务器端事件 8003 的时间戳进行比对，从而确定调用方进程。在实务中，先通过事件日志把范围缩小到「是哪台设备」，再只对那台设备用 ProcMon 追踪，是最快的做法。

理应支持 Kerberos 的应用，为什么还是会回退到 NTLM？

大多数情况是名称的问题。微软的指南列举了理论上支持 Kerberos 却仍会使用 NTLM 的四类应用：可以选择安全配置或提供程序的应用、SPN（服务主体名称）未正确注册的应用、由于配置错误或供应商操作手册而使用 IP 地址而非 DNS 名称进行连接的应用，以及遗留代码库中仍残留 NTLM 专用部分的应用。如果事件 8001 中的「目标服务器」既不是 NetBIOS 名称也不是 FQDN 格式（也就是 IP 地址），那么在默认配置下就不会使用 Kerberos。首先要做的两件事是：把直接写死的 IP 地址改为 FQDN；如果是通过别名访问，就为该名称注册 SPN。此外，针对实在无法改成名称的情况，也提供了在客户端设置 TryIPSPN、手动为 IP 地址注册 SPN 的方法，但微软自身也表示应仅限于无法改为 DNS 名称的情况，因此这终究只是最后的手段。

我们自己开发的 Windows 应用，应该修改什么地方？

把认证包中明确指定 NTLM 的地方，替换为 Negotiate。微软明确指出：「应用程序不应直接访问 NTLM 安全包，而应使用 Negotiate 包」。Negotiate 会在 Kerberos 与 NTLM 之间做出选择，除非参与认证的系统中有一方无法使用 Kerberos，否则都会选择 Kerberos。在 .NET 中，典型的修复方式是把传给 CredentialCache.Add 的认证类型从 "NTLM" 改为 "Negotiate"（指定认证类型的是 CredentialCache.Add，而不是 NetworkCredential 的构造函数）。与此同时，还需要把连接目标从 IP 地址或写在 hosts 中的别名改为用 FQDN 指定，并且如果要让自研服务以 Kerberos 方式接受认证，还需要为该服务账户注册 SPN。

作者简介

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

Go Komura

小村软件有限公司 代表

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