图解 NTLM 与 Kerberos——认证为什么会“回退”到 NTLM

即便是被称作“我们是 Kerberos 环境”的企业内网，只要采集审计日志，也一定会看到 NTLM。而且出现的多半是本应支持 Kerberos 的应用。

这里说的“回退到 NTLM”，不是指认证报错中断，而是指用不上 Kerberos，于是切换到 NTLM。业务照常运转，并不代表实际使用的就是你期望的认证方式。

本文先用图对比 NTLM 与 Kerberos 各自以什么为材料、验证的又是谁。看清这个区别之后，连接目标的名称或账户类型导致认证切换到 NTLM 的原因，以及中继攻击和 Pass-the-Hash 得以成立的原因，都可以用同一套机制来解释。

阅读顺序是机制上的区别 → 发生切换的条件 → 防护与迁移的判断。如果目的是故障排查，请先把“正在用 NTLM 运行”和“认证本身已经中断”区分开，从第 1 章的按目的索引进入第 6 章。

自家环境的盘点步骤（审计策略的设置、事件的追踪方法、修复顺序），汇总在与本文成对的文章《NTLM 停用会导致业务应用停止运行吗》里。

1. 先说结论

最先要把握的是认证的材料、切换到 NTLM 的条件、安全性与迁移方针这三点。

看清机制上的区别

NTLM 根据哈希生成响应，Kerberos 使用指定了连接目标的票据。 NTLM 的凭据是域名、用户名，以及密码的单向哈希。¹ 在 NTLMv2 中，用从该哈希导出的密钥，以服务器的挑战、时间、客户端一侧的挑战、目标信息为材料计算 HMAC（2.2 节）。²

另一方面，Kerberos 以 SPN（连接目标的服务名）为依据签发服务票据，确认的是“谁、对哪个服务”。³ 由这个区别衍生出相互认证、域账户认证时对 DC 的查询、向其他服务的委派这三项差异（第 5 章）。⁴

把切换与认证错误分开

“以 NTLM 运行”和“因 Kerberos 报错而中断”，排查的入口不同。 切换到 NTLM 的主要原因是直接填 IP 地址、SPN 未注册、工作组、到不了 DC 的路径。其中，能否从连接目标的名称解析出 SPN 尤其关键（第 6 章）。⁵⁶

与此相对，像时间偏差这种在 Kerberos 已被选中之后才失败的问题，属于认证本身中断的问题。不要认为失败之后一定会改用 NTLM 重试（6.5 节）。⁷

把握安全性与迁移方针

即使用 NTLMv2，中继攻击和 Pass-the-Hash 的问题依然存在。 中继源于认证往来不绑定目的地，Pass-the-Hash 源于哈希本身就是认证的材料。连接目标是否要求 SMB 签名和通道绑定也在其中，成立条件在第 7 章确认。⁸¹

NTLMv1 已在 Windows 11 版本 24H2 和 Windows Server 2025 中移除。NTLMv2 还能工作，但属于弃用对象（第 8 章）。⁹ 应用不要直接指定 NTLM，而应使用优先选择 Kerberos 的 Negotiate，并在此基础上把能让 Kerberos 成立的名称、SPN、连接路径整理好。¹

按目的与症状阅读

本文讲的是机制与判断。要实施审计配置和盘点的具体步骤，请前往开头介绍的实务篇。

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

2. NTLM 在做什么

本章先把生成响应的一方和验证的一方分开。先看域账户下三方之间的往来，再确认 NTLMv2 的实际计算，以及本地账户时的差异。

NTLM（Windows Challenge/Response）正如其名，是一种挑战/响应方式的认证协议。把微软的说明概括一下：凭据由交互式登录时得到的域名、用户名，以及密码的单向哈希构成（进行哈希的只有密码）；为了不让密码在线路上传输就完成认证，请求认证的一方会做一次计算，以证明自己“能够访问安全保管的 NTLM 凭据”。¹

这里重要的是，认证的材料不是密码本身，而是密码的哈希。正是这一点构成了后面要看的 Pass-the-Hash 的成立条件。

2.1. 域账户下会出现三方

设想一个已经登录的用户，用域账户访问服务器上的资源。这属于非交互式认证，登场的是下面三方。¹

关键在于，资源服务器不是自己验证域用户的响应，而是把计算交给 DC。

图 1 及其下方的 7 个步骤，是微软概述页面给出的概念层面的流程。NTLMv2 准确的响应计算放在 2.2 节。用图 1 读“谁委托谁验证”，用图 2 读“怎么计算”，就不会混在一起。¹

sequenceDiagram
    autonumber
    participant C as 客户端
    participant S as 服务器
    participant DC as 域控制器

    Note over C: 登录时计算密码的哈希<br/>并丢弃密码本身
    C->>S: 用户名（明文）
    S->>C: 8 字节随机数（挑战）
    Note over C: 用密码的哈希<br/>加密挑战
    C->>S: 响应
    S->>DC: 用户名 / 挑战 / 响应
    Note over DC: 从 SAM 取出哈希<br/>做同样的计算
    DC-->>S: 一致则认证成功
    S-->>C: 允许访问

