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

On Wed, Apr 21, 2010 at 3:19 PM, Jeff Layton <[email protected]> wrote:
> On Wed, 21 Apr 2010 09:29:33 -0500
> Shirish Pargaonkar <[email protected]> wrote:
>
>> On Sat, Apr 17, 2010 at 5:29 AM, Jeff Layton <[email protected]> wrote:
>> > On Sat, 17 Apr 2010 15:58:23 +1000
>> > Andrew Bartlett <[email protected]> wrote:
>> >
>> >> On Fri, 2010-04-16 at 22:44 -0400, Jeff Layton wrote:
>> >> >
>> >> > - then I read the spec more carefully. The problem is that the exis=
ting
>> >> > =A0 code doesn't try to use NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECUR=
ITY
>> >> > =A0 (aka NTLM2 -- not to be confused with NTLMv2).
>> >> >
>> >> > Without that, the server expects signatures done using rc4, but cif=
s
>> >> > universally uses md5 signatures.
>> >>
>> >> This isn't the case. =A0SMB signing is always MD5. =A0NTLM2 simply ch=
anges
>> >> the 'effective' challenge and the session key, by providing a value i=
n
>> >> the 'LM hash' to include with the Negotiate-provided challenge.
>> >>
>> >
>> > Interesting. That seems to be contradictory to what the MS-NLMP
>> > document says. If you have a look at section 3.4.4.1, you'll see that
>> > the algorithm for computing the signature does not use md5. However if
>> > you negotiate extended session security (aka NTLM2) or use NTLMv2, the=
n
>> > you're supposed to use md5. Perhaps we should bring that up on the
>> > dochelp list?
>> >
>>
>> > In any case, I think the right solution is just to have CIFS always us=
e
>> > extended session security and NTLMv2.
>>
>> If by extended session security you mean NTLM2, are not NTLMv2 and
>> NTLM2 both authentication mechanisms and orthogonal to each other?
>
> I'd probably call them "mutually exclusive" rather than "orthogonal".
> The NTLM2 flag is always supposed to be set if you're using NTLMv2, but
> its presence doesn't mean you're using NTLMv2.
>
>> In which case, I think cifs/smb2 clients should at least make NTLMv2 aut=
h mech
>> within NTLMSSP (Raw or SPNEGO) work against a Windows server
>> like Windows7/Vista/2008 server, with and without SMB signing.
>>
>
> Agreed, though we need to have some sort of way to automatically fall
> back to NTLM2 if that doesn't work against the server.
>
>> NTLMv.2 in NTLMSSP will work with LMCompatibililtyLevel settings of
>> 0 through 5. =A0I am not whether NTLM2 will work with with settings (eg.=
 4, 5)
>> and I am not sure whether NTLM2 needs/works_with SMB signing i.e.
>> how to calculate session key, mac key, signature etc.
>>
>
> I'll take your word for it. I've walked away from all of this for the
> time being. I will say however that if you're doing some work for this
> for SMB2, then please consider doing this in a fashion that will allow
> the code to be shared with CIFS as well.
>
> --
> Jeff Layton <[email protected]>
>

When I look at Windows - Windows smb2 traces, the (16 bytes) signature
looks nothing like
version (which is 1), ciphertext of 8 bytes of hmac-md5, sequence number