On Wed, 30 Jun 2010 09:25:10 +1000 Andrew Bartlett <abartlet@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxx> > > > > > > > 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. -- Jeff Layton <jlayton@xxxxxxxxx>
Attachment:
signature.asc
Description: PGP signature