图 1：NTLM 的非交互式认证（域账户的情况）

把图 1 拆成步骤，就是下面 7 步。NTLMv2 的响应计算本身，在接下来的 2.2 节改写。

1. （仅限交互式认证）用户输入域名、用户名、密码。客户端计算密码的加密哈希，并丢弃真正的密码。
2. 客户端把用户名以明文发送给服务器。
3. 服务器生成 8 字节随机数（挑战，即 nonce）并发给客户端。
4. 客户端用该用户密码的哈希加密这个挑战，把结果（响应）返回。
5. 服务器把用户名、发给客户端的挑战、收到的响应这三样发送给域控制器。
6. 域控制器根据用户名从 SAM 数据库取出密码哈希，用它加密挑战。
7. 把自己算出的结果与客户端的响应比较，相同则认证成功。

2.2. 实际的计算——NTLMv2 要更复杂一些

上面这 7 步，是微软在概述页面讲解的基本形态。当前 Windows 实际使用的 NTLMv2，比“用密码的哈希加密挑战”还要再复杂一层。规范（[MS-NLMP]）中的定义如下。²

生成响应密钥，再用挑战等材料计算 HMAC

• 响应密钥为 NTOWFv2 = HMAC_MD5( MD4(UNICODE(密码)), 转为大写的用户名 + 域名 )
• 客户端把响应版本、时间、客户端生成的 8 字节挑战、目标信息（AV 对）连接起来，构成 temp
• 响应的核心是 NTProofStr = HMAC_MD5( 响应密钥, 服务器的挑战 + temp )

只把材料和处理流程抽出来，就是下面这一张图。

flowchart TD
    PW["密码"] --> MD4["MD4(UNICODE(密码))<br/>= NT 哈希"]
    UD["转为大写的用户名<br/>+ 域名"] --> H1["HMAC_MD5"]
    MD4 -->|"以此作为密钥"| H1
    H1 --> KEY["响应密钥 NTOWFv2"]

    MAT["响应版本 / 时间 /<br/>客户端的 8 字节挑战 /<br/>目标信息(AV 对)"] --> TEMP["temp"]

    SC["服务器的挑战"] --> H2["HMAC_MD5"]
    TEMP --> H2
    KEY -->|"以此作为密钥"| H2
    H2 --> PROOF["NTProofStr"]
    PROOF --> RESP["NtChallengeResponse<br/>= NTProofStr + temp"]
    TEMP --> RESP

图 2：NTLMv2 响应的生成过程（密码 → NT 哈希 → 响应密钥 → HMAC）

也就是说，实际计算的是不仅混入服务器的挑战，还混入客户端的随机数、时间、目标信息的 HMAC。验证方也要复现同样的计算。账户在 Active Directory 里，就把挑战与响应的组合发给域控制器验证；账户是服务器本地的，就由服务器用自己保管的 OWF 计算期望值。²

计算变复杂了，但有两点没变

对本文的讨论来说重要的是，即使变复杂，下面两点也没有变。

1. 密钥的材料到现在仍然是密码的哈希。NTOWFv2 的出发点是 MD4(UNICODE(密码))，也就是 NT 哈希本身。² 所以 Pass-the-Hash 能够成立（7.2 节）。
2. 客户端并没有验证服务器是不是真的。微软所说的 NTLM 没有相互认证，在 NTLMv2 中同样成立。⁴

后面的讲解都建立在这两点之上。

2.3. 本地账户下两方就能完成

如果是本地账户，图 1 右侧的域控制器就不见了。

资源服务器在账户是域账户时，会向该域的域控制器上的认证服务查询；而账户是本地账户时，则查阅本地的账户数据库。¹⁰

也就是说，工作组机器，或者用文件服务器的本地账户连接共享的情况，域控制器不会出场，而是服务器查自己的 SAM 自行判定的两方往来。

这个差异直接关系到 6.3 节要讲的“因为是本地账户所以用不了 Kerberos”这类依赖的盘点。即使去看域控制器的审计日志，这条路径上的 NTLM 也不会出现。

2.4. 这种设计带来的三个结果

从目前为止的往来中，可以抽出三条会引出后续故障与攻击的性质。

第 2 行的查询发生在资源服务器每次需要新的访问令牌时。域账户下向 DC 的认证服务确认，本地账户下向本地的账户数据库确认。¹⁰

另外，由于挑战每次都变，同一个响应无法原样重用。但是，把刚收到的挑战与响应在与另一台服务器之间中继，仅凭这一点是防不住的。这个差异在第 7 章来看。

3. 服务器为什么要问域控制器

NTLM 把验证交给持有哈希的一方

域用户的密码哈希在 DC 一侧的账户数据库里。资源服务器不知道该用户的哈希，因此无法自行验证收到的响应。

于是，把用户名、挑战、响应交给 DC 去判定，这就是直通认证。域账户下的 NTLM 认证之所以需要向 DC 查询，正是出自这种职责分工。¹⁰¹

