审核事件将身份验证包显示为 NTLMv1 而不是 NTLMv2 - Windows Server

本文讨论身份验证实际使用 NTLMv2 但报告事件日志中的 NTLMv1 的问题。

原始 KB 数： 2701704

总结

在域中所有计算机上使用 3 或更高版本的 lmcompatibilitylevel 来强制客户端仅使用 NTLMv2。 在测试 IP 地址与网络共享的连接以强制 NTLM 时，发现“身份验证包”仍作为 NTLMv1 列出，该事件（事件 ID 4624）记录在服务器上。

例如，使用连接到 Windows Server 2008 R2 上的文件共享的 Windows 7 客户端进行测试。 网络跟踪显示身份验证实际上是使用 NTLMv2，但在事件日志中报告 NTLMv1：

日志名称：安全性 来源：Microsoft-Windows-Security-Auditing 事件 ID：4624 任务类别：登录 级别：信息 关键字：审核成功 说明: 帐户登录成功。 帐户名称：用户 帐户域：contoso 详细的身份验证信息： 登录过程：NtLmSsp 身份验证包：NTLM 传输的服务： - 包名称（仅限 NTLM）：NTLM V1 密钥长度：128

详细信息

有两种已知方案可能导致此结果。

• 方案 A：Windows Server 2003 域控制器

  我们发现，当验证用户凭据的域控制器是基于 2003 的服务器时，我们可以重现此行为。 Windows Server 2003 在其事件日志记录中没有“身份验证包”字段，这是在 Windows Vista 中添加的一项新功能。

  如果域控制器是 Windows Server 2008 或更高版本，服务器将显示正确列为 NTLMv2 的身份验证包。 如果身份验证协议版本的报告很重要，建议使用 Windows Server 2008 或更高版本的域控制器。

  Windows Server 2003 处于扩展支持阶段，支持将于 2015 年 7 月停用。 请参阅 搜索产品生命周期。

• 方案 B：安全级别协商使用“旧”方法，这意味着尽力而为

  此方案涉及第三方客户端：

  1. 客户具有为 NTLMv1 配置的第三方 SMB 客户端。

  2. 文件服务器配置为 LmCompatiblityLevel=5 和最小 sesion 安全性 NTLMv2，DC 配置为 LmCompatiblityLevel=4。

  3. 第三方客户端上的用户连接。 在 SMB 中，可以看到 SMB 会话中与预期名称字段和 NegotiateFlags 协商中的安全 Blob，服务器拒绝协商：

     NegotiateFlags: 0x60000215 (NTLM v1128-bit encryption, , Sign)
     NegotiateNTLM:                    (......................1.........) Requests usage of the NTLM v1 session security protocol.
     NegotiateNTLM2:                   (............0...................) Does NOT request usage of the NTLM v1 using the extended session security.
     

  4. 然后，第三方客户端在不使用安全 Blob 的情况下重试（这表示扩展会话安全性）。 在此格式中，看不到相同的已知名称字段列表，也可能看不到 noNegotiateFlags。 某些字段（如“ClientChallenge”）可能表示客户端尝试执行 NTLMv2 哈希处理。 但由于缺少 NegotiateFlags，因此不会作为 NTLMv2 身份验证请求到达 DC。

  5. 服务器将包转发到对请求进行身份验证的 DC，并且 DC 可以使用 NTLMv1，因此它会对请求进行身份验证。

  6. 服务器接收成功登录并审核 DC 指定的 NTLMv1。

  对于没有扩展会话安全性的登录，服务器无法基于客户端标志阻止登录请求。 它必须将请求转发到 DC 的最佳标志。 返回时，它还必须接受 DC 在登录时做出的任何决定。 在这种情况下，它接受登录并将其记录为 NTLMv1 登录，即使资源服务器配置为仅允许 NTLMv2。