NTLM 停用会导致业务应用停止运行吗——审计日志的采集方法与消除依赖的顺序

“听说 NTLM 要停用了，我们这边没问题吧”——要给出答案，第一件事不是在全公司范围内阻止，而是对现在正在跑的认证做审计。2024 年 6 月微软宣布 NTLM 的所有版本进入弃用状态，但仅凭这条公告，业务并不会停摆。¹

NTLM 的停用不是“某天打上补丁全公司就停摆”那类变更，而是每次把操作系统换新、限制就逐级收紧的变更。要趁 NTLM 还能用的时候，把依赖它的终端、应用、连接目标列成清单，先在小范围里试过再施加限制。先全部停掉、再去找哪里坏了，顺序正好反了。

本文面向管理 Windows 环境的信息系统部门，以及维护业务应用的开发者，给出实务步骤。推进顺序是：审计 → 原因分类 → 名称、配置、代码的修改 → 按连接逐个测试 → 分阶段施加限制。

协议机制本身（为什么 NTLM 有风险、为什么认证不走 Kerberos 而会回退到 NTLM），拆分到了配套文章《图解 NTLM 与 Kerberos——为什么认证会“回退”到 NTLM》中。

停用路线图与功能提供状况的基准时点，与原文一致，都是 2026 年 7 月。请把它与文章结构的更新日期区分开。IAKerb、本地 KDC 等的提供状况，在实际做迁移判断时，要按目标版本的发行说明重新确认。²

从你遇到的问题入手

想通读的话请从第 1 章往下看；要开始实际动手时，请回到第 4 章的审计。

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 章）。⁵

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

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，而且必须使用 NTLM。⁶ 阶段 2 中计划提供的本地 KDC，正是为了填上“本地账户需要 NTLM”这个窟窿的功能。²

2.1. 3 个阶段的当前位置

停用的路线图分 3 个阶段。因为这是随时点而变的信息，所以要带上基准日来整理（下表是 2026 年 7 月时的情况）。

这张表里希望你确认的是，现在能靠自己动手推动的只有阶段 1。阶段 2 的功能在第 6 章的判断表里有几处写着“可能成为解法”，但都以确认提供状况为前提。提供时间是会变的，所以这张表的内容，请在本公司做判断的时点务必重新获取一次。

3. 为什么它会消失——只花 3 分钟

作为迁移的判断材料，只讲最低限度。详细图解交给配套文章。

微软在策略设置的文档里明确写道：NTLM 及 NTLMv2 认证，对包括 SMB 中继、中间人攻击、暴力破解在内的各种恶意攻击都很脆弱。⁷ 根子在于下面这些与 Kerberos 对比时被提及的性质。⁸

没有相互认证

在 NTLM 中，客户端无法验证服务器的身份，某台服务器也无法验证另一台服务器的身份。NTLM 是为“可以假定服务器是真的”的网络环境设计的。Kerberos 不做这个假定。这个差别，正是让认证信息被送到假服务器的中继攻击得以成立的条件。

在域认证中，服务器要去问 DC

在 NTLM 中，应用服务器每次认证域账户的客户端时，都需要连接域控制器（如果是服务器本地的账户，就由服务器查自己的账户数据库来判定）。⁶ 在 Kerberos 中，可续订的会话票据取代了这种传递认证，除非需要验证 PAC（特权属性证书），服务器不必再去找域控制器。

不知道密码，偷来的哈希也会被滥用

NTLM 的凭据由域名、用户名，以及密码的单向哈希构成（进行哈希的只有密码），客户端用这个哈希加密质询并返回响应。⁵ 只要偷到哈希，即便不知道明文密码也能冒充——这个性质正是由此而来。

“没有相互认证”在实务上的含义是：只是想连一下 SMB 共享，就有可能把认证信息交给假服务器。微软之所以准备了 SMB 客户端一侧的 NTLM 阻止功能，给出的理由也是“防止诱使客户端向恶意服务器发送 NTLM 请求的手法”。⁴

