局域网管理器身份验证失败

引言

在许多工业环境中，遗留应用程序需要与不同域中的应用程序进行通信。例如，可能有一个工业控制应用程序位于专用的车间域中，与企业域之间没有任何信任关系。

遗留应用程序通常以本地用户的身份运行，该用户在两台计算机上具有相同的名称和密码。在这种情况下，它们将能够跨安全边界假定彼此的身份，因为服务器上的局域网管理器将基于名称和密码哈希值对客户端进行身份验证，遵循 NTLM 协议。

为了使之工作，用户帐户必须具有相同的名称和密码，因为否则，服务器上启动登录会话的凭据验证将因错误代码 0xC000006A 而失败。

在本技巧中，我描述了一个可能的原因，它不是错误的密码，但看起来像。

问题背景

我在配置通信时遇到了这个问题。

0xC000006D 是一个通用的错误代码，可能表明许多问题，例如 NTLM 不匹配、密码错误等。具体的错误条件通过子状态进行通信，子状态为 0xC000006A，表示“密码错误或格式不正确”。

我绝对确定用户名和密码在两个系统上都匹配。99% 的在线文章对我来说都毫无用处，因为它们都描述了各种密码确实不正确的情况。

身份验证

当客户端想要在服务器上进行身份验证时，它们会启动身份验证协议。在域环境中，这通常是 Kerberos，它是一种可靠的协议，具有许多功能。但它依赖于受信任的中央机构。当客户端和服务器位于没有信任关系的两个域中时，Kerberos 并不是一个选项。相反，使用 NTLM。

NTLM 有不同的版本：LM、NTLM (v1)、NTLMv2。LM 和 NTLM 已过时，绝不应使用。在其他方面，它们容易受到中间人攻击。应仅使用 NTLMv2。

并且此身份验证发生在实际尝试进行凭据验证之前。或者说，凭据验证是整个身份验证过程的一部分。

长话短说：我们排除了防火墙作为可能的问题，排除了用户名和密码错误的可能性，并且能够通过使用不同的计算机作为客户端来解决问题。

最终，我们发现客户端有一个本地安全策略，指定了 LM 和 NTLM 身份验证。

这很奇怪，因为它是一台 Windows 2019 机器，并且配置的设置自 Windows 2008R2 以来就已经过时了。我们正在调查为什么会发生这种情况。无论如何，将此设置修复为“仅 NTLMv2”立即解决了我们的问题。

结论是，即使子状态表明密码不正确，实际上是由于协议错误而无法建立身份验证。

在 Powershell 中检查级别

我创建了一个 PowerShell 函数，它将显示身份验证级别。显然，如果存在禁止远程身份验证的问题，则无法远程运行此函数。

但是，如果您有一个在安装前运行以验证先决条件的脚本，您可以轻松地将其实现为检查此项作为先决条件，如果存在此问题。

function Get-LMCompatibilityLevel
{
    $lmcompat = (Get-ItemProperty 
    -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa').LmCompatibilityLevel
    switch($lmcompat)
    {
        0 {"Send LM & NTLM responses"}
        1 {"Send LM & NTLM – use NTLMv2 session security if negotiated"}
        2 {"Send NTLM response only"}
        3 {"Send NTLMv2 response only"}
        4 {"Send NTLMv2 response only. Refuse LM"}
        5 {"Send NTLMv2 response only. Refuse LM & NTLM"}
    }
}

历史

• 2023年6月21日：第一个版本