Linux CIFS NTLMSSP mount failing against win2k8

[Steve French]

On Wed, Jun 30, 2010 at 6:55 AM, Jeff Layton <jlayton at samba.org> wrote:
> On Wed, 30 Jun 2010 09:25:10 +1000
> Andrew Bartlett <abartlet at samba.org> wrote:
>
>> On Sat, 2010-04-10 at 23:09 -0500, Shirish Pargaonkar wrote:
>> > On Sat, Apr 10, 2010 at 5:17 PM, Jeff Layton <jlayton at samba.org> wrote:
>> > > I've been playing with NTLMSSP today in CIFS, and have run across a
>> > > problem. The Session Setup using Raw NTLMSSP succeeds, but then afterward
>> > > the tree connect fails with STATUS_ACCESS_DENIED. The odd thing is that
>> > > if authenticate as the same user using krb5, then it works fine.
>> > > smbclient does SPNEGO encapsulated NTLMSSP and the tree connect it does
>> > > works fine as well.
>> > >
>> > > Attached is a capture that shows two "mount attempts". The first one
>> > > fails (that the Linux CIFS one). The second succeeds -- that's the
>> > > Linux CIFS one.
>> > >
>> > > The code I'm using is slightly modified so that the tree connect is
>> > > closer to identical to what smbclient does. That doesn't get around the
>> > > problem though. I assume that there must be something wrong with the
>> > > session setup, but since it succeeds it seems like it ought to work...
>> > >
>> > > Does anyone have any clue as to what the problem is? Or does anyone
>> > > know how to make win2k8 tell me why it's refusing the tree connect? The
>> > > event viewer seems to be pretty useless for this, but maybe I'm just
>> > > not looking in the right place?
>> > >
>> > > --
>> > > Jeff Layton <jlayton at samba.org>
>> > >
>> >
>> > Jeff,
>> >
>> > You can see if this code change,
>> >   cifs_MD5_update(&context, (char *)&key->data, 16);
>> > insetead of
>> >  cifs_MD5_update(&context, (char *)&key->data, key->len);
>> > in function cifs_calculate_signature() works.
>>
>> If I had some context, I would be able to advise if this is correct.  If
>> this is the application of the 'session key' to the SMB singing (the MD5
>> with the actual packet), then this is important, but only for Kerberos,
>> not NTLMSSP, which for all versions returns a 16 byte key.
>>
>
> (dropping old linux-cifs-client list and adding new one to cc list)
>
> Unfortunately, I haven't had time to spend on this in a while so I
> haven't really given it the time it deserves.  My gut feeling is that
> there are enough questionable portions of this code in CIFS that it
> really needs an overhaul from "first principles" -- starting by making
> the encryption algorithms use the standard kernel crypto libs and a
> review of what NTLMSSP flags are being set in the negotation. Some of
> that may just be my lack of familiarity with the code, but a lot of the
> unicode conversion in smbencrypt.c looks questionable.

I would like to make some simplifying assumptions, e.g.
the number of NTLMSSP flags we use.  For SMB2 it
is easier because we can limit support to only
two auth mechanisms: krb5 in spnego and ntlmv2 in ntlmssp -
and only one signing mechanism (the new SHA256 one),
but for cifs we have old servers that won't support those.

The originals for a few key pieces of the old came from Samba,
so it probably had some of the same problems with Unicode
that you noted.  Converting the RC4-MD5-HMAC to kernel crypto libs is harder
than it seems.  Shirish had some trouble with the kernel crypto (as did I a
few years ago when I tried it - the code got uglier/bigger using those
interfaces).

The documentation for this is harder than it seems to wade through
(due to lack of examples).

-- 
Thanks,

Steve