如果是本地账户，确认哈希的地方就是服务器自身的 SAM。“NTLM 要问 DC”这个说法，只适用于域账户的情况。

Kerberos 用票据取代查询

Kerberos 用可更新的会话票据取代了这种直通认证。微软说明，NTLM 中应用服务器每次认证都必须连接 DC，而在 Kerberos 中这种查询就不再需要了。⁴

不过，需要验证 PAC（特权属性证书）时是例外。这并不等于“用了 Kerberos，服务器与 DC 之间就完全没有通信”。

也就是说，迁移到 Kerberos 除了“能确认对方身份”这项安全性改善，还有减少每次认证对 DC 的依赖这层运维上的意义。下一章来看票据是怎么承担这个角色的。

4. Kerberos 在做什么

NTLM 是每次认证都请别人验证响应，而 Kerberos 则是先完成身份确认拿到票据，再把这张票据用于后续认证。图 3 展示了从最初的身份确认到连上服务的整个流程。

KDC（密钥分发中心）运行在域控制器上，把 Active Directory Domain Services 的数据库当作安全账户数据库使用。⁴

看图之前，先把名称和票据分开

图 3 是做身份确认拿到 TGT → 指定 SPN 拿到服务票据 → 向服务出示这三个阶段。要点是不要把 TGT 和服务票据当成同一样东西来读。

sequenceDiagram
    autonumber
    participant C as 客户端
    participant KDC as KDC（域控制器）
    participant S as 服务（由 SPN 标识）

    Note over C,KDC: AS 交换——身份确认与获取 TGT
    C->>KDC: KRB_AS_REQ<br/>（用户名 + 用长期密钥加密的时间）
    Note over KDC: 能用长期密钥解密即为本人
    KDC-->>C: KRB_AS_REP<br/>TGT（用 krbtgt 的密钥加密）+ 会话密钥

    Note over C,KDC: TGS 交换——获取服务票据
    C->>KDC: KRB_TGS_REQ<br/>（TGT + 连接目标的 SPN + 验证子）
    Note over KDC: 从 SPN 查出服务账户<br/>用它的长期密钥加密票据
    KDC-->>C: KRB_TGS_REP<br/>服务票据 + 会话密钥

    Note over C,S: AP 交换——向服务出示
    C->>S: KRB_AP_REQ<br/>（服务票据 + 验证子）
    Note over S: 能用自己的长期密钥解密<br/>= 是发给自己的票据
    S-->>C: KRB_AP_REP（在要求相互认证时）

图 3：Kerberos 的三次交换（AS / TGS / AP）

图例——AS = Authentication Service（认证服务）、TGS = Ticket Granting Service（票据授予服务）、AP = Application（应用程序）。消息名中的 _REQ 表示请求，_REP 表示响应。例如 KRB_TGS_REQ 的意思是“向票据授予服务发出的请求”。

4.1. AS 交换——只做一次的身份确认

发出的东西：用长期密钥加密的时间

客户端向 KDC 发送用户名、域名，以及用自己的长期密钥（从密码派生出的密钥）加密的时间戳。这就是预认证（pre-authentication）。KDC 如果能用该长期密钥解密，并且时间戳合理，就判定“是本人”。³

收到的东西：TGT 与会话密钥

KDC 返回两样角色不同的东西。两者都是“客户端收到的东西”，但客户端能不能读懂里面的内容并不相同。³

持有 TGT 与能读懂 TGT 的内容是两回事。这个区分，引出了接下来“附上 TGT 和验证子提出请求”的步骤。

时间一偏，Kerberos 本身就会失败

这里要记住的是，时间戳是认证的一部分。Kerberos 对时间同步要求严格正是因为这个，默认允许的时间差是 5 分钟。⁷ 超出这个范围，预认证就通不过，Kerberos 认证本身会报错失败（Windows 的时间同步汇总在《Windows 的时间同步（w32time）指南》中）。这里的“Kerberos 失败”与“回退到 NTLM”是两回事。区分方法在 6.5 节讲。

4.2. TGS 交换——申报“要连到哪个服务”

拿到 TGT 之后，接着申请发给连接目标服务的票据。到这一步，“要连到哪个服务”这个名称（SPN）才成为中心。³

客户端向 KDC 发送连接目标的 SPN、TGT、验证子。KDC 查找与 SPN 对应的服务账户，用该账户的长期密钥加密服务票据后返回。³

把这个流程倒过来读，就能看到第 6 章要讲的问题。

• SPN 解析不出来，就签发不了票据。 服务账户如果没有注册 SPN，KDC 就无法确定该用谁的密钥。用 IP 地址连接同样是默认不尝试 Kerberos 的条件（6.1 节）。
• 票据是按目的地制作的。 由于它是用该服务的长期密钥加密的，持有其他长期密钥的服务无法解密。之所以不能换个目的地重用，原因就在这里。

4.3. AP 交换——向服务出示与相互认证

最后是与 KDC 无关的与连接目标服务之间的往来。这里也要把服务一侧的确认和客户端一侧的确认分开来读。

