Samba 4 has been under development for 10 years. In that same time, the Samba 3.x series also has seen numerous releases and advancements. This parallel development has led to some confusion over the nature of Samba 4; and, some distributions release both samba3 and samba4 packages that can be installed in parallel, with varying degrees of success.

Samba 4.x [1] is a full replacement and upgrade to Samba 3. Undoubtedly, it will be used in parallel with existing Samba 3.x installations for some time, but not because of any deficiency in Samba 4. In almost all cases, Samba 4 can be a drop-in replacement for maintained Samba 3.x versions and will continue to function and provide the same services. Samba 4 is not the Samba Active Directory Domain Controller; rather, it is a new version of Samba that provides new and improved services. Therefore, I will refer to the current Samba 4.x release throughout this article simply as "Samba." Version numbers will only indicate a version of Samba other than the current release.

Some of this version confusion arises from the long development time required to bring out the new release. Over the years, various directions were taken and emphases made in the project, even including rumors of a potential fork. However, the project settled successfully on a direction and a method for integrating divergent approaches to the many technical problems that needed to be resolved.

In understanding the current structure of the software and the direction the project has taken, it is vital to reference only current material. The use of older documentation or mail list archives, especially those that reference Samba4 "test" and "alpha" releases, is strongly discouraged. Old mail messages and blog posts will mislead you. Configuration directives and command syntaxes have changed significantly during the evolution of the release, so you should expect old documentation to be wrong.

The ability to participate fully in an Active Directory (AD) domain is the elephant in the room and is immediately what many people want to talk about regarding the new Samba; however, AD integration is not the only important enhancement the latest Samba brings to the table. I'll talk about AD functionality in a moment, but I'll mention some other important changes first.

One important change regards the Samba project itself and the workflow used for Samba development. The Samba team's new commit process requires that every commit be reviewed by two developers; once the commit is pushed, the entire test suite is run – on every commit. This process ensures a high quality of code and should catch almost all regressions before they make it into a release. Nearly all commits are also tracked in relation to Bugzilla entries that include regression tests.

First Glance

After installing Samba, the administrator will see a few changes. For traditional domain members, such as file servers, the expected smbd, nmbd, and winbind binaries are present and should continue to be used for those applications.

For servers providing domain control services, Samba runs as a single samba binary. Because samba does not fully support being a domain member, the appropriate daemons, depending on the server's role, must be started. A new samba-tool is the primary means for controlling a Samba server providing domain services. The syntax is very similar to that used by the net command.

The traditional trivial database (TDB) tools, as well as smbcacls, smbclient, rpclient, and other binaries, are still provided as expected, but installing Samba 4.x and Samba 3.x in parallel on a single host can be perilous, as can building Samba yourself on a host that already has Samba 3 installed. If you do a parallel install, be sure to watch your PATH to ensure you are using the intended versions of the tools.

The most basic use of Samba is simply as a file server, in which Samba 4 excels. The internals of the file server are now highly asynchronous, providing higher throughput and improved utilization of server resources. Another file server-related performance enhancement is support for the SMB2.1 and SMB3 protocols. These higher level SMB versions are supported in increasing degrees on Microsoft Vista and greater clients. Higher levels of the SMB protocol provide encryption, symbolic link support, server-side copy, and high-availability features, such as multipath and failover. An SMB3 file server should outperform a lower SMB/CIFS-level file server.

Before moving on to Active Directory support, note that your server should be using a modern filesystem that has good support for extended attributes. If you are using an ext3 or ext4 filesystem on Linux, you should ensure that the filesystem is mounted with the user_xattr,acl,barrier=1 option. If an ext3/4 filesystem is mounted without barrier=1, the TDB databases used by Samba cannot be guaranteed to be consistent in the case of a system crash.

A broken TDB database can mean a corrupted Active Directory domain. If you are stranded on a system without a modern filesystem, the Samba wiki [2] has information on a workaround, but upgrading the host is the preferable option.

Active Directory

Out of the box, Active Directory support works. Creating an Active Directory domain can be performed in a matter of seconds with the use of samba-tool. This interactive way to provision a domain will prompt you for your DNS zone, realm name, and preferred DNS mode (Listing 1). Now when you start samba, you have working Kerberos, DNS, LDAP, and Active Directory.

sudo ./bin/samba-tool domain provision
Realm [EXAMPLE.COM]:
 Domain [EXAMPLE]:
 Server Role (dc, member, standalone) [dc]:
 DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]:
 DNS forwarder IP address (write 'none' to disable forwarding) [192.168.1.46]:
