I have posted a question on the list first, see <https://lists.samba.org/archive/samba/2013-December/177436.html> but did not get any reply yet. So I am opening a bug report for tracking as I feel it's not configuration issue but real bug. I try to track down an issue with Windows 8 authenticating to Samba 3.6.22. Today I faced a strange issue that I could not connect to my server using hostname but I could perfectly do so using IP-address. - \\skynet\share did not work ("The parameter is invalid") - \\10.0.1.6\share did work After lots of searching and trying I was mainly concerned about the following error logged over and over again: [2013/12/16 02:23:13.573666, 1] libsmb/ntlmssp.c:255(ntlmssp_update) Failed to parse NTLMSSP packet, could not extract NTLMSSP command After increasing log level I found this logged: [2013/12/16 02:23:13.573666, 1] libsmb/ntlmssp.c:255(ntlmssp_update) Failed to parse NTLMSSP packet, could not extract NTLMSSP command [2013/12/16 02:23:13.573752, 2] ../lib/util/util.c:415(dump_data) [0000] 4E 45 47 4F 45 58 54 53 00 00 00 00 00 00 00 00 NEGOEXTS ........ [0010] 60 00 00 00 70 00 00 00 A4 74 53 78 31 35 3C 8A `...p... .tSx15<. [0020] 91 CA D7 F8 94 25 93 AD FE 7B A9 BC 4D D7 4F 12 .....%.. .{..M.O. [0030] 80 DB 24 92 6D EF E1 8F 64 D0 8D 1E 49 C6 D2 36 ..$.m... d...I..6 [0040] BC 43 8C 01 BF 21 B5 1A 00 00 00 00 00 00 00 00 .C...!.. ........ [0050] 60 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 `....... ........ [0060] 5C 33 53 0D EA F9 0D 4D B2 EC 4A E3 78 6E C3 08 \3S....M ..J.xn.. [0070] 4E 45 47 4F 45 58 54 53 02 00 00 00 01 00 00 00 NEGOEXTS ........ [0080] 40 00 00 00 C5 00 00 00 A4 74 53 78 31 35 3C 8A @....... .tSx15<. [0090] 91 CA D7 F8 94 25 93 AD 5C 33 53 0D EA F9 0D 4D .....%.. \3S....M [00A0] B2 EC 4A E3 78 6E C3 08 40 00 00 00 85 00 00 00 ..J.xn.. @....... [00B0] 30 81 82 A0 54 30 52 30 27 80 25 30 23 31 21 30 0...T0R0 '.%0#1!0 [00C0] 1F 06 03 55 04 03 13 18 54 6F 6B 65 6E 20 53 69 ...U.... Token Si [00D0] 67 6E 69 6E 67 20 50 75 62 6C 69 63 20 4B 65 79 gning Pu blic Key [00E0] 30 27 80 25 30 23 31 21 30 1F 06 03 55 04 03 13 0'.%0#1! 0...U... [00F0] 18 54 6F 6B 65 6E 20 53 69 67 6E 69 6E 67 20 50 .Token S igning P [0100] 75 62 6C 69 63 20 4B 65 79 A1 2A 30 28 A0 11 1B ublic Ke y.*0(... [0110] 0F 57 45 4C 4C 4B 4E 4F 57 4E 3A 50 4B 55 32 55 .WELLKNO WN:PKU2U [0120] A1 13 30 11 A0 03 02 01 80 A1 0A 30 08 1B 06 73 ..0..... ...0...s [0130] 6B 79 6E 65 74 kynet Looking for similar issues with NEGOEXTS dumps I found bug 7577 (<https://bugzilla.samba.org/show_bug.cgi?id=7577>). Which was supposed to be fixed since version 3.5.4 and therefore should be fixed in my 3.6.22 too. I have also scanned the discussion about Live Sign-In issues on the list: <https://lists.samba.org/archive/samba-technical/2010-July/072321.html> After having read this I have disconnected my Microsoft Account from my Windows profile and suddenly my shares now work as expected. Though I cannot use the Windows Store any more on Windows 8 then. Can anybody confirm that this (or similar parsing issue) returned in Windows 8(.1) now? I am running Samba 3.6.22 as a domain controller for Windows 8.1 Professional 64-bit as a trial right now. Also roaming profiles occasionally report "The parameter is invalid" on profile synchronization which might be related to the same issue as I was used to connect my user profiles to a Microsoft account.
reproduced with 3.6.24 in different way 1. turn on Windows UAC (if you ever turned if off) 2. open the samba mount (let's say \\share\abc) in windows using normal user before UAC (medium integrity) correctly 3. then open something like regedit to elevate to high integrity (confirm the UAC dialog), use file import/export dialog in regedit to get a open file (actually an explorer), open exactly the same UNC path \\share\abc Failed to parse NTLMSSP packet shown in samba log, while error like failed to open dialog shown in client side if you do step 3 before 2 before connection is made (e.g.: after restarting samba), you get same result in medium integrity. only 1 of medium/high integrity connects fine, not both
(In reply to Xuefer from comment #1) Our NTLMSSP handling has improved a lot since 3.6, this should work in current releases