4. 审计——把 NTLM 用在哪些地方列成清单

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

4.1. 启用审计模式

注意：审计模式只记录，不阻止任何东西。另一方面，在终端数量多的环境里，日志量会一下子涨上来。如果没有使用事件收集（WEF），请先重新审视日志大小上限与保留期限，再启用。微软的指南也提到，视环境复杂程度，分析可能要花上几个月。³

审计周期要从设置真正铺到目标终端之后开始算。为了不漏掉月度处理或故障时才走的路径，请先看一下 9.2 节的“业务走完一轮”。

设置位置与 3 项策略

要设置的是 3 项策略。位置都在 计算机配置\Windows 设置\安全设置\本地策略\安全选项，而且不需要重启。无论是保存在本地，还是通过组策略分发，设置被应用的那一刻就生效。⁷

不要把保存 GPO 的时刻当作审计的起点

不过“不需要重启”和“立刻对所有机器生效”是两回事。用域的 GPO 分发时，保存 GPO 的那一刻更新的只是 AD/SYSVOL 上的策略，各终端真正开始审计要等到下一次后台刷新，或者执行了 gpupdate /force 之后。审计周期的起点不是“保存 GPO 的日期时间”，而是“应用铺到目标终端的日期时间”，请按后者计。这里搞错了，结果会以“只有第一次汇总时对象台数偏少”的形式被扭曲。

第三项“到远程服务器的传出 NTLM 流量”有全部允许 / 全部审核 / 全部拒绝 / 未定义这 4 个取值，未定义等同于“全部允许”。微软的建议也很明确：不要一上来就选“全部拒绝”，先设成“全部审核”并查看操作日志，摸清哪些服务器在接收认证请求，然后再做例外列表。⁷

要看的不是安全日志，而是 NTLM/Operational

记录位置是事件查看器 > 应用程序和服务日志 > Microsoft > Windows > NTLM（Microsoft-Windows-NTLM/Operational）。这项审计没有对应的安全审核事件策略，所以要看的是这个通道，而不是安全日志。⁷

把机器角色与要记录的事件对应起来

现场最容易搞混的，就是“在哪台机器上放哪项策略、看哪个事件”这个对应关系。把上表的 3 项策略记作①②③，做成检查清单。

日志在任何机器上都是同一个 Microsoft-Windows-NTLM/Operational。①只对域控制器有效，而漏掉②③的终端不是“没有使用 NTLM 的终端”，而是“没有做记录的终端”。这个区别，是让汇总结果失真的最大原因。

4.2. 追踪要“从域控制器往下游走”

首先把认证用的账户区分开。域账户就从 DC 往下游追，本地账户就从服务器和客户端追。³

另外，也存在域控制器上不出现 8004 的情况。因为用本地用户账户连接文件服务器时，那次认证不经过域控制器。³ 不能因为“看了 DC 的日志很少”就判断没问题。

域账户按 8004 → 8003 → 8001 追

微软的指南给出的域账户追踪路径如下。³

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。³

4.3. 用 PowerShell 做汇总

步骤 1：数一数这台机器上记录了哪些事件 ID

在事件查看器的图形界面里翻几千条并不现实，所以用 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 } }

步骤 2：打开一条 8001，确认实际的项目名

确认有事件之后，把客户端一侧的 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'

步骤 3：按连接目标 × 调用方进程汇总

弄清结构之后，用 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

步骤 4：比起条数，更要看连接目标与负责的应用

最后的汇总会返回 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 地址目标的行有没有排在前列”“能查到可执行文件名的行有几条”。前者是改了就一定会减少的依赖，后者是能分派负责人的依赖。

如果汇总出空值或 PID，就要重新检查项目名

字段名在不同的操作系统版本之间有差异，所以这里采用的写法是把候选按优先级排成数组，只取其中真实存在的。这里如果用 -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 V1 的记录要单独列出、优先处理

