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

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

09/14/2020

本文内容

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

原始产品版本：  Windows Server 2012 R2

原始 KB 编号：  2701704

摘要

在域中的所有计算机上使用 lmcompatibilitylevel 3 或更高版本，以强制客户端仅使用 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：安全级别的协商使用表示最大努力的"旧"方法

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

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

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

第三方客户端上的用户进行连接。 在 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.

然后，第三方客户端重试，而不使用安全 blob (这表示扩展的会话) 。 在此格式中，您不会看到相同的名称字段的已知列表，也可能看不到 NoNegotiateFlags。 某些字段(如"ClientChallenge")可能指示客户端尝试执行 NTLMv2 哈希处理。 但由于缺少 NegotiateFlags，这不会作为 NTLMv2 身份验证请求到达 DC。

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

服务器接收成功登录，并按 DC 指定的 NTLMv1 进行审核。

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