服务一侧：打开发给自己的票据

客户端出示服务票据和验证子。服务用自己的长期密钥解密票据，取出会话密钥和授权信息。能用自己的密钥解密，就是这张票据发给自己的确认。³

客户端一侧：在要求相互认证时确认对方

如果客户端要求了相互认证，服务会把收到的时间戳用会话密钥加密后返回。客户端验证这个响应，确认对方是真正的服务。³

不只是服务确认客户端，客户端也能确认服务。 这就是 NTLM 所没有的相互认证。

5. 决定性的差异

把第 2 到 4 章的机制，从运维和设计上起作用的视角做个对比。对 DC 的查询会因为是域账户还是本地账户而不同，Kerberos 这边也有 PAC 验证这个例外。 请连同条件一起读。

用到委派的设计，还要再选方式

委派是这样一种机制：例如前端的 Web 应用代表用户去连接后端的 SQL Server。在服务器内部模拟用户，与代表用户继续走到另一个服务，要分开考虑。⁴

而且 Kerberos 的委派还分为非约束委派、约束委派（constrained delegation）、基于资源的约束委派（RBCD）。设计上的议题不只是决定“用 Kerberos”，还包括用哪种委派方式。

本文不深入各方式的具体配置。请把这三个名称记住，作为调查需要委派的架构时的下一批检索词。

名称与域的条件，会连到下一步的排查

这张表最后两行，直接就是“回退到 NTLM 的原因”。因为 Kerberos 的强项（绑定目的地、验证对方）是建立在名称能被正确解析之上的。

6. 为什么会“回退”到 NTLM

本章要查的是“业务在运转，但认证变成了 NTLM”的原因。请按连接目标的名称、SPN 的注册、账户、到 KDC 的路径这个顺序确认。如果是认证本身报错，请先到 6.5 节确认是否需要另一套排查方法。

即使应用程序没有直接指定 NTLM，NTLM 也会被用上。因为 Negotiate 就是这么工作的。按微软的说明，Negotiate 会在 Kerberos 与 NTLM 之间做出选择，并且除非参与认证的某个系统用不了 Kerberos，否则选择 Kerberos。¹

也就是说，即便用的是 Negotiate，只要让 Kerberos 成立的条件不齐，选中的就是 NTLM。应用支持 Kerberos，与这条连接实际用上 Kerberos，是两回事。

下面的图和表，是在 NTLM 可用的配置下的典型分支。它并不意味着在 NTLM 本身受限的情况下认证也一定成功。请先查清楚发生切换的原因，对认证方式的限制则结合第 8 章、第 9 章一起确认。

flowchart TD
    START["用 Negotiate 开始认证"]
    Q1{"是域的<br/>账户吗？"}
    Q2{"能从连接目标名称<br/>构造出 SPN 吗？"}
    Q3{"这个 SPN<br/>已注册吗？"}
    Q4{"能到达<br/>KDC 吗？"}
    KRB["用 Kerberos 认证"]
    NTLM["回退到 NTLM"]

    START --> Q1
    Q1 -->|"否<br/>（工作组 / 本地账户）"| NTLM
    Q1 -->|是| Q2
    Q2 -->|"否<br/>（直接填 IP 地址）"| NTLM
    Q2 -->|是| Q3
    Q3 -->|"否<br/>（SPN 未注册 / 用别名访问）"| NTLM
    Q3 -->|是| Q4
    Q4 -->|"否<br/>（分支站点 / VPN / 防火墙）"| NTLM
    Q4 -->|是| KRB

图 4：Negotiate 回退到 NTLM 的分支

先把四大成因按条件、原因、修复方法三列列出来。细节从 6.1 节开始讲。

6.1. 用 IP 地址连接

默认行为：IP 地址不尝试 Kerberos

这是最常见的原因。微软明确写道，默认情况下，当主机名是 IP 地址时，Windows 不会对该主机尝试 Kerberos 认证，而是回退到 NTLM 等其他可用的认证协议。¹¹ 审计指南那边也写着，如果事件 8001 的“目标服务器”既不是 NetBIOS 形式也不是 FQDN 形式，就不会使用 Kerberos。⁵

而且，导致这种情况的原因也被列了出来：由于配置错误或厂商文档的缘故，使用 IP 地址而不是 DNS 名称的应用程序。⁵ 实务中还非常常见另一种情况：过去因为“名称解析不稳定”而改写成 IP 的配置，就这么一直留着。

例外：设置 TryIPSPN，并配置实际会被请求的 SPN

IP 地址不尝试 Kerberos，是默认行为，而不是绝对的限制。 从 Windows 10 版本 1507 和 Windows Server 2016 起，已经有让 SPN 的主机名可以使用 IP 地址的机制。¹¹

需要的是下面两项，缺一不可。

1. 在客户端一侧把注册表值 TryIPSPN 设为 1。
2. 用 Setspn -s <服务类>/<IP 地址> <账户> 的形式，手动注册使用 IP 地址的 SPN。

