LAN Manager Authenticate Failure

Introduction

In many industrial settings, legacy applications need to communicate with applications in a different domain. For example, there could be an industrial control application in a dedicated shopfloor domain, without any kind of trust relationship to the corporate domain.

It is not uncommon for legacy applications to run under the credentials of a local user with the same name and password on both computers. In that case, they will be able to assume each other's identity across security boundaries because the LAN manager on the server will authenticate the client based on the name and password hash, following the NTLM protocol.

For this to work, it is crucial that the user account has the same name and password, because otherwise the credential verification starting the logon session on the server will fail with error code 0xC000006A.

In this tip, I describe a possible reason that is not a bad password, but looks like it.

Problem Background

I encountered this problem while configuring communications.

0xC000006D is a catch-all errorcode that could indicate a number of problems, such as NTLM mismatch, bad password, etc. The specific error condition is communicated via the substatus, which is 0xC000006A and means 'Bad or malformed password'.

I was absolutely certain that the username and password matched on both systems. 99% of all articles online were useless in my case because they all described various scenarios where the password was indeed incorrect.

Authentication

When a client wants to authenticate on a server, they engage in an authentication protocol. In a domain environment, this is often Kerberos, which is a reliable protocol with many features. But it relies on a trusted central authority. When client and server are in different domains without trust between them, Kerberos is not an option. Instead, NTLM is used.

NTLM comes in different flavors: LM, NTLM (v1), NTLMv2. LM and NTLM are obsolete and should never be used. Among other things, they are vulnerable to man-in-the-middle attacks. Only NTLMv2 should be used.

And this authentication takes place before the actual credential validation is attempted. Or rather, the credential validation is part of the overall authentication process.

Long story short: we eliminated the firewall as a possible problem, we eliminated the possibility of a bad username and password, and we were able to get things to work by using a different computer as client.

Eventually, we found that the client had a local security policy that specified LM and NTLM authentication.

This was bizarre because it's a Windows 2019 machine and the configured setting has been obsolete since Windows 2008R2. We're looking into why that happened. In any case, fixing this setting to 'NTLMv2 only' immediately solved our problems.

The conclusion is that even though the sub status indicated that the password was incorrect, it really was a matter of not being able to establish authentication due to protocol error.

Checking the Level in Powershell

I made a PowerShell function that will display the authentication level. Obviously, if there is a problem that prohibits remote authentication, this cannot be run remotely.

However, if you have a script that is run before installation to verify the prerequisites, you can easily implement it to check this as a prerequisite if the chance exists that this is going to be an issue.

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"}
    }
}

History

• 21^st June, 2023: First version