Re: Linux CIFS NTLMSSP mount failing against win2k8

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 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.
>>
>
> 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, then
> 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 use
> 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?
In which case, I think cifs/smb2 clients should at least make NTLMv2 auth mech
within NTLMSSP (Raw or SPNEGO) work against a Windows server
like Windows7/Vista/2008 server, with and without SMB signing.

NTLMv.2 in NTLMSSP will work with LMCompatibililtyLevel settings of
0 through 5.  I 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.

>
>> > 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 ;-)
>>
>
> Thanks. This protocol is INSANE. I think we're going to have to
> overhaul a lot of the CIFS crypto from the ground up in order to do
> this right.
>
> --
> Jeff Layton <[email protected]>
>