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:

[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).

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
   ---------        -------

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).

Figure 1: Success! The first connection is established.

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.

Figure 2: Two folders set up in the Departments folder: Production and Administration.

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.

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).

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:---
[...]

Figure 3: Rights set in Windows for the Production folder.

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.