On Tue, Nov 30, 2010 at 10:38 AM, Shirish Pargaonkar <shirishpargaonkar@xxxxxxxxx> wrote: > 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. > security blob in ntlmssp negotiate request between what cifs client sends and what Windows client sends is little different. cifs client does not encode OIDs for SPNEGO and NTLMSSP mech type in the request. That could be a cause of error at the setup you have but at the setup I have, Windows 2008 server seems to be OK with it. I can make that change, encode them using asn.1 and see if that helps. But meanwhile if even logger is flagging anything, that would be useful to know. -- 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
