Click here to Skip to main content
15,886,919 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
This one has me stumped.
I have 2 computers: A and B. These are in different domains. A network connection needs to be made from A to B. There can be no trust, sso, or whatever.

The only way to make it happen is to have a user for example 'test' with the same password on both systems. Because of how the LSA works, A\Test can connect to B because the LSA on both systems has a user with that password. and will create a new logon session for the network connection. We've done this numerous times for that application.

However, now we have a situation where this doesn't work. We get 'access denied'.

What I have tried:

In the security event log on B, we verify that there is a credential validation error 4625 with error code 0xc00006A. So we know the attempt reached B.
0xc00006A means password error, but we are 100% sure that both passwords and user account names are the same, and can log in on each server locally with that name and password. I've deployed a server C in a different environment, created the same account, and we can connect from C to B no problem.

So far I've verified that the name / password is correct.
I've verified that the attempt reached B.
UAC is disabled.
other servers in A's domain can reach B.

I have thought about a FW issue. However, since the attempt reaches B, I don't know if that makes sense. The one thing that may be either a clue or a red herring, is that the attempts that succeed show in the security log that NTLM is used, and an NTLMv2 channel is established with a key length of 128 bits.

The failed attempts show NTLM, but no key length and no NTLM version. But I don't know if that means anything because if the channel is only established after successful credential validation. If this is the case, it means nothing.

Other than that I've been looking at this for 12 hours so I'm giving it a rest. If anyone had
Posted
Updated 20-Jun-23 5:04am

1 solution

I'm posting the answer here for future reference: The problem was that client and server had different local security configuration. The client had 'Network security: Send LM & NTLM – use NTLMv2 session security if negotiated' Which are incompatible with the server setting of only NTLMv2.

According to Microsoft, the default is 'Send NTLMv2 response only' so for some reason, someone changed that and made it incompatible. Changing it back to the default solved the problem.
 
Share this answer
 

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900