注册的 SPN，要与客户端实际请求的服务类一致。即便原本的连接目标是同一个 IP 地址，不同服务需要的名称也不一样。

只注册 host/，如果与被请求的 SPN 对不上，Kerberos 照样不成立。微软把这个功能定位为减轻禁用 NTLM 对兼容性造成的影响的手段。¹¹

先改成 FQDN，例外只当最后手段

话虽如此，这并不是首选。微软自己也说，IP 地址是临时的，租约到期与续订会引发冲突和认证失败，因此通常不要用它代替主机名，而且基于 IP 地址的 SPN 注册是手工作业，只应在无法改用基于 DNS 的主机名时使用。¹¹ 审计中发现的直接填 IP 地址，请首先考虑改成 FQDN。TryIPSPN 是对那些实在做不到的对象的最后手段。

6.2. SPN 未注册

接着要看的是，实际访问所用的名称，是否已注册为 SPN。微软把 SPN 未正确配置的应用，列为明明支持 Kerberos 却使用 NTLM 的应用类型之一。⁵

在图 3 的 TGS 交换中，KDC 从 SPN 查出服务账户，用它的长期密钥加密票据。没有 SPN，就无法确定“那个服务的密钥”。

用 DNS 别名（CNAME）或自定义主机名连接时，如果该名称的 SPN 未注册，也会发生同样的事。能用某个名称找到服务器，与能用该名称拿到 Kerberos 的票据，是两回事。

要确认的是应用连接配置里写的名称，以及针对该名称会被请求的服务类的 SPN。有时应用运行得好好的，只是它用的那个名称没有登记在册。

6.3. 本来就在 Active Directory 之外

找出现在必须用 NTLM 的路径

工作组配置的终端，以及用本地账户访问共享，都不在 Kerberos 的场子里。微软也说，对配置为工作组成员的系统进行 Windows 认证，以及在域控制器之外进行本地登录认证，会使用而且必须使用 NTLM。¹⁰

区分本地 KDC 能补上的范围与补不上的范围

这正是不能“简单禁止”NTLM 的原因。第 2 阶段计划提供的本地 KDC，就是为了补上这个缺口的功能。⁶

不过请这样理解：能补上的只有支持该功能的 Windows 之间的情况。对方是旧版 Windows，或者 NAS、多功能一体机这类第三方设备的本地账户认证，本地 KDC 来了也不会自动变成 Kerberos。这类划分在实务篇的第 5 章、第 6 章中讲。

6.4. 到不了 KDC

跨分支站点或经 VPN 到不了 DC，或者 Kerberos 所需的通信被防火墙挡住，也是切换到 NTLM 的原因。⁶ 因为在无法从 KDC 取得所需票据的场景里，使用 Kerberos 的准备工作做不完。

这里请把“能不能到达 DC”，细分到是谁发出的通信。

“客户端到不了 KDC”与“用 NTLM 就不需要 DC”不是一回事。 正如第 3 章所见，域账户的 NTLM 需要服务器一侧向 DC 查询。¹⁰ 即使选中了 NTLM，只要这条验证路径也断了，认证同样完不成。

6.5. 不要把“Kerberos 失败”与“回退到 NTLM”混为一谈

无法开始 Kerberos，与选中之后才失败

最后，把容易混淆但确实不同的两件事区分开。到这里为止的 6.1～6.4，都属于“没能开始 Kerberos”的情形。因为开始不了，Negotiate 才选择 NTLM。

另一方面，Kerberos 被选中之后才失败的问题，要另行排查。典型例子就是 4.1 节也提到过的时间偏差。

只要能解析出 SPN、也能到达 KDC，Negotiate 首先就会选择 Kerberos。但如果时间差超出允许范围（默认 5 分钟），预认证就通不过，会作为 Kerberos 的错误而失败。⁷

“因为用不了 Kerberos 所以选择 NTLM”与“选中的 Kerberos 失败了所以改用 NTLM 重试”，并不是一回事。Negotiate 未必一定会走到后者；应用程序显式改用其他方式重试的情况，也需要另外考虑。

先区分症状，再挑日志和命令

实务上的含义很简单。时间偏差引起的故障，去翻事件 8001 是找不到的。症状也不一样。

请先分清是“回退到了 NTLM”还是“Kerberos 坏了”，再开始排查。这里说的“能用但是 NTLM”这种症状，说的是 NTLM 可用的配置。对 NTLM 的限制与阻止，要与第 8 章、第 9 章分开确认。

7. 从攻击角度看差异——中继与 Pass-the-Hash

中继和 Pass-the-Hash 都被当作 NTLM 的问题来谈，但它们利用的东西不同。

先在 7.1 节看中继能成立的条件，再在 7.2 节看哈希被盗后的问题。

微软在策略设置文档中明确写道，NTLM 及 NTLMv2 认证容易受到包括 SMB 中继、中间人攻击、暴力破解在内的各种恶意攻击。⁸ 至于为什么会这样，看图 1 就能解释。

7.1. 中继攻击——不绑定目的地的后果

