« Previous 1 2 3 Next »
Protecting Samba file servers in heterogeneous environments
Teamwork
Configuration with smb.conf
The first step is to set up the file server in smb.conf
. In Listing 2, you see the basic configuration without shares. In this article, I will not be discussing the parameters for joining the domain and ID mapping, only the parameters that increase the security of the system:
Listing 2
smb.conf Basic Configuration
[global] workgroup = example realm = EXAMPLE.NET security = ADS winbind enum users = yes winbind enum groups = yes winbind use default domain = yes winbind refresh tickets = yes template shell = /bin/bash idmap config * : range = 10000 - 19999 idmap config EXAMPLE : backend = rid idmap config EXAMPLE : range = 1000000 - 1999999 inherit acls = yes store dos attributes = yes vfs objects = acl_xattr interfaces = 192.168.56.210 bind interfaces only = yes client ipc min protocol = smb2_10 client min protocol = smb2_10 disable netbios = yes
inherit acls = yes
: The assigned access control lists (ACLs) are inherited. This parameter can also be set in the release.store dos attributes = yes
: The extended attributes of a Windows system are also managed. You can also set this parameter in a share.vfs-objects = acl_xattr
: Ensures the Windows-compliant management of permissions in the filesystem. This parameter can also be set directly in the share.interfaces = 192.168.56.210
: Sets the IP address where the service will receive requests. You can enter either the IP address or the device name here.bind interfaces only = yes
: Enables the specification of an interface. If the system is configured with several IP addresses, Samba will bind only to these specific interfaces.client ipc min protocol = smb2_10
: IPC requests are only accepted by systems with at least Windows 7.client min protocol = smb2_10
: Connection requests are only answered by clients from Windows 7.disable netbios = yes
: NetBIOS is not supported. The server no longer appears in the network environment of the clients. However, connections can still be made.
After you have created the smb.conf
file, you must now ensure that the Samba server can also communicate with the domain's Kerberos server. Install the libpam-heimdal
package. You can simply confirm the values that are requested during the installation of the packages with a Return. These values change the /etc/krb5.conf
file. In the next step, you want to create this file with the minimum parameters. After installing the package, create a new /etc/krb5.conf
with the following content:
[libdefaults] default_realm = EXAMPLE.NET dns_lookup_realm = false dns_lookup_kdc = true
After adding the DNS servers of the AD domain to the /etc/resolv.conf
file, you can then join the server to the domain:
root@fs01:~# net ads join -U administrator [...] root@fs01:~# net ads testjoin Join is OK
To test that all services start properly, even after a reboot, reboot the system. Now you have to adjust the /etc/nsswitch.conf
file:
passwd: compat winbind group: compat winbind
Next, test whether the new file server also responds to requests. For this, you use the smbclient
command on the server. The following shows a first attempt at connecting to the server:
root@fs01:~# smbclient -L fs01.example.net Enter root's password: protocol negotiation failed: NT_STATUS_INVALID_PARAMETER_MIX
What happened here? Because you have set the minimum protocol to version 2.1 in the smb.conf
file, smbclient
cannot connect. The connection only works if you use a protocol newer than 2.0 (see Listing 3). This example reveals that there is no master for NetBIOS in the domain – all domain controllers and the file server no longer use NetBIOS. What does the list of ports on the server look like now? To find out, use netstat
again (Listing 4).
Listing 3
Successful Connection
root@fs01:~# smbclient -L fs01.example.net -m SMB3 Enter root's password: Anonymous login successful Sharename Type Comment --------- ---- ------- IPC$ IPC IPC Service (Samba 4.5.8-Debian) Anonymous login successful Server Comment --------- ------- Workgroup Master --------- -------
Listing 4
List of Ports
root@fs01:~# netstat -tln Active Internet Connection (Only Server) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN tcp 0 0 192.168.56.210:445 0.0.0.0:* LISTEN tcp 0 0 192.168.56.210:139 0.0.0.0:* LISTEN
Two ports have been added. One is TCP port 445, which is the port for the SMB connections, and the other is TCP port 139, which provides SMB connections via NetBIOS. However, because NetBIOS has been disabled on the server, you can also disable this port. To do so, add the smb ports = 445
line to smb.conf
in the global area and restart the service. A new test with netstat
then only shows port 445 as open. Testing from the outside with nmap
also shows only two open ports. Running smbclient
will only output an error message that it always connects via NetBIOS.
The First Share
Now comes the point that makes the server usable in the first place: setting up the first share. Here, you want create an administrative Windows share to which only the Domain Admins group has write access, similar to drive shares under Windows. The directories are then made available to the users in this share. You can then assign the directories created there to users in individual shares with group policy objects (GPOs).
The advantage of this approach is that you can assign all permissions directly under Windows and thus have a uniform permissions structure on all servers, whether Windows or Samba servers. The following snippet shows the share from smb.conf
:
[admin] path = /data browsable = no read only = no
As you can see, no parameters for access rights are entered here. All authorizations are assigned from Windows. Now you want to test whether it is possible to create a connection to the share. To do this, log on to a Windows client in the domain and create a network connection (Figure 1).
To be able to create an authorization structure and a new share, you now create the Departments folder under Windows with a Production sub-folder and assign all rights for the domain admins to the Departments folder. On the system are the Production and Administration groups (Figure 2); the directories are now assigned to these groups accordingly.
If you now try to access one of the folders as a domain administrator, you will only see an error message stating that you do not have the required rights. The behavior at this point is therefore identical to that on a Windows server. The rights of the two directories on the file server are shown in Listing 5.
Listing 5
Directory Rights
root@fs01:~# ls -l /data/Departments/ in total 16 drwxrwx---+ 2 administrator domain users 4096 Jun 7 19:14 Production drwxrwx---+ 2 administrator domain users 4096 Jun 7 19:14 Administration
You can see by the +
at the end of the authorizations list that the POSIX ACLs are also set in addition to the filesystem rights. Listing 6 shows the ACLs of the Production
folder and the complexity of the authorization assignment. For this reason, you should always assign authorizations from Windows (Figure 3).
Listing 6
Production Folder ACLs
root@fs01:~# getfacl /data/Departments/Production/ getfacl: Remove leading '/' from absolute path names # file: data/Departments/Production/ # owner: administrator # group: domain\040users user::rwx user:administrator:rwx user:production:rwx group::--- group:domain\040users:--- group:production:rwx mask::rwx other::--- default:user::rwx default:user:administrator:rwx default:user:production:rwx default:group::--- default:group:domain\040users:--- [...]
For users to access their department's folder, you need to set up the appropriate share. It makes sense for only the members of a department to be able see the corresponding department directory; then, you have the option of providing a share to all departments. An employee who changes departments would immediately only have the rights for their new department and would only see the corresponding directory. The following listing shows the entry in smb.conf
for the share:
[Departments] path = /data/Departments browseable = No hide unreadable = Yes read only = No
The browseable = no
parameter means that this share is a hidden share, just like a $
share under Windows. The hide unreadable = yes
parameter ensures that you only see entries for which you have at least read access. Because all employees only have rights to their department's directory, they only see that departmental directory.
Unfortunately, this parameter also has its pitfalls, because the more subdirectories and files you have in the Departments folder, the longer access can take, because the system first needs to check the access rights in all subdirectories. Therefore, test the parameter in detail in your environment before using it.
Converting to the Registry
To manage the system in the registry, and thus also in the Windows registry editor, the conversion from smb.conf
to the registry now follows. The first step is to import the file into the tdb database with the
net conf import /etc/samba/smb.conf
command. The net conf list
command reveals the content of the registry. Now save smb.conf
under a different name and create a new smb.conf
file with the following content:
[global] config backend = registry
After restarting smbd
, you can read the configuration with testparm
. You will see that the registry is now used for configuration. If you start Regedit on a Windows client as a domain administrator, you can connect to the registry of the file server, read and change the settings, create new keys for a new release, or create new values within the existing keys.
« Previous 1 2 3 Next »
Buy this article as PDF
(incl. VAT)