Building Bridges

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.

Permissions

Windows supports a variety of permissions that can be assigned in a granular way for shares and the folders and files they contain (Figure 2), whereas Linux only supports Read, Write, and Execute permissions for the owner, group, and "rest of the world" roles. From the perspective of a Windows admin, that is not proper rights management.

Figure 2: Windows uses a complex, finely granular authorization concept.

Connecting these two worlds therefore is not simple, but it's necessary. If Samba is not the only way to access the data (e.g., local logins or an NFS share on the server), you must make sure that the access rights you set cannot be worked around locally. In other words, it is not enough simply to save the permissions in a database; you also need to include the Linux filesystem.

Early versions of Samba converted the Windows permissions to Linux flags and ignored other access control settings. This solution is obviously unsatisfactory, so the next step is to support POSIX ACLs. This means that there is at least the possibility to assign permissions specifically to individual users (even if they are not the owner) and individual groups (Listing 6).

This approach is a step forward, but unfortunately it is not yet sufficient: Windows supports not only read, write, execute, but also unusual permissions such as "delete subfolders and files, but not the folder itself."

These permissions cannot currently be mapped on the filesystem in Linux. Nevertheless, it is important to keep and implement them in the Windows world at least. To do this, Samba uses advanced file attributes, which allow arbitrary variables to be associated with a file in certain namespaces (Listing 7).

Extended attributes therefore offer the possibility of storing arbitrary metadata for a file. Samba (or more precisely, the vfs_acl_xattr module) now leverages these capabilities to save permissions that cannot otherwise be mapped:

$ getfattr -n security.NTACL /tank/herbert/
# file: tank/herbert/
security.NTACL=0sAwADAAAAAgAEAAI...

A minor issue exists here, however: Not all filesystems support these mechanisms; in particular, ZFS on Linux does not support them. On Solaris and FreeBSD, the vfs_zfsacl module provides a remedy, but it does not exist on Linux.

You can work around this with the vfs_acl_tdb module, which stores the permissions in a database file. This module also provides an option for modifying the POSIX ACLs; thus, given a careful configuration, no problems are to be expected in the event of third-party access. However, this solution does not scale as well as the use of extended attributes, because database access can quickly become a bottleneck. Furthermore, snapshots, high availability, and failover are not so easy to implement. If you need features such as those offered by ZFS, you should consider using Btrfs.

Feature Matrix

The selection of the filesystem on the storage server has an additional effect on the functions that a file server can offer its users, beyond support for ACLs. Which of these factors is relevant in practice, of course, always depends on the corporation and the type of data stored. Other interesting functions include:

• Quotas: The filesystem lets you set size limits for directories for individual users and groups.
• Filesystem shrink: The filesystem can shrink as well as grow. If you miscalculated when setting up storage, this provides an easy fix without having to move the data.
• Compression: The filesystem supports compression of data before it's stored and can thus use the available space more effectively.
• Deduplication: The filesystem detects duplicate data blocks and stores them once only, and so use the available space more efficiently.
• Snapshots: The filesystem supports the ability to create subvolumes and snapshots. In this way, the entire directory tree or subtree can be frozen in a matter of seconds so that its state no longer changes.
• Redundancy: The filesystem itself offers the possibility of redundant data storage so that the failure of a hard disk can be compensated for in a way that is invisible to the user. There is no need to resort to RAID.
• Distributed: Distributed and cluster filesystems like OCFS2 or Ceph offer different ways to look at storage on multiple hosts as a single large storage area. Data is stored redundantly and distributed on these hosts to compensate for the failure of individual hosts in a way that is transparent to the user.

An overview of the back-end filesystems used for Samba in these contexts is provided in Table 1. Giving a general recommendation for or against an individual filesystem does not make sense, because it is driven by the intended use and the expected growth of data.