sequenceDiagram
    autonumber
    participant V as 受害者的 PC
    participant A as 攻击者的服务器
    participant T as 真正的服务器

    Note over V,A: 把受害者引诱到攻击者的服务器
    V->>A: 开始认证（用户名）
    A->>T: 用同一个用户开始认证
    T-->>A: 挑战
    A-->>V: 把该挑战原样转发
    Note over V: 无法区分它是不是<br/>来自真正的服务器
    V->>A: 响应（用哈希派生的密钥计算）
    A->>T: 把该响应原样转发
    Note over T: 在既不要求签名<br/>也不要求通道绑定的情况下
    T-->>A: 认证成功 → 以受害者身份建立连接

图 5：NTLM 中继的成立（对方没有签名与通道绑定的情况）

中继不需要偷到密码或哈希也能成立

攻击者不需要知道密码，也不需要知道哈希。只要把挑战和响应从左手倒到右手就行。它之所以能成立，是因为客户端一侧没有手段确认“这个响应是不是真的交给了本来想连的对象”。

能不能成立，取决于连接目标的防护

不过，并不是对任何对象都能中继成功。被中继的往来能不能变成可用的会话，取决于连接目标的防护。

• 对要求 SMB 签名的对象走不通。微软明确写道，附在每条 SMB 消息上的签名包含整条消息的哈希，并且由于要确认发送方与接收方的身份，可以防止中继攻击。¹² 另外，域控制器默认会要求连接方使用 SMB 签名。¹²
• 对强制启用 Extended Protection for Authentication（通道绑定）的服务也走不通。因为它把认证绑定到下层的 TLS 通道上，中继到另一条通道的认证就通不过了。

图 5 的前提是接受 NTLM、既不要求签名也不要求通道绑定的对象。不要把它读成“凡是用 NTLM 的连接都无条件能被这样中继”。

这里要确认的不只是防护功能“是否支持”，而是实际上有没有要求、有没有强制。在盘点 NTLM 的同时，确认一下是否配置为要求 SMB 签名，是值得做的。

把向 Kerberos 的迁移与 SMB 一侧的防护放在一起考虑

在 Kerberos 中，同样形式的中继本来就做不到。服务票据是用目的地服务的长期密钥加密的，拿到别的服务那里也解不开。³ 而且客户端还能通过相互认证确认对方是不是真的。⁴

微软之所以准备 SMB 客户端一侧的 NTLM 阻止功能，正是出于这个原因。官方说明它的目的是防止诱使客户端向恶意服务器发送 NTLM 请求的手法。¹³

另外，在 SMB 签名相关的建议中，微软还提到：为了让会话密钥一开始就足够强，应使用 Kerberos 而不是 NTLMv2；以及不要用 IP 地址或 CNAME 记录连接共享（因为那样会使用 NTLM 而不是 Kerberos）。¹² 这和 6.1 节、6.2 节说的是同一件事。

7.2. Pass-the-Hash——哈希等价于密码

flowchart LR
    P["密码"] -->|"单向哈希"| H["密码的哈希"]
    H -->|"导出响应密钥<br/>并计算 HMAC"| R["响应"]
    R --> AUTH["认证成功"]
    STEAL["从终端<br/>窃取哈希"] --> H
    NOTE["不需要<br/>明文密码"] -.-> STEAL

图 6：认证需要的是哈希，而不是明文密码

能用哈希生成响应，这本身就是问题

NTLM 凭据的材料是密码的单向哈希。¹ 在 NTLMv2 中，也是以 MD4(UNICODE(密码)) 为密钥导出响应密钥，再用该密钥计算 HMAC 生成响应。²

也就是说，计算再复杂，出发点没有变。拿到哈希的攻击者，不破解明文密码也能完成以该用户身份认证所需的计算。

光靠密码的复杂度堵不上这条路径

把密码设得又长又复杂，与哈希被盗之后不让它被使用，是两回事。把密码弄复杂，用窃取的哈希的路径依然存在。 微软在讲 SMB 的 NTLM 阻止能对抗的攻击时，除了暴力破解和口令破解，还列出了 Pass-the-Hash。¹³

Kerberos 也有长期密钥。不过，日常认证中来回传递的是有有效期的票据和会话密钥。³ 比较时还需要把“被盗的是什么、其有效范围有多大”这一点一并考虑进去。

8. NTLMv1、NTLMv2 与“移除”

NTLM 不是单一协议，而是包含 LAN Manager 版本 1、2 和 NTLM 版本 1、2 的一组认证协议。¹⁰

这里要区分的是弃用与移除。弃用意味着不再是积极功能开发的对象，移除意味着在相应版本上已经不能用了。

下表把 2024 年 6 月的弃用公告与之后的 NTLMv1 移除并列起来。请不要把第 1 行的“仍可工作”读成第 2 行那些操作系统上也能用 NTLMv1。 对 NTLMv1 而言，适用的是之后的移除。⁹

优先找出只能用 NTLMv1 的对象