Administrator password:
Retype password:
Looking up IPv4 addresses
....
Fixing provision GUIDs
A Kerberos configuration suitable for Samba 4 has been generated at /opt/s4/private/krb5.conf
Once the above files are installed, your Samba4 server will be ready to use
Server Role:           active directory domain controller
Hostname:              workstation
NetBIOS Domain:        EXAMPLE
DNS Domain:            EXAMPLE.COM
DOMAIN SID:            S-1-5-21-1405516098-4140136852-3456372168

Although this process seems simple, the reality is that Active Directory support is as complicated as Active Directory itself. Before creating a new Samba-powered Active Directory domain, the administrator really needs to learn the basics of Active Directory – a topic far beyond the scope of this article – and integration of the underlying Unix-like operating system with Active Directory domain servers provides yet more complexity. Most importantly, administrators need to understand the following:

• An Active Directory Domain is a DNS domain. The security domain and DNS are inextricably linked in a way that was not true with Windows NT 4.0 (NT4) domains. Changing to or creating an Active Directory domain almost certainly means the architecture of your existing DNS changes.
• An Active Directory domain is a Kerberos domain. One requirement of Kerberos is accurate clock synchronization. Differences between servers or workstations of more that a few minutes from the clock of a domain controller will render services unavailable from that server or to that workstation. For servers, this also means that working Kerberos libraries and utilities must be available and properly configured. The most common problem with Kerberos versions is that Active Directory domain controllers can require encryption hashes that might not be available with older Kerberos clients.
• Active Directory is an LDAP directory service with its own schema and security model.

Active Directory is Active Directory, regardless of whether you are using a Samba domain controller (DC), Windows Server DC, or a mixture of both. Questions on the Samba mail list regarding the use of Samba 4 are frequently just Active Directory questions. You can break a Samba AD domain in all the same ways you can break any AD domain. The Samba wiki provides very good step-by-step instructions on creating an AD DC [3]; you should primarily use that as your documentation. For the remainder of this article, I will focus on some of the various gotchas and information not made obvious on the wiki.

AD Integration

To provide full Active Directory integration, Samba itself must integrate closely with DNS, provide Kerberos domain controller services, and provide an LDAP directory service consistent with that expected by an Active Directory client (Figure 1).

Figure 1: Active Directory is a tightly integrated collection of services.

With previous NT4 domain support, Samba was able to "outsource" many of these functions to existing codebases that provided these services, such as BIND, OpenLDAP, and MIT or Heimdal Kerberos. With the exception of BIND for DNS, the ability to utilize third-party codebases in that role is gone.

A common practice with Samba NT4 domains was to use the ldapsam back end to host the domain's security account manager (SAM) in an OpenLDAP data source adapter (DSA). That ability is gone. The LDAP service used in Samba is now Samba's LDAP service. Sites utilizing OpenLDAP to migrate to Active Directory must migrate at least the SAM to Samba's built-in LDAP server. The same is true if the site uses a standalone MIT or Heimdal key distribution center (KDC) – the KDC function must be migrated to the Samba host. This is no different than if the Active Directory domain controller were a Microsoft Windows server.

It would seem that Samba taking over all these functions is very much contrary to the concept of an open stack or support for standards; it is, and the project acknowledges that. Loss of the ability to use a third-party DSA such as OpenLDAP is regrettable, but providing a reliable and consistent domain model forged of disparate components proved too difficult.

One of the primary goals of this Samba release is to work out of the box, which means Samba must take over all these roles.

The primary advantage of an Active Directory domain is that all the components (e.g., DNS, LDAP, KDC) are integrated and can be scaled up over multiple domain controllers. With the penalty of pushing out the transitional solutions to those network services, Samba now provides those same advantages: tight integration and an agreed-upon schema.

A Samba AD domain controller can peer with other Samba AD domain controllers or with other Windows AD domain controllers. You can bring up a Samba server and promote it to a DC in your existing domain. These domain controllers will replicate the domain information, providing the same level of failover that an all-Windows AD DC domain would provide … or almost. As of v4.0.3, a few small problems have been encountered:

1. A Samba AD domain controller does not replicate completely when paired with a Windows AD read-only domain controller (RODC).

2. DNS information does not replicate reliably between domain controllers when using Samba's built-in DNS server.

3. The sysvol volume, which stores the GPO policies, does not replicate automatically.

4. Privilege delegation and ACLs with LDAP objects did experience difficulties early on, but these issues were resolved in version 4.0.3.

5. In my experience on a Samba AD DC, a script specified using the wins hook parameter, which should work in the same manner as on previous versions, does not appear to be invoked. [Bug 9651]

6. Windows clients complain that they cannot disable offline caching on the profile share [Bug 7810]. (This is a non-critical message and does not affect operation.)

Issues 2 and 3 are the most significant and need to be addressed when utilizing a Samba AD domain controller.