Linux CIFS NTLMSSP mount failing against win2k8
Jeff Layton
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 <jla...@samba.org>
Shirish Pargaonkar
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.
Regards,
Shiris
Shirish Pargaonkar
I could not go as far as you have gone with cifs (and smb2) against
Windows 7 and Windows 2008 server.
For me even session setup was/is not working. I found event log on
Windwos box to be useful.
I keep getting this error for both cifs and smb2 logins against both
Windows7 and Windows 2008 Server.
> Logon Type: 3
> Account For Which Logon Failed:
> Security ID: NULL SID
> Account Name: root
> Account Domain:
> Failure Information:
> Failure Reason: An Error occured during Logon.
> Status: 0xc0000225
> Sub Status: 0x0
> Process Information:
> Caller Process ID: 0x0
> Caller Process Name: -
> Network Information:
> Workstation Name:
> Source Network Address: 1.2.345.678
> Source Port: 59215
> Detailed Authentication Information:
> Logon Process:
> Authentication Package: NTLM
> Transited Services: -
> Package Name (NTLM only): -
> Key Length: 0
Jeff Layton
Shirish Pargaonkar <shirishp...@gmail.com> wrote:
Thanks. With Steve's help last night, I figured out that the problem is
with the signing key. When I stopped the server from requiring signing,
then I can mount. So what seems to be happening is that the NTLMSSP
session setup works, but when we go to sign the first packet (the tree
connect), the server rejects it.
It looks like this code is still just stubs and the session key is just
zeroed out regardless of whether signing is done:
-----------------[snip]---------------
sec_blob->SessionKey.BufferOffset = cpu_to_le32(tmp - pbuffer);
sec_blob->SessionKey.Length = 0;
sec_blob->SessionKey.MaximumLength = 0;
-----------------[snip]---------------
...samba 3.4 however seems to be fine with this, even when I request
signing so there may be a samba bug related to this as well.
I think we need to put a key in that field and may need to alter the
flags (i.e. add the key exchange flag, etc). It's not 100% clear to me
what exactly needs to go in that field though, and what flags we need
to have set at each stage. I'll note that the negotiation flags that
smbclient uses are very different from what we're sending. smbclient
also sends a 16 byte key as the session key.
--
Jeff Layton <jla...@samba.org>
Shirish Pargaonkar
Jeff,
I see that this is ntlm and ntlmv2. I think, with ntlmv2, your session
setup will not succeed
with the current cifs/smb2 code against Windows7 and Windows 2008 server.
Regards,
Shirish
Shirish Pargaonkar
I think this is the signature for ntlmv2 authentication
hmac_md5_final(ses->server->mac_signing_key.data.ntlmv2.key, &context);
and this is the signature for ntlm authentication
memcpy(key->data.ntlm+16, rn, CIFS_SESS_KEY_SIZE);
to be filled in session key in ntlmssp security blob
Jeff Layton
Shirish Pargaonkar <shirishp...@gmail.com> 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.
--
Jeff Layton <jla...@samba.org>
Andrew Bartlett
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.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.