也就是说，并不是“因为是 NTLMv2 所以暂时可以放着不管”。不过优先级是明确的：只会说 NTLMv1 的设备和主机优先级最高。审计中记录为 NTLM V1 的主机，一旦直接升级到新版 Windows，认证就通不过了。版本的辨别方法（看安全日志中的“包名称(仅限 NTLM)”），在实务篇文章的 4.4 节讲。⁵

限制策略对 v1 和 v2 都生效

另外，限制 NTLM 的审计与阻止策略，对 NTLMv1 和 NTLMv2 具有相同的效果。⁵ 施加限制时，行为不会因版本而改变。

9. 今后会怎样

迁移的方向，按改变应用的调用 → 减少必须用 NTLM 的场景 → 改变网络认证的默认值这个顺序来把握，就比较好理解。

下面关于 IAKerb、本地 KDC 的提供时间以及默认禁用，都是作为所引用的微软路线图中的计划来讲的。不要把它们当成已经提供的功能，或者在所有设备上都能自动使用的功能。⁶

第一件：在应用程序一侧使用 Negotiate

NTLM 的调用应当替换为 Negotiate 的调用，这是弃用公告本身包含的指示。⁹ 文档也明确写道，应用程序不应直接访问 NTLM 安全包。¹

第二件：减少必须用到 NTLM 的场景本身

第 2 阶段（2026 年下半年）计划提供的 IAKerb 和本地 KDC 属于这一类。⁶ 这是要从协议一侧去补上 6.3 节看到的“因为是本地账户所以用不了 Kerberos”“因为到不了域控制器所以用不了 Kerberos”这两个缺口。

不过能补上的范围是有限的。IAKerb 解决的是到域控制器的可达性，而不是对方是否支持。本地 KDC 也只在支持该功能的 Windows 之间才管用。

如果对方是第三方的 NAS 或多功能一体机，等到第 2 阶段情况也不会变，因此必须自己在设备更新、加入域、切换到其他协议、例外管理之中做出选择。

第三件：改变网络 NTLM 认证的默认值

第 3 阶段计划在下一个主要版本中默认禁用网络 NTLM 认证。⁶ 不过官方也给出了一个前提：可以用策略重新启用。

现在要做的：区分可以指望新功能覆盖的依赖和要自己修的依赖

这个计划的顺序是“先消除使用 NTLM 的理由，再改变默认值”。自家的依赖也按下面这样分好，就不会把该等的和该先修的混在一起。

重要的是，不要把与旧版 Windows 或第三方设备的认证一律归入“等第 2 阶段”。它们不会自动变成 Kerberos，放着不管的话，到了默认禁用的阶段就会以故障的形式暴露出来。

具体的盘点与分类步骤，汇总在实务篇里。

10. 小结

最后，按判断的顺序梳理一遍。

机制：是基于哈希的响应，还是发给特定目的地的票据

NTLM 根据密码的哈希生成对挑战的响应。验证方在域账户下是 DC，在本地账户下是服务器自身的 SAM。¹¹⁰

Kerberos 使用以目的地服务的长期密钥加密的票据。³ 把握了相互认证、每次认证对 DC 的查询、委派这几点差异，就能看清两种方式区别使用的前提。⁴

排查：是在用 NTLM 运行，还是认证本身中断了

如果是切换到了 NTLM，就确认直接填 IP 地址、SPN 未注册、在 Active Directory 之外、到 KDC 的可达性这四个条件。⁵⁶¹¹

另一方面，像时间偏差这种在 Kerberos 被选中之后才出认证错误的问题则另当别论。不要只盯着 NTLM/Operational 的事件 8001，还要查 Kerberos 一侧的事件和时间同步。⁷ 调查的出发点是不要武断地认为“能用就是 Kerberos”“停了就是回退到 NTLM”。

应对：确认防护，再推进 Negotiate 与名称的整备

中继 NTLM 往来的中继攻击，与使用窃取哈希的 Pass-the-Hash，成立的原因和所需的材料都不一样。⁸¹¹³ 在确认连接目标防护条件的同时，逐步减少对 NTLM 本身的依赖。

NTLMv1 已在 Windows 11 24H2 / Windows Server 2025 中移除，包括 NTLMv2 在内的所有版本都已弃用。⁹ 在应用中要做的是使用 Negotiate、把连接目标统一成 FQDN、注册 SPN。¹⁵ 在此基础上，把可以指望新功能覆盖的依赖和必须自己修的依赖分开，推进迁移。

相关文章

• NTLM 停用会导致业务应用停止运行吗——审计日志的采集方法与消除依赖的顺序
• 网络驱动器与 UNC 路径的陷阱——业务应用中处理文件服务器（共享文件夹）的实务
• Windows 的时间同步（w32time）指南
• 用 Get-WinEvent 实务排查事件日志——筛选速度决定调查时间
• PowerShell 中凭据的安全处理——把明文密码逐出脚本
• Windows 的 TPM 是什么——图解“不让密钥离开的保险柜”与度量启动
• 信息安全 10 大威胁 2026——排行榜的看法，以及中小企业真正该防范的东西

相关咨询领域

