[linux-cifs-client] Linux CIFS NTLMSSP mount failing against win2k8

[Andrew Bartlett]

On Fri, 2010-04-16 at 22:44 -0400, Jeff Layton wrote:
> On Wed, 14 Apr 2010 11:34:53 -0400
> Jeff Layton <jlayton at samba.org> wrote:
> 
> > On Wed, 14 Apr 2010 08:29:44 -0400
> > Jeff Layton <jlayton at samba.org> wrote:
> > 
> > > On Wed, 14 Apr 2010 09:01:32 +1000
> > > Andrew Bartlett <abartlet at samba.org> wrote:
> > > 
> > > > On Sun, 2010-04-11 at 19:40 -0400, Jeff Layton wrote:
> > > > 
> > > > > I don't think that's right. CIFS_SESS_KEY_SIZE is 24 bytes. According
> > > > > to the MS-NLMP document, the session key should be 16 bytes. The
> > > > > signing key is different with NTLMSSP than with "raw" NTLM and NTLMv2.
> > > > 
> > > > So, with NTLMSSP the 24 byte (actually variable, it is much lager for
> > > > NTLMv2) response is not included in the MAC calculation - just use the
> > > > 16 bytes session key only. 
> > > > 
> > > > Andrew Bartlett
> > > > 
> > > 
> > > That was it! I was putting the right key into the NTLMSSP response, but
> > > was leaving the saved key used for signing as a 40-byte key. When I
> > > limit the key length to 16 then signing works correctly.
> > > 
> > > I'll need to clean up the code a bit, but will post a patch to fix this
> > > soon.
> > > 
> > > Many thanks,
> > 
> > Sigh, I made a mistake in testing. This didn't actually fix the
> > problem. The tree connect is still rejected after session setup. The
> > odd thing here is that this mount works against my samba server
> > (samba-3.4.7-58.fc12.x86_64).
> > 
> > Anyway for the purposes of discussion, here is the current patch I've
> > got. Signing is still busted with this though. Anyone have thoughts on
> > what we're doing wrong here?
> > 
> 
> An update on this...
> 
> I think I now understand what the problem is. Volker pointed me in the
> right direction. There were several problems actually:
> 
> - the sequence number was wrong. With a 4-packet Session Setup
>   exchange, the following tree connect should be sequence number 2. I
>   hacked in a quick fix for that but it still didn't work...

Yes, you do need to get the sequence number right. 

> - then I read the spec more carefully. The problem is that the existing
>   code doesn't try to use NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY
>   (aka NTLM2 -- not to be confused with NTLMv2).
> 
> Without that, the server expects signatures done using rc4, but cifs
> universally uses md5 signatures. 

This isn't the case.  SMB signing is always MD5.  NTLM2 simply changes
the 'effective' challenge and the session key, by providing a value in
the 'LM hash' to include with the Negotiate-provided challenge.

> So we need to negotiate with that flag
> too. At this point, I don't have the time to undertake this project
> (and it does seem to be a project), so I've left this code alone for
> now. It may be quite some time before I can fix this. It would be great
> if someone else could take on this project instead :)
> 
> There are a couple of other things that could stand to be fixed too:
> 
> - The client uses NTLMv1 auth in the exchange. It seems like it would
>   be better to use NTLMv2 instead. Are there any known servers that
>   support the NTLMSSP GSSAPI scheme but that don't support NTLMv2 auth?

There are.  The compatibility for NTLMv2 is dependent entirely on the
domain controller, while 'NTLM2 session security' does not need
co-operation from the DC. 

However, all real world DCs now support NTLMv2, as long as you get the
workstation names right etc. 

> - The code uses its own crypto routines. It would be preferable to have
>   it use the kernel's crypto API where possible.
> 
> - being able to do SPNEGO-wrapped NTLMSSP instead of just "raw" would
>   also be great.
> 
> Anyway, hopefully these notes will be helpful to whomever ends up
> fixing this code.

I'm happy to help confuse you further if required ;-)

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100417/74fc6aaa/attachment.pgp>