Created attachment 7675 [details]
command output and wireshark packet traces
One of the fileservers at my institution is a packaged solution by Nexenta, a NexentaStore 3.1.3. Samba 3.4.7 (from Ubuntu 10.04) connects to this server fine. We are having issues with Samba 3.6.6 (from Debian unstable). The problem is also reproducible using Samba 3.6.3.
Using mount.cifs, e.g.
$ sudo mount.cifs //host/share /mnt/point -o credentials=/path/to/credentials
Everything works fine.
Using smbclient, e.g.
$ smbclient //host/share -A /path/to/credentials
session setup failed: NT_STATUS_WRONG_PASSWORD
So this would, at first blush, appear to be a regression in smbclient. More detailed command output and wireshark packet traces are attached. (Password changed to protect the innocent.)
Just for fun, we also tried connecting using smbclient from the beta of Samba 4 (from the samba4-clients package in Debian unstable). smbclient4 is able to connect to the server successfully.
Hmmm, there's an extra "NetBIOS host name" field in the smbclient3 sessionsetup request that's not in the smbclient4 one.
I'll look closer.
Ok, checked a 3.6.6 smbclient against a Win7 server, and it works fine of course.
But Win7 is using GSSAPI/SPNEGO auth, and the Nexenta seems to be doing raw NTLM-only.
Is there a way to make that server do GSSAPI/SPNEGO ?
Yeah, the negprot reply doesn't have "extended security" negotiated.
Ok, I'm trying to get Win7 to accept an 3.6.6 smbclient logon without extended security, and I keep getting "bad parameter" back.
It's almost certainly the extended security issue.
Ok, try settting "client NTLMv2 auth = false" in your smb.conf, and try again against the Nexenta box. I'm guessing that will get around the problem.
It looks like using NTLMv2 auth without extended security might be an unsupported configuration in Windows, but I'm going to get Andrew Bartlett to look at this to make sure.
Created attachment 7676 [details]
smbclient output with "client NTLMv2 auth = false"
Thank you Jeremy, you are quite right! Adding "client NTLMv2 auth = false" to smb.conf does indeed make smbclient connect. Is there any chance a more transparent fix will make it into a future release of Samba 3?
Also, with regards to the Nexenta server supporting GSSAPI/SPNEGO, I will ask the admin if he would be willing to try it out tomorrow.
Is the next Nexenta server a member of the domain, and is that domain membership under a different name to that which we connect it by?
However, I'm pretty sure the issue is that Jeremy mentioned in comment #1 that the NTLMv2 response has a zero length netbios name in the client challenge component.
(In reply to comment #7)
> Is the next Nexenta server a member of the domain, and is that domain
> membership under a different name to that which we connect it by?
The domain specified in the credentials client is necessary for a successful connection from a Windows 7 client. As to whether or not the Nexenta server is configured as a member of that domain (it would be very silly if it weren't), I'm not sure how to check that.
I read through the thread and am still confused. I this a NexentaStor bug or is it a bug with Samba 3.6.x? If it's a NexentaStor bug I'll submit a bug request to them.