小村软件有限公司承接因调整认证方式而产生的 Windows 业务应用改造，以及 Kerberos/NTLM 相关认证故障的原因调查。

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

参考链接

相关文章

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

相关主题

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

与本主题相关的服务

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

常见问题

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

NTLM 与 Kerberos，归根结底有什么区别？

最大的区别在于“能不能确认对方的身份”。微软明确写道，在 NTLM 中，客户端无法验证服务器的身份，某台服务器也无法验证另一台服务器的身份。NTLM 是为可以假定“服务器是真的”这种环境设计的，而 Kerberos 不做这种假定。第二个区别是服务器是否需要向域控制器查询。在 NTLM 中，如果是域账户的认证，应用服务器每次认证客户端都要连接域控制器（如果是服务器本地的账户，则由服务器查自己的账户数据库自行判定，域控制器不会出场）。在 Kerberos 中，可更新的会话票据取代了这种直通认证，因此除非需要验证 PAC，服务器不必访问域控制器。第三点是 Kerberos 支持服务的委派（代表客户端连接到其他服务的机制）。

明明应该支持 Kerberos，为什么还是变成了 NTLM？

Kerberos 是以“连接目标的名称”为钥匙来签发票据的机制，名称解析不出来就无法成立。客户端要把连接目标的 SPN（服务主体名称）提交给 KDC 来申请服务票据，但默认情况下，当主机名是 IP 地址时 Windows 不会尝试 Kerberos 认证；而且服务账户如果没有注册 SPN，KDC 也无法签发票据。微软的审计指南也写道，如果事件 8001 的“目标服务器”既不是 NetBIOS 名称也不是 FQDN 形式，就不会使用 Kerberos（关于 IP 地址，可以在客户端设置 TryIPSPN 并手动注册 IP 地址的 SPN，作为例外让 Kerberos 成立，但这被定位为无法改成 DNS 名称时的最后手段）。此外，工作组机器或本地账户的认证（本来就在 Active Directory 之外）、无法到达域控制器的分支站点、对没有信任关系的对方进行认证，也都是 Kerberos 无法成立的条件。Negotiate 会在用不了 Kerberos 时选择 NTLM，所以在这些情况下就会“回退”。

什么是 NTLM 中继攻击？它为什么能成立？

这是一种攻击：攻击者把受害者引诱到自己的服务器，再把到达那里的 NTLM 认证往来原样中继给真正的服务器，从而冒充受害者。之所以能成立，是因为 NTLM 的挑战/响应没有把“在向谁认证”绑定住的机制。客户端只是根据服务器发出的挑战计算并返回响应，在客户端一侧没有办法确认这个响应是发给真正的服务器的，还是攻击者中继过来的。微软自己也在策略设置文档中明确写道，NTLM 及 NTLMv2 认证容易受到包括 SMB 中继、中间人攻击、暴力破解在内的各种恶意攻击。不过，并不是对任何对象都能中继成功。如果连接目标要求 SMB 签名，由于签名会确认发送方与接收方的身份，中继就无法成立；对强制启用 Extended Protection for Authentication（通道绑定）的服务也一样。反过来说，被盯上的是那些既没有签名也没有通道绑定、又接受 NTLM 的对象。在 Kerberos 中，服务票据是用该服务的长期密钥加密的，把发给别处的票据拿到另一个服务那里也无法解密。

Pass-the-Hash 是不是说不破解密码也能冒充身份？

正是如此。NTLM 的凭据由域名、用户名，以及密码的单向哈希构成。在当前 Windows 使用的 NTLMv2 中，响应密钥是以密码的 MD4 哈希（NT 哈希）为密钥导出的 HMAC，再用这个密钥，对服务器的挑战、时间、客户端一侧的挑战、目标信息汇总而成的内容计算 HMAC。虽然不是单纯地对挑战加密，但出发点仍然是密码的哈希，这一点没有变。也就是说，认证需要的是哈希，而不是明文密码。因此，只要攻击者能从终端的内存等处取出哈希，即使不破解密码，也能以该用户的身份完成认证。把密码设得又长又复杂，也堵不上这条路径。微软准备 SMB 客户端一侧的 NTLM 阻止功能，理由之一正是对抗 Pass-the-Hash 攻击。

只要用的是 NTLMv2，短期内就安全了吗？

NTLMv2 比 NTLMv1 强，但并没有被排除在弃用对象之外。微软的已弃用功能列表写道，包括 LANMAN、NTLMv1、NTLMv2 在内的所有版本的 NTLM 都不再是积极功能开发的对象，均已弃用。限制策略的行为也一样，官方说明审计和阻止策略对这两个版本具有相同的效果。另一方面，NTLMv1 的处置不同，它已经不是弃用而是进入了移除阶段，从 Windows 11 版本 24H2 和 Windows Server 2025 开始已被移除。因此正确的结论不是“因为是 NTLMv2 所以暂时可以放着不管”，而是“NTLMv1 现在就是期限，NTLMv2 则要一边盘点一边朝默认禁用的方向推进”。

作者简介

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

Go Komura

小村软件有限公司 代表

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