When Samba 3 was released in 2003, it consisted of three services: the file server smbd, the name server nmbd, and the authentication server winbind. In their interaction with the rest of the system, these three services provided a file service and an NT4 domain controller.

The development of Samba 4 [1] completely changed this structure. Samba 4's support for an Active Directory domain means that it needs to provide a wider range of services: Classic NETBIOS name resolution was superseded by DNS, authentication was centralized using Kerberos, and centralized data storage was implemented via LDAP – only the file server remained the same, with changes to match the new structure.

For the first time, it's now possible to use Samba 4 to map a full Windows domain structure on Linux. The Debian Samba packages offer this possibility and prompt you at install time to decide the role the system will play on your network. I provisioned four systems in the lab: a virtual machine as a domain controller (Debian Jessie [2]), an openATTIC system [3] as a domain member (Debian Jessie), and two Windows clients as domain members (Windows 7/8).

The network filesystem is now more integrated than ever into the domain concept – using it without managing users and permissions in the domain makes little sense. The setup described in this article is thus a basic requirement for using Samba as a shared filesystem in the enterprise.

Domain Controller

The new Samba is a modular system (Listing 1) that lets you outsource various Active Directory-related services; for example, you can replace DNS with bind9 or the directory service with OpenLDAP.

A central service that provides the domain controller (DC) is easy to overlook: A Windows domain handles its complete authentication via Kerberos. Kerberos only works if all systems keep time with a drift of no more than five minutes from one another. It is therefore essential to configure an NTP server to avoid time problems.

The domain controller software installation is easy with apt-get install samba. Debconf pops up during the installation with questions about the server role and the key data of the domain and also handles provisioning automatically. Ideally, you need to do nothing yourself. If anything goes wrong, re-provisioning with samba-tool domain provision is easily possible. The packages also ensure that samba-tool uses the correct values.

Among other files, the provisioning process produces both /etc/krb5.conf and /etc/samba/smb.conf, which looks like Listing 2 when done. This configuration covers everything you need for getting started.

Installing the Domain Member

You need to be aware of a restriction to running a Samba 4 server as a domain member: The samba program does not support operation as a member. This configuration is thus implemented using the known programs smbd, nmbd, and winbind. At this point, remember the NTP client, which definitely needs to be configured up front: If the time is not synchronized, you can't expect a working Samba installation. Furthermore, you need to check whether hostname --fqdn returns the correct, fully qualified name of the computer:

$ hostname --fqdn
benrime.samba.lan

In the lab, I wanted the openATTIC storage server to act as a domain member. To do this, I first installed Debian Wheezy on the computer, then configured openATTIC on the system, and finally upgraded to Debian Jessie. The system is then – as envisaged by the openATTIC standard – added to the domain using the oaconfig domainjoin command. This script executes a series of commands that are described in more detail later and should work on any Linux system.

OpenATTIC first creates the krb5.conf file (this can also be copied from the DC) and the Samba configuration /etc/samba/smb.conf (Listing 3).

Next, openATTIC tests whether Kerberos is working by authenticating as the administrator (Listing 4).

If this step is successful, you can use net ads join -U Administrator to join the domain. The Samba configuration for openATTIC uses an external keytab to enable Kerberos authentication for other services beyond Samba. This is why you need to generate and validate the keytab (Listing 5).

If everything worked out, the domain join is now complete. The remaining task is to configure winbind by modifying the /etc/nsswitch.conf file as follows:

passwd:   compat winbind
group:    compat winbind

After a subsequent reboot of the Winbind server (service winbind restart), the new domain member can access the domain and retrieve users and groups:

root@benrime:~$ getent passwd Administrator
administrator:*:10500:10513:Administrator:/home/SAMBA/administrator:/bin/bash
root@benrime:~$ getent group "Domain Admins"
domain admins:x:10512:test,administrator

This completes the domain join process.

Windows systems join a Samba 4 domain just like a classic Windows Active Directory (Figure 1). To do this, navigate in the system settings to Advanced System Settings | Computer Name | Change, then enter the domain name, answer the prompt for the administrator password, and after a few seconds of waiting and a reboot, you are done joining the domain. Windows automatically updates the NTP client configuration on joining.

Figure 1: With the right configuration, Windows clients can join a Samba 4 domain.

Domain Administration

To manage the shiny, new domain, you can use the classic Windows management tools. These are included as part of any current Windows server operating system but are also available as a retroactively installable package for Windows  7 and Windows 8 clients under the name "Remote Server Administration Tools" [4]. New users can then be created, for example, in Active Directory Users and Computers.

The good old Samba Web Administration Tool, SWAT, unfortunately no longer matches with the Samba 4 concept and died along with Samba 3. Currently, there is no substitute for it, so the only administration tools are those provided by Windows. However, Samba 4 does provide a Python API to simplify the development of such tools.

After creating two users, herbert and otto, I wanted to test whether openATTIC had already met them:

root@benrime:~$ getent passwd herbert
herbert:*:11110:10513::/home/SAMBA/herbert:/bin/bash
root@benrime:~$ getent passwd otto
otto:*:11109:10513::/home/SAMBA/otto:/bin/bash

That is good news. These users can log in on the Windows clients from now on. Next, you can create a volume and a CIFS share on openATTIC. This happens in smb.conf, for example, by adding a new section:

[tank]
   path = /tank
   available = yes
   browseable = yes
   guest ok = no
   writeable = yes

Note that I have not said anything about permissions so far. They are configured completely by the administrator in Windows by opening the share in Windows Explorer and granting permissions. For this to work cleanly, two things are needed: a filesystem with support for extended attributes and the line vfs objects = acl_xattr in the smb.conf file of the storage host.