If encryption is disabled globally, per definition we shouldn't allow enabling encryption on individual shares and given a config [Global] smb encrypt = off [share] smb encrypt = required we must deny access to "share" with access denied. Current behaviour doesn't get this right for the SMB 3.1.1 case with a negprot encryption context exchange and allows Windows 10 Client encrypted access to "share". Additionally, a config [Global] smb encrypt = off [share] smb encrypt = desired must result in an unencrypted tcon to "share" because encryption if off globally, but with current code we set the "encryption required" flag on the share and again allow encrypted access for any client that can deal with the strange combination of a server that says "I don't support encryption" (in negprot) but sets the encryption required flag for the share. Patch to follow...
Created attachment 12880 [details] Patch for 4.4 cherry-picked from master
Created attachment 12881 [details] Patch for 4.5 cherry-picked from master
Created attachment 12882 [details] Patch for 4.6 cherry-picked from master
Reassigning to Karolin for inclusion in 4.6.next, 4.5.next, 4.4.next.
(In reply to Jeremy Allison from comment #4) Pushed to autobuild-v4-{6,5,4}-test.
(In reply to Karolin Seeger from comment #5) Pushed to all branches. Closing out bug report. Thanks!