samba - Apr 2013 - NT MD4 password encryption question

Are there multiple ways that Windows clients encrypt passwords?  I'm seeing 
different behavior between two clients.

On one, I can access a Samba share just fine.  On the other, using the same 
username and password to access the same share, I get "incorrect
password."

Looking for the difference in Samba debug traces, I find it comes down to 
this:

  smb_password_ok: Checking SMB password for user bryanh
  smb_password_ok: challenge received
  smb_password_ok: Checking NT MD4 password
  smb_password_ok: NT MD4 password check failed
  
on the failing system; same thing but the last word is "succeeded" on
the
working system.

The only relevant difference I can think of between the systems is that the
working system is Windows XP and the failing one is Windows 7.

This really seems to say the two systems are sending a different response 
for the same username/password/challenge.  Is that possible?

This is not current Samba, btw, so I'm not asking anyone to debug it;
I'm
just trying to get a handle on the problem.

Bryan Henderson <bryanh <at> giraffe-data.com> writes:
> 
> Are there multiple ways that Windows clients encrypt passwords?
With more tracing and web searching, I found the answer: yes.  But not in 
the way the Samba log messages suggest.

The client can do at least 3 forms of authentication: original Lanman, NTLM 
Version 1, and NTLM Version 2.
> I'm seeing 
> different behavior between two clients. ...
> The only relevant difference I can think of between the systems is that 
the
> working system is Windows XP and the failing one is Windows 7.
That was the difference.  Windows XP by default does NTLMv1, while Windows 
7 does NTLMv2.  Astonishingly, the client does not ask the server if it 
knows NTLMv2 before using it.  My old Samba server does not.

The structure of Samba made it impossible to tell from the log messages 
that this was the problem.  Samba did notice that what was supposed to be 
an NTLMv1 challenge response wasn't one; where the log messages showed it 
validating an NTLMv1 response, it was really, by design, validating the 
Lanman response field from the same message, as an NTLMv1 response, which 
of course failed.

I found out that manipulating the registry key 
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\LMCompatibilityLevel 
on the Windows 7 client makes it use NTLMv1, and it then works as well as  
Windows XP..