samba - Jan 2017 - Win 10 cannot connect with (some variations of) 'smb encrypt = desired'

Hi all,

There are some surprises when trying to connect Windows 10 (up to date 
circa Dec 2016) to Samba (4.5.2) with 'smb encrypt = desired' as a 
config option.

I've made a grid of some of the combinations 'smb encrypt = desired'
settings below.

The biggest surprise is that if 'smb encrypt = desired' is set globally 
and in the share, Windows 10 cannot connect at all, but if 'smb encrypt 
= required' globally then Windows 10 can connect.

"Connecting" was tested by first logging out of Windows, restarting
the
smbd daemon, logging in to Windows, opening Explorer, and typing the URL 
(UNC?) into the address bar.  No credentials were saved in Credential 
Manager.

browse - specify hostname, but not share name - \\smb.physics.wisc.edu
select - browse shares as above, then select the share name in Explorer
direct - specify hostname and sharename - \\smb.physics.wisc.edu\smb

G - global
S - per share
                                     browse | select | direct
smb encrypt (no G, no S) = ''       Y      | Y      | Y
smb encrypt (G, no S)    = required Y[0]   | Y      | Y
smb encrypt (no G, S)    = desired  Y[4]   | N[1]   | Y
smb encrypt (G and S)    = desired  N[3]   | N/A    | N[2]
smb encrypt (G, no S)    = desired  N[3]   | N/A    | N[2]

- Shouldn't the last two combos create the same final connection as a 
global 'smb encrypt = required'?

[0] Successful login needed before shares are visible.
[1] Error message is "multiple connections to a server or a shared 
resource by the same user, using more than one user name, are not 
allowed.  Disconnect all [...]"
[2] Error message is "The specified server connot perform the requested 
operation"
[3] Error message is "Check the spelling of the name.  Otherwise there 
might be a problem with your network."
[4] Browsing shares connection not encrypted.  When trying to enter a 
share, possibly Samba/Windows tries to create an encrypted connection 
leading to [1]. If it is not possible to renegotiate encryption, then 
the unencrypted connection should be used instead (remember that 'smb 
encryption = desired').

Below is testparm output (for the smb encrypt (no Global, only per 
share) = desired case):
[global]
	realm = PHYSICS.WISC.EDU
	server string = %h server
	workgroup = PHYSICS
	max log size = 100000
	syslog = 0
	panic action = /usr/share/samba/panic-action %d
	kerberos method = secrets and keytab
	map to guest = Bad User
	security = ADS
	server signing = required
	hostname lookups = Yes
	dns proxy = No
	idmap config * : backend = tdb
[smb]
	path = /srv/smb
	inherit acls = Yes
	inherit permissions = Yes
	read only = No
	smb encrypt = desired
	vfs objects = btrfs streams_xattr


Thanks for your insights!
Chad

On Fri, Dec 23, 2016 at 02:21:16PM -0600, Chad William Seys via samba
wrote:
> Hi all,
> 
> There are some surprises when trying to connect Windows 10 (up to date
circa
> Dec 2016) to Samba (4.5.2) with 'smb encrypt = desired' as a config
option.
> 
> I've made a grid of some of the combinations 'smb encrypt =
desired'
> settings below.
> 
> The biggest surprise is that if 'smb encrypt = desired' is set
globally and
> in the share, Windows 10 cannot connect at all, but if 'smb encrypt
> required' globally then Windows 10 can connect.
> 
> "Connecting" was tested by first logging out of Windows,
restarting the smbd
> daemon, logging in to Windows, opening Explorer, and typing the URL (UNC?)
> into the address bar.  No credentials were saved in Credential Manager.
> 
> browse - specify hostname, but not share name - \\smb.physics.wisc.edu
> select - browse shares as above, then select the share name in Explorer
> direct - specify hostname and sharename - \\smb.physics.wisc.edu\smb
> 
> G - global
> S - per share
>                                     browse | select | direct
> smb encrypt (no G, no S) = ''       Y      | Y      | Y
> smb encrypt (G, no S)    = required Y[0]   | Y      | Y
> smb encrypt (no G, S)    = desired  Y[4]   | N[1]   | Y
> smb encrypt (G and S)    = desired  N[3]   | N/A    | N[2]
> smb encrypt (G, no S)    = desired  N[3]   | N/A    | N[2]
> 
> - Shouldn't the last two combos create the same final connection as a
global
> 'smb encrypt = required'?
> 
> [0] Successful login needed before shares are visible.
> [1] Error message is "multiple connections to a server or a shared
resource
> by the same user, using more than one user name, are not allowed.
> Disconnect all [...]"
> [2] Error message is "The specified server connot perform the
requested
> operation"
> [3] Error message is "Check the spelling of the name.  Otherwise there
might
> be a problem with your network."
> [4] Browsing shares connection not encrypted.  When trying to enter a
share,
> possibly Samba/Windows tries to create an encrypted connection leading to
> [1]. If it is not possible to renegotiate encryption, then the unencrypted
> connection should be used instead (remember that 'smb encryption >
desired').
hm, this sounds different then
<https://bugzilla.samba.org/show_bug.cgi?id=12520>

but can you please test with the patch proposed here:
<https://lists.samba.org/archive/samba-technical/2017-January/118225.html>

Cheerio!
-slow

Hi,

 > hm, this sounds different then
 > <https://bugzilla.samba.org/show_bug.cgi?id=12520>
 >
 > but can you please test with the patch proposed here:
 > 
<https://lists.samba.org/archive/samba-technical/2017-January/118225.html>

Definitely seems to be in the ballpark.  But I'm a little busy at the 
moment to try this.  I'll follow the bug so I'll know if it makes it 
into a packaged Samba before I get a chance to patch it myself.

Thanks for the heads up!
Chad.

On Fri, Dec 23, 2016 at 02:21:16PM -0600, Chad William Seys via samba
wrote:
> There are some surprises when trying to connect Windows 10 (up to date
circa
> Dec 2016) to Samba (4.5.2) with 'smb encrypt = desired' as a config
option.
> 
> ...
>
>                                     browse | select | direct
> smb encrypt (no G, no S) = ''       Y      | Y      | Y
> smb encrypt (G, no S)    = required Y[0]   | Y      | Y
> smb encrypt (no G, S)    = desired  Y[4]   | N[1]   | Y
> smb encrypt (G and S)    = desired  N[3]   | N/A    | N[2]
> smb encrypt (G, no S)    = desired  N[3]   | N/A    | N[2]
can't reproduce this. These are my findings:

                                    browse | select | direct
smb encrypt (no G, no S) = ''       Y      | Y      | Y
smb encrypt (G, no S)    = required Y      | Y      | Y
smb encrypt (no G, S)    = desired  Y      | Y      | Y
smb encrypt (G and S)    = desired  Y      | Y      | Y
smb encrypt (G, no S)    = desired  Y      | Y      | Y

This is with a Windows 10 client and Samba git master, but without the patch I
mentioned. I don't think there are differences in the code between master
and
4.5.2 that could come into play here.

After every test I closed all Explorer windows, restarted Samba and checked with
smbstatus that there was no active session before running the next test.

I didn't restart the Windows client which I would have done if I got
unexecpted
results, but as the above results matched my expectations I ommitted this step.

Cheerio!
-slow

I did one test and was able to reproduce a line again with a freshly 
booted (and long time off) Win 10 client:

                                     browse | select | direct
smb encrypt (no G, S)    = desired  Y[4]   | N[1]   | Y

Did you authenticate by kerberos?  That seems to be the most likely 
difference (but maybe not most likely cause).

Thanks for looking into it!
C.