Whether you run Active Directory (AD) with Windows servers or Samba 4 domain controllers, you will always want to provide at least one server for file and print services. If the choice is a Samba server, you have to bring two worlds together. The first step will always be to select and install the distribution; only then can you think about configuring the Samba server. The first part of this article deals with the criteria for choosing a distribution and installing the system safely. The second section then deals with the secure configuration of the Samba service.

A Suitable Distribution

When choosing a distribution, you should consider the following points:

• Which distribution is already used in your company? Don't create a distribution zoo.
• Which distribution do you know best?
• Which distribution offers the right Samba version for you?
• How long will updates be available?

The topic of the Samba version is very important. At the time of testing, Samba versions 4.2 to 4.5 were available directly [1] and from SerNet [2]. (At the time of print, versions 4.6 to 4.8 were available.) If you always want to use the latest version (e.g., the pre-release or release candidate), you can compile Samba yourself. Another important point when choosing the Samba version, and therefore also the distribution, is support from the Samba team.

Every fall and spring a new Samba version is released. Maintenance and updates directly from the Samba team are available for the last three versions; at the time of testing, this meant versions 4.7, 4.6, and 4.5. With all other versions, you are dependent on the publishers of the distributions promptly delivering patches in case of vulnerabilities. Updating can be difficult on NAS boxes, because they are often equipped with very old Samba versions.

To be as up-to-date as possible, in this article, I want to show you the installation and configuration of a Samba file server in an AD domain with Debian Stretch. Except for the basic installation and method of installing packages, you can apply this article to all distributions. I used the network install version of Debian and only installed the default packages and the SSH server. A graphical user interface is not used for security reasons. Later, the system will be managed exclusively via SSH. Before Samba is installed and configured on the system, you will want to deal with system security and pay attention to the following during installation: (1) Partition your system, (2) do not install a GUI, and (3) do not install any services that you do not need on the system.

The first step en route to a secure file server is always partitioning. You should place the following areas in separate partitions:

• /var (read/write)
• /boot (read only)
• /usr (read only)
• / (read/write)
• Directories for your shares (read/write)

Later, the /boot and /usr directories only need to be read/write-mounted when updates are installed. One more tip about the partition on which you will be setting up your shares: If only user data and no executable programs are to be stored there, you can specify the noexec option when mounting. In this case, programs that are stored here cannot be executed. This setting could be important, especially with regard to a vulnerability that was present during testing [3].

After installation, you can connect to the server via SSH. A direct connection as root is not possible; the configuration of SSH prohibits a direct login as root, and you should not change this setting. The su command helps you become root after logging in. A dash after su also gives you the complete environment with all the variables of the root user, because it simulates a complete login process; without the dash, you only change identity.

After the basic installation of the system, you should test which ports are open with the netstat command. If this command is not immediately available, you need to install the net-tools package. Listing 1 shows the netstat output.

root@fs01:~# netstat -tl
Active Internet connections (only servers)
Proto     Recv-Q     Send-Q     Local Address     Foreign Address     State
tcp       0          0          0.0.0.0:ssh       0.0.0.0:*           LISTEN
tcp6      0          0          [::]:ssh          [::]:*              LISTEN

As you can see, only port 22 for SSH is open for incoming connections for both IPv4 and IPv6. If you are not (yet) using IPv6 on your network, you should disable it, because what good is a secured IPv4 connection if access via IPv6 would be possible? To disable IPv6 on a Debian system, create a file called /etc/sysctl.d/01-disable-ipv6.conf containing the line:

net.ipv6.conf.all.disable_ipv6 = 1

At the next restart or after execution of the

sysctl -p /etc/sysctl.d/01-disable-ipv6.conf

command, IPv6 is disabled. If you test the ports again with netstat, you will notice that ssh will still respond to IPv6 requests. If you also want to deactivate this behavior, you need to enter the AddressFamily inet value in the /etc/sshd_config file. After restarting the SSH daemon, only the IPv4 port is now displayed. To test the system from the outside, use nmap:

stefan@stefan-nb ~ % nmap 192.168.56.210
Nmap scan report for 192.168.56.210
Host is up (0.00056s latency).
Not shown: 999 closed ports
PORT STATE SERVICE
22/tcp open ssh

Here, too, port 22 is indicated as open. An additional firewall with iptables would now round off the security concept for the file server, but I will set up the firewall at the very end of the article when I integrate the Samba service into the firewall.

Installing Samba Server

For this article, I use the Debian packages for Samba, which were available in version 4.5.8 at the time of testing. The samba package is responsible for the server service. Because the Samba server will be integrated into an AD later and the users from the AD will have to be "mapped" to the Samba server, I also install winbind . To test the releases locally, I need the smbclients package; thus, I will need the following packages: samba , winbind , smbclients , libpam-winbind , and libnss-winbind .

After the package installation, you should delete the provided /etc/samba/smb.conf file. This configuration is not designed for use as a file server because:

• In the file, Samba is configured as a standalone system, but I want to set up a member server in an AD.
• The file contains shares that I will not be using.
• References are given to parameters that are outdated.
• The smb.conf file should not contain any comments. Each client that connects to the Samba server always starts its own server daemon (smbd) process, so the entire file is always transferred to all connected clients whenever changes are made to smb.conf.

To later manage the Samba server completely from Windows, you want to transfer the configuration to the registry of the Samba server. Then, you can simply manage the server with Regedit, because the configuration is then in a tdb database.

With or Without NetBIOS

Windows supports two different protocols on a server: SMB and NetBIOS. NetBIOS is only used for name resolution. Without the NetBIOS protocol, the server is therefore not visible in the "network environment" of a client. However, because the names are resolved by DNS in AD, NetBIOS is no longer absolutely necessary. That said, any protocol that is present on a server and is not required is always a security issue. Therefore, I want to dispense with NetBIOS completely to remove the associated ports and traffic broadcast to the network.

Depending on your choice of distribution, different SMB versions are available. Starting with Samba v4.2, the highest version of the SMB protocol available is 3.0. On the Windows side, this version is available as of Windows 8. With the release of Samba 4.3, SMB v3.1.1 was introduced for use on Windows 10 and Windows Server 2016 or later. Besides online compression, the new v3.1.1 provides higher encryption of the transmitted data. If your network contains Windows 10 or Windows Server 2016, you should use at least Samba v4.3.