How-to: Enable Encrypted Communication for Samba

Howto Enable Encrypted Communication for Samba

For security reasons you want Clients to communicate encrypted with the UCS Samba Server.

Step 1

Set Samba configuration option through ucr command line tool

root@master:~# ucr set samba/global/options/smb\ encrypt=required
Create samba/global/options/smb encrypt
Script: /etc/univention/templates/scripts/samba.local.config.py
Multifile: /etc/samba/smb.conf

Step 2

Restart Samba

root@master:~# /etc/init.d/samba restart

Environment

As a background for these settings the information from the man page of smb.conf:

smb encrypt (S)

This parameter controls whether a remote client is allowed or required to use SMB encryption. It has different effects depending on whether the connection uses SMB1 or SMB2 and newer:

If the connection uses SMB1, then this option controls the use of a Samba-specific extension to the SMB protocol introduced in Samba 3.2 that makes use of the Unix extensions.

If the connection uses SMB2 or newer, then this option controls the use of the SMB-level encryption that is supported in SMB version 3.0 and above and available in Windows 8 and newer.

This parameter can be set globally and on a per-share bases. Possible values are off (or disabled), enabled (or auto, or if_required), desired, and required (or mandatory). A special value is default which is the implicit default setting of enabled.

Effects for SMB1

The Samba-specific encryption of SMB1 connections is an extension to the SMB protocol negotiated as part of the UNIX extensions. SMB encryption uses the GSSAPI (SSPI on Windows) ability to encrypt and sign every request/response in a SMB protocol stream. When enabled it provides a secure method of SMB/CIFS communication, similar to an ssh protected session, but using SMB/CIFS authentication to negotiate encryption and signing keys. Currently this is only supported smbclient of by Samba 3.2 and newer, and hopefully soon Linux CIFSFS and MacOS/X clients. Windows clients do not support this feature.

This may be set on a per-share basis, but clients may chose to encrypt the entire session, not just traffic to a specific share. If this is set to mandatory then all traffic to a share must be encrypted once the connection has been made to the share. The server would return “access denied” to all non-encrypted requests on such a share. Selecting encrypted traffic reduces throughput as smaller packet sizes must be used (no huge UNIX style read/writes allowed) as well as the overhead of encrypting and signing all the data.

If SMB encryption is selected, Windows style SMB signing (see the server signing option) is no longer necessary, as the GSSAPI flags use select both signing and sealing of the data.

When set to auto or default, SMB encryption is offered, but not enforced. When set to mandatory, SMB encryption is required and if set to disabled, SMB encryption can not be negotiated.
Effects for SMB2

Native SMB transport encryption is available in SMB version 3.0 or newer. It is only offered by Samba if server max protocol is set to SMB3 or newer. Clients supporting this type of encryption include Windows 8 and newer, Windows server 2012 and newer, and smbclient of Samba 4.1 and newer.

The protocol implementation offers various options:

The capability to perform SMB encryption can be negotiated during protocol negotiation.

Data encryption can be enabled globally. In that case, an encryption-capable connection will have all traffic in all its sessions encrypted. In particular all share connections will be encrypted.

Data encryption can also be enabled per share if not enabled globally. For an encryption-capable connection, all connections to an encryption-enabled share will be encrypted.

Encryption can be enforced. This means that session setups will be denied on non-encryption-capable connections if data encryption has been enabled globally. And tree connections will be denied for non-encryption capable connections to shares with data encryption enabled.

These features can be controlled with settings of smb encrypt as follows:

Leaving it as default, explicitly setting default, or setting it to enabled globally will enable negotiation of encryption but will not turn on data encryption globally or per share.

Setting it to desired globally will enable negotiation and will turn on data encryption on sessions and share connections for those clients that support it.

Setting it to required globally will enable negotiation and turn on data encryption on sessions and share connections. Clients that do not support encryption will be denied access to the server.

Setting it to off globally will completely disable the encryption feature for all connections. Setting smb encrypt = required for individual shares (while it’s globally off) will deny access to this shares for all clients.

Setting it to desired on a share will turn on data encryption for this share for clients that support encryption if negotiation has been enabled globally.

Setting it to required on a share will enforce data encryption for this share if negotiation has been enabled globally. I.e. clients that do not support encryption will be denied access to the share.

Note that this allows per-share enforcing to be controlled in Samba differently from Windows: In Windows, RejectUnencryptedAccess is a global setting, and if it is set, all shares with data encryption turned on are automatically enforcing encryption. In order to achieve the same effect in Samba, one has to globally set smb encrypt to enabled, and then set all shares that should be encrypted to required. Additionally, it is possible in Samba to have some shares with encryption required and some other shares with encryption only desired, which is not possible in Windows.

Setting it to off or enabled for a share has no effect.

Default: smb encrypt = default

Mastodon