The option "smb encryption=mandatory" is supposed to force all clients to use transmission encryption e.g. "smbclient -e" Per definition clients without this option are refused. This works well for SMB1. When SMB2 is enabled the option "smb encryption=mandatory" is ignored for clients connection via SMB2. A client using "mount -t cifs -o vers=2.0 ..." can connect and perform unencrypted transmissions My guess about this bug: If SMB encryption is selected, Windows style SMB signing is not required , as the GSSAPI flags use select both signing and sealing of the data. But for the SMB2 protocol, by design, signing cannot be disabled. This should not matter but it is probably where the bug is, practically breaking the encryption implementation
3.6.x only supports up to SMB2, not SMB3. Transport level encryption is only supported in SMB3. To get encryption support you need 4.0.x and above. Connecting with SMB2 and having "smb encrypt = required" should fail all connections immediately in 3.6.x, as it's incapable of supporting it. Probably we should issue a debug level zero log warning if "smb encrypt = required" is set and a client connects with smb2, as well as failing the connection. Jeremy.
Created attachment 9241 [details] git-am fix for 3.6.next. Can you test this please - works for me here. Once you confirm it fixes the bug for you we'll get in integrated into the next 3.6.x release. Thanks, Jeremy.
Karolin, Metze +1 reviewed. Please apply to 3.6.next. Thanks ! Jeremy.
Does not work as expected: with smb encrypt=mandatory mount -t cifs -o vers=2.0,user=username,password=password //server/share /mountpoint mount: block device //server/share is write-protected, mounting read-only mount: cannot mount block device //server/share read-only why this message? And with server signing = mandatory I also get mount: block device //server/share is write-protected, mounting read-only mount: cannot mount block device //server/share read-only which should work, right?
You get the first message as we're returning NT_STATUS_ACCESS_DENIED to the client, so he thinks it's read-only, so he tries to remount with read-only, but gets the same error. So fails with the message you see. As for the second problem, does the SMB2 Linux kernel client support SMB2 signing yet ? I don't think it does. In which case you get exactly the same messages back when the signature fails on the SMB2_TCON. Patch is still good I think. Jeremy.
Ok I'm not sure whether I applied everything correctly. Sorry if I'm wasting your time Here's the deal: when "smb encrypt = mandatory" is applied no connection works. not with mount -t cifs -o vers=2.0 ... (which does work without the patch) nor with smbclient -L //server/share -U username -e which gives me: Encryption required and setup failed with error NT_STATUS_NO_SUCH_USER without "smb encrypt = mandatory" and without "server signing = mandatory" everything works fine here are my actions in detail: my version is 3.6.18 on Debian testing (Jessie) got the debian source, compiled after patch and installed, run smbd and nmbd manually. commands: apt-get source samba cd samba-3.6.18/source3 nano smbd/smb2_tcon.c (adding) /* Don't allow connection if encryption is required. */ if (lp_smb_encrypt(snum) == Required) { DEBUG(0,("Connection refused on share %s as encryption is" " required on this share and SMB2 does not support" " this.\n", lp_servicename(snum))); return NT_STATUS_ACCESS_DENIED; } ./configure make make install /usr/local/samba/sbin/nmbd /usr/local/samba/sbin/smbd
No you're not wasting my time - far from it ! I have tested locally with 3.6.x smbclient, and with "smb encrypt=mandatory" I can successfully connect to a share with SMB1 using: /usr/local/samba3.6/bin/smbclient //127.0.0.1/tmp -Ujuser%password -e Once you have selected SMB2 from the CIFS client you should *NOT* be able to connect to a share with "smb encrypt=mandatory" set, as the CIFS SMB client doesn't support SMB3 or SMB3 encryption yet. Again, I can connect correctly with "server signing = mandatory" from smbclient over SMB1. The patch correctly denies SMB2 access to unencrypted access to the share when "smb encrypt=mandatory" is set, but has no other effect on SMB1 connections. Jeremy.
I'm sure something is wrong with my compiled samba, I will figure this out and report later
samba 4.0.9 does not need this fix. smb2 connections are refused when smb encrypt = mandatory on samba 4.0.9
Successfully tested the patch using samba 3.6.6 (debian stable/wheezy) It seems only samba <= 3.6.x needs the patch, as 4.0.x seems to have fixed this already.
Yes, this is a 3.6.x-only bug. Jeremy.
(In reply to comment #11) > Yes, this is a 3.6.x-only bug. > > Jeremy. Pushed to v3-6-test. Will be included in Samba 3.6.20. Closing out bug report. Thanks!