这个“包名称(仅限 NTLM)”表示用到了 NTLM 协议族中的哪个子协议。³ 出现 NTLM V1 的主机，就是直接升级到 Windows 11 24H2 / Windows Server 2025 后认证会通不过的候选。因为 NTLMv1 在这些版本中已被移除。¹ 跑审计时，唯独这个视角要提高优先级去取。

4.5. 当 PID 全是 4（SYSTEM）、推进不下去时

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

用日志把终端缩小到一台，再用 ProcMon 追那一台

微软的指南给出的处理办法如下。³

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 未注册、对信任关系对端的认证、工作组环境中的认证。²

把原因与修改的优先级记在同一张表里

把这些整理成现场遇到的形态，就是下面这张表。右边两列是用来排优先级的基准。“影响范围”表示停掉之后会造成多大范围的困扰，“修改难易度”表示能不能只凭本公司的判断就改好。有了这两项，直接就是计划书里的动手顺序。

把 NTLMv1 放在最优先，长周期的协调并行启动

动手顺序，从这两列就能机械地定出来。

1. 无论影响范围如何，最优先的是只会说 NTLMv1 的设备，以及记录到 NTLM V1 的主机（4.4 节）。因为唯独这里“期限已经到了”，所以放在优先级计算之外。¹
2. 其次是影响范围 = 大，且修改难易度 = 高的，也就是写死 IP 地址。条数多，而且只凭本公司的判断就能改。第一个月请集中在这里。
3. 再往下是修改难易度 = 中的 SPN 相关。与名称的统一一并推进。
4. 修改难易度 = 低的那些（取决于设备、路径、等阶段 2），并不是动手要往后拖，而只是前置周期长，所以向供应商的问询和预算申请要与第 1～3 项并行、提前启动。

被归入“马上能改”和“注册 SPN 就能改好”的，应该会占审计结果的大部分。光把这些消掉，剩下的例外就会少很多。

6. 修改方式的判断表

按第 5 章标上的分类来选处理办法。先推进改为 FQDN 和确认 SPN，TryIPSPN 只作为改不了名称时的最后手段。IIS 的 SPN 注册对象有例外，动手之前请先看 8.3 节的“解密票据的身份”。

7. SMB 的 NTLM 阻止——实地验证的最短路径

审计日志能告诉你“正在被使用”，但不会告诉你“停掉会怎样”。这时派上用场的，是Windows Server 2025 与 Windows 11 版本 24H2 中新增的、SMB 客户端一侧的 NTLM 阻止。⁴

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

注意：这个功能是SMB 客户端一侧的功能。⁴ SMB 以外的路径（自研应用的 HTTP 通信、到 SQL Server 的连接、WinRM 等）上的 NTLM，用它是拦不住的。那些要按第 5 章的分类逐个消掉。

前提条件有下面两条。⁴

• SMB 客户端是 Windows Server 2025 或更高版本，或 Windows 11 版本 24H2 或更高版本
• 连接目标的 SMB 服务器能够使用 Kerberos（SMB 服务器一侧的操作系统，只要能用 PKU2U 或 Kerberos，什么都行）

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

不要一上来就下发策略，而是利用可以按连接单位指定阻止这一点。不过要做出判断，需要清除已有会话，并确认不加标志时能连上。下面两条命令只是指定方式的示例，实际的测试请按再下面的 4 个步骤来做。

# 只对这个连接禁用 NTLM 再连一次（连上了，就说明这个共享不用 NTLM 也够）
NET USE \\fileserver.corp.example.com\share /BLOCKNTLM

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

满足必要前提后能连上，就可以判断这条路径不用 NTLM 也成立。失败时，要与不加标志的测试对照，把原因区分开。因为不改策略就能一个连接一个连接地确认，所以适合用来核实审计日志。

结果要分成下面 3 个层面来确认。不要只凭错误消息的措辞就断定是依赖 NTLM。

