This problem was originally reported by one of our customers and has been reproduced by Zi Hao Jiang of Sinobot A 2meg good and bad network trace was sent to Jeremy The repro requires the following 1)Samba joined to an AD domain member 2)The User must be an AD user 3)The Windows machine (XP or Vista) the user is attempting to connect to Samba from must ALSO be joined to the AD domain 4)Attempt to connect to the Samba server using its network address (i.e. net use \\1.2.3.4\joe user (to force NTLM authentication) Also confirmed by our customer is setting "client schannel = no" bypasses the problem. Note that there is no problem with NTLM signing unless all of the conditions mentioned above are met. The symptom is that the NTLM authentication works, but samba cannot confirm the signature of the next client packet so it turns off signing and tries to send an unsigned response. The client does not like this and breaks the connection.
A little more research from Zi Hao Tested with samba3.0.33 It don't have this issue. Actually, for 3.0.33, it always use NetrLogonSamLogon (2) , never use NetrLogonSamLogonEx(39), even if I added [client schannel = Yes] in the smb.conf
Do you have a chance to test the patch provided in https://bugzilla.samba.org/show_bug.cgi?id=7568 ? I am convinced it will resolve this issue as well.
Thanks We are in the middle of integrating and testing with Samba 3.5.4. I will have our engineer confirm it is still broken and then get back to you with the results of the patch.
We have confirmed that the patch applied to 3.5.4 fixes the problem. Okay with me to close this bug.
Great! Thanks David for verifying this.