I have recently been digging into the settings of my /etc/samba/smb.conf file, in an effort to tighten up its security.
One fact about Samba which I don’t particularly like, is that too many options are controlled from the client. Thus, on my Samba 3.2 client I had the [Global] option set as a default:
client use spnego = yes
What this did successfully, was secure the way in which the password is authenticated, without exposing it. It causes the server to invoke Kerberos. Additionally, it is possible to set
client NTLMv2 auth = yes
which is default on Samba 4, but which was not set by default on Samba 3 clients. This asks the server for NTLMv2 if available, which is the Windows default for SMB2. It was not set in older Samba clients, to improve compatibility with older SMB shares.
But all that these options allow, is for the initial negotiation to be secured, by which an SMB share is connected. Further, it allows for a possible, later encryption key to be determined in a secure way.
A commonly-known fact about Samba, is that whether the actual exchange of data is encrypted, is determined by default by the client. The actual ‘smbclient’ command-line under Linux accepts the -e flag to do so. And under Windows 7 and 8, the use of 128-bit encryption is default, again set on the client. There are some people who cannot use this, because they are connecting to an older Samba server from Win 7 or 8 as the client, but I like the fact that this is enabled.
Yet, when I connected to my Samba server from a Linux client, not from the command-line, but from within the KDE browser, either ‘Konqueror’ or ‘Dolphin’, these GUI network browsers did not set encryption by default.
Therefore, the possibility still existed that I could be using a Linux client, and not benefiting from encryption in those cases. And so one setting on the server which I found could be helpful, was
smb encrypt = mandatory
This is a [Share] section setting on the server to force encryption, instead of the client deciding. In the case of my Windows clients, this produces no new behavior. But in the case of my Linux (Samba 3) client, it does produce new behavior.
My only personal problem with this setting is, that I don’t know of any Android SMB browsers that support share-level, data encryption. Putting this setting on my server, and then giving the command
smbcontrol smbd reload-config
simply causes all my Android SMB browsers to fail at connecting, apparently. And so one thing I needed to do after all, was to disable this setting, and consciously leave myself open to the possibility, that some of my exchanged data will not be encrypted (especially data exchanged with an Android device).
(Edit : ) I have been trying to obtain some sort of closure on this subject, by putting the configuration lines
smb encrypt = mandatory
guest ok = no
Into the [Homes] section.
However, I found that this does not resolve my issue completely, for three reasons:
1) The [Homes] section works differently from how I had thought. It actually determines which service is being asked for explicitly by the client, and then either clones the section specific to that share, or creates one on-the-fly.
2) Even if I create a different share specifically to have these options, the KDE 3 Konqueror GUI and the KDE 4 Dolphin GUI seem unable to abide by it, while the ‘smbclient’ command-line does so without problems. And so what I’ll need to accept, is that KDE 3/4 Samba browsing will simply need to remain without data encryption…
3) What this option does seems to differ, depending on whether the client is asking for SMB1, SMB2, or SMB3.
With SMB1, a form of encryption is possible, which only exists in the case of Linux, and which is invoked by the ‘smbclient’ command-line as described above.
With SMB2, this feature either seems to be broken or isn’t available.
And with SMB3, this feature actually works. Thus, the only client which seems to be fully compatible with this special share, is my Windows 8.1 laptop.
(Edit 03/15/2016 : ) Due to recent upgrades to the Samba server suite (v
2:4.1.17+dfsg-2+deb8u2 ), I can no longer recommend that older clients bet set to use NTLMv2. On the newer server, this mode only exists to provide compatibility with Windows clients. It only seems to work for me if password encryption is generally required by the server, but if the protocol is left open on the client. That way, a specific negotiation can use ‘Kerberos’ if necessary.