避免误判的 4 个步骤

不过这个确认是有步骤要求的。不假思索地执行，两个方向上都会误判。

$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

注意：微软文档里登载的示例，在值还不存在时的分支只是设置 @("")，想追加的条目就这么被丢掉了。⁴ 表现出来就是：首次执行一条例外都进不去，第二次执行才终于进去。所以上面的代码在尚未创建时，也会把待追加的对象直接写进去。话虽如此，这个注册表值本来就是组策略管理的地盘。永久性的例外请在组策略一侧管理，这个操作只限于紧急时的临时处置。下一次策略应用就会把它覆盖掉。

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》里。

直接使用 SSPI 时，同样要指定 Negotiate

如果必须直接使用 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。“未注册 SPN 的应用程序，即便声称支持 Kerberos 也会回退到 NTLM”，这正是微软自己举出的典型例子。³

在 IIS 中，应用程序池的身份未必就是解密的身份

如果简单地认为注册对象是“运行服务的账户”，在 IIS 上就会栽跟头。IIS 的 Windows 身份验证默认启用内核模式身份验证，此时解密 Kerberos 票据的不是应用程序池的身份，而是HTTP.sys 使用的计算机账户。仅仅因为用专用的域账户运行应用程序池，就把站点的 HTTP SPN 注册到那个账户上，会造成SPN 的所有者与实际解密的账户对不上，结果不只是回退到 NTLM，而是直接以 KRB_AP_ERR_MODIFIED 认证失败。

要点是“让 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 的例外列表里，所以数条数也看不见。

SMB 以外用 Restrict NTLM，按审计 → 例外 → 拒绝推进

收紧那一块的是阶段 6b。用的就是第 4 章里改成审计模式的那 3 项策略本身。步骤也是同一个形状。¹¹

1. 保持“到远程服务器的传出 NTLM 流量”为全部审核，把还剩下的连接目标梳理出来
2. 把实在必需的对端登记到“添加远程服务器的 NTLM 身份验证例外”
3. 在试点终端上切换为全部拒绝，等业务走完一轮
4. 没有问题就推广

整个域也要先用对应的审计确认影响，再转拒绝

对整个域，则用“此域中的 NTLM 身份验证”，同样按审计 → 例外（“添加此域中的服务器例外”）→ 拒绝的顺序推进。¹² 微软也表示，在选择拒绝选项之前，应把对应的审核策略设为同一选项以评估影响。¹²

并不是“阻止了 SMB，NTLM 对策就完成了”。要作为完成指标的话，请把 SMB 的例外列表和 Restrict NTLM 的服务器例外列表两边都清点一遍。

9.2. 审计周期不按“天数”定，而按“业务走完一轮”定

阶段 1 里最容易失败的，就是周期的定法。要是按“收了两周就算完成”来办，那两周里没有跑过的处理就不会出现在清单上。而没上清单的东西，会在阶段 6 下发阻止之后才第一次坏掉。

不只是月度处理，恢复流程和离线终端也要梳理

具体来说，容易漏掉的是下面这些。

• 月度、季度的结账处理。月末批处理用写死的 IP 地址连共享文件夹或数据库，就是典型例子。
• 年度处理。盘点、年度切换、决算相关。
• 只有出故障时才会走的路径。从备份恢复的步骤、切换到备用服务器、DR 演练。
• 长期离线的终端。外带 PC、长假中的负责人的终端、平时不开机的备用机。
• 一年只用几次的业务应用。

等不及的话，就有意地把低频处理跑一遍

微软的指南自身也说，分析视部署的复杂程度可能长达数月。³ 现实的划线方式是下面两种之一。

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 的构造函数）。与此同时还需要：把连接目标写成 FQDN，而不是 IP 地址或写在 hosts 里的别名；如果要让自研服务以 Kerberos 接受认证，还得给那个服务账户注册 SPN。

作者简介

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

Go Komura

小村软件有限公司 代表

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