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

  • 项目

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

适用于： Windows Server 2012 R2
原始 KB 编号： 2701704

摘要

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

例如，使用连接到 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 会话协商中看到安全 Blob，其中包含预期名称字段和 NegotiateFlags，服务器拒绝协商：

      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 的情况下重试， (该 blob 指示扩展的会话安全) 。 在此格式中，你看不到名称字段的相同已知列表，也可能看不到 noNegotiateFlags。 某些字段（如“ClientChallenge”）可能指示客户端尝试执行 NTLMv2 哈希处理。 但由于缺少 NegotiateFlags，它不会作为 NTLMv2 身份验证请求在 DC 上到达。

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

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

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