On Tue, Nov 30, 2010 at 9:45 AM, Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > On Tue, Nov 30, 2010 at 7:35 AM, Robbert Kouprie <robbert@xxxxxx> wrote: >> Hi Shirish, >> >> Find attached some detailed problem info and pcaps on the different failing >> scenario's. >> >> Please note our setup is not standard, as we're using a BIND DNS server, and >> we have a mix of 3 DC's where only 2 are DFS root. >> >> Do note however that Windows clients do not have any problem with this >> setup. >> >> If I can be of more help/need to test something, please let me know. >> >> Thanks! >> -- >> Robbert >> >> ---------- Forwarded message ---------- >> Date: Tue, 30 Nov 2010 14:18:37 +0100 (CET) >> From: Robbert Kouprie <robbert@xxxxxx> >> To: Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> >> Cc: linux-cifs@xxxxxxxxxxxxxxx >> Subject: Re: Can't mount Windows DFS root using NTLMv2 >> >> Hi Shirish, >> >> On Mon, 29 Nov 2010, Shirish Pargaonkar wrote: >> >>> Robert, does sec=ntlmssp without dom=sox helps? >>> A wireshark trace when you issue mount command would be useful. >> >> With or wihout dom=sox does not make a difference. >> >> Here is an overview of what I tested: >> >> 2003sp2 2008r2 (+DFS) 2008 (+DFS) >> NTLM (1) OK OK >> NTLMv2 (1) (2) (2) >> NTLMSSP (3) (3) (3) >> >> >> 1 = Fails with "Required key not available" >> 2 = Fails with "NT_STATUS_INVALID_PARAMETER" >> 3 = Fails with "NT_STATUS_NOT_SUPPORTED" >> >> I will send you some detailed logs and pcaps off-list. >> >> Regards, >> Robbert > > This is strange wrt ntlmssp. In negotiate protocol response, server > does state NTLMSSP as one of the mechanism types. > It must be related to bits in flag2 that that client sends in type 1 ntlmssp > session setup that server eitther expects from client but is missing or > does not support/like one of the flags2 bits. > Is 10.0.0.7 a box that runs cifs client? > > ntlmv2 is not going to work as it is against Windows 2008, it will return > invalid parameter error. > Jeff Layton had pointed to this which you can try (I have not tried it yet) > http://support.microsoft.com/kb/957441/en-us > I think more than fields flags and flags2 in the smb header, it could be something to do with flags field in ntlmssp_negotiate (type 1) packet sent by the cifs client to Windows server that server does not support. But then server would return the flags it supports in ntlmssp_challenge (type 2) response instead of returning an error. So it is perhaps something else that is not supported by the server. I just mounted a share using sec=ntlmssp from a Windows 2008 server. The flags field in ntlmssp_negotiate request from client has same exact value that is in the file 3.pcap capture (0xa0000205), entire ntlmssp_negotiate request in both the cases is same yet it fails in your installation and it succeeds at the installation I have. It would be useful to compare with the ntlmssp_negotiate packet that a Windows client sends to this Windows server. And something could be logged in Event Logger on the Windows server. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
