Getting Ready for Samba4

Samba Team member Andrew Bartlett explores the world of Samba4, its development status, what you can (and can't) do with Samba4, and -- most importantly-- when you can expect to start using Samba4 in a production environment.

Ever wanted to run an Active Directory Domain Controller on your Linux server? Did you run a Samba 3.0 DC, but had to move to Active Directory, or worried you might need to? Interested in the leading edge of Samba development, and wondering what the preceding questions mean?

Without Samba, Linux, Windows and Macintosh computers could not share files and printers with each other, and networks of windows computers could only use Microsoft’s products to implement consistent user names and passwords across an organisation, something known as domain control.

Since Samba was last covered by Linux Magazine in 2002, it seems the whole world has changed. Yet for members of the Samba Team the task remains to provide the Free Software community with a solid implementation of the Common Internet File System (CIFS) protocol, and with that a bridge into the Windows world.

It is in that pursuit of interoperability that the Samba Team has continued, soon (at the time of writing) releasing version 3.2.0 of Samba, and alpha releases of Samba4.

But Samba4 is more than just a new version of Samba, and more akin to a new development effort. Largely rewritten to handle the problems of interacting with modern versions of Microsoft’s Windows suite, Samba4 has been a storehouse of testing and innovation. Samba4′s focus on test-driven development has bolstered the Samba Team’s production releases with comprehensive test-suites, and the demonstration and back-porting of new technologies has brought new life to the Samba 3.2 code base.

But it is in the area of Active Directory (AD) support that Samba4 leads the way. Like all versions of Samba since 2.2 Samba4 can be a domain controller (DC), providing the consistent user-names and passwords and profiles across a network, particularly for Windows workstations. This consistency of user-name and password, and the fact that Windows will not re-prompt for that password once’ logged in’ is known as Single Sign On (SSO).

Most importantly, however, and unlike earlier versions of Samba, Samba4 implements the Active Directory protocols that Microsoft’s modern clients such as Windows XP expect. This compatibility is vital, as without Samba4′s AD domain controller support, many organisations have been and would otherwise be forced to run Windows servers.

Samba administrators have long said that support for the native policy mechanism– Group Policy– used by windows clients in Active Directory is their most requested feature.

Good, usable policy mechanisms (the NT4-style system policies supported by previous versions of Samba failed the usable part of this test badly) are vital to a modern enterprise. Specifying everything from mandatory desktop backgrounds and setting intranet home pages, to what applications should be installed on what computers, it can help keep large windows networks under control.

Unfortunately, it is simply not possible to enable Group Policy without implementing all the other Active Directory protocols (client operating systems such as Windows XP trigger on being in an AD domain to download and apply these polices), nor is it possible to administer them without Microsoft’s Active Directory management tools.

Similarly, as corporate and Government security requirements increase, NTLM authentication will be seen as increasingly insecure. Kerberos and the NTLM authentication systems both check usernames and passwords over the network, without exposing them. However Kerberos, as used in Samba4, uses far stronger cryptography, and is an Internet-standard. Originally developed at MIT, Microsoft adapted and extended Kerberos to their needs for Active Directory, and Samba4′s implementation is compatible with both the standard, and Microsoft’s extensions. For many reasons, networks will be far better off when NTLM authentication is finally eliminated.

Kerberos also opens the authentication world to smart-card token based login and genuinely’ strong authentication’, a feature that Samba4 does not currently support, but hopes to provide the groundwork for. To achieve this and more, the Samba Team adapted the Heimdal Kerberos distribution into the Samba4, gaining the knowledge and experience of an established Kerberos implementation. This synergy between Free Software projects also provides a clear strategy for implementing further features, as they can be brought in as Heimdal implements them upstream.

Because Samba4 has such a different, and more complex mission than earlier versions, it no longer supports simple file-based back ends for configuration of users and passwords. Instead, a new file-based database known as’ ldb’ has been developed, with an LDAP-like structure. It allows us to be an LDAP server for AD clients, but also be a strong structure under the rest of Samba4′s operation. To assist administration of Samba4 servers in this more complex environment, Samba4 preconfigures phpLDAPadmin, allowing the use of a graphical LDAP browser to edit the underlying ldb database. For those with the command-line in their blood, any LDAP client, and Samba-provided tools such as ldbsearch, ldbadd, ldbdel and ldbedit will also oblige.

Where is Samba4?

Samba4 is certainly not a drop-in replacement for AD at this stage, nor is it expected to be in the short term, given the massive scope that could imply. Instead, the Samba Team aims to tackle and enable the features Windows clients and network administrators actively use- like Group Policy, machine domain join, user domain logon and the Microsoft Management Console for directory administration. Within this restriction however, Samba4 can take over an AD domain, allowing domain members such as workstations and file-servers to migrate without major disruption (some manual followup required).

However, the single biggest feature that administrators wishing to deploy Samba4 will notice is’ Group Policy’. Group Policies may be stored in Samba4, and modified using Microsoft’s native management tools. Hiding the recycle bin on every computer has never been easier!

Samba4 has also become a basis for other projects to build on. The OpenChange (Microsoft Outlook and Exchange protocol implementation) project uses Samba4 extensively for their support infrastructure.

What About File Services?

Samba’s’ bread and butter’ has for a very long time been the simple but vital business of file and printer sharing. In this area Samba4 has been both ahead and behind. Samba4 includes a very well-tested and extensive implementation of a file server, but lacks much of the integration as a’ domain member server’ (being a server that respects the common set of passwords for a domain) that Samba 3.x possesses. Until that improves (and the team hopes to improve it in the next year), it will see little real world use.

Samba4 has however been the breeding ground for an important technology– clustered Samba, via a project known as CTDB– was first developed in Samba4, and should soon be a standard component of later Samba 3.2 releases. It is also the only Samba version to implement the SMB2 protocol that Microsoft has added to Windows Vista.

Printers are a more tricky question, and for the foreseeable future, the best way to share printers with Samba will be to run Samba 3.2, as this highly complex area has not been reimplemented in Samba4 to date.

The Gotchas

On a more somber note, Samba4 lacks great integration with the POSIX system on which it sits. It cannot map NT ACLs into POSIX ACLs, it requires users and groups to be added to Linux as well as to its internal ldb database.

The future

One of the major areas in which Samba4 is expected to improve is as a file-server. As demand for an SMB2-compatible file server increases, vendor interest in this part of the project will move this code into the mainstream.

Another area of future work is to support an LDAP backend. The use of LDAP as a backend for Samba 3.0 and 3.2 based domains is quite commonplace, and while the requirements around Samba4 are far, far more strict, it is expected that Samba4 will also be able to use an external LDAP server as a data store, hopefully integrated with other services. Documentation for trial implementations of this feature are on the Samba4 wiki.

Trying out Samba4

Samba4 is well and truly ready to be tried out and tested. Tarballs of the Samba4 pre-releases are made available from the samba.org Web site, and instructions are included in the howto.txt.

After building and installing Samba4, it must be configured for use in the local network. This is done by running a provision script– see the instructions in howto.txt in the release. Ensure that when you run the provision that you follow the directions it outputs, as the BIND (DNS nameserver) configuration in particular needs to be installed manually for your system.

Samba4 requires precise configuration of DNS, otherwise its clients (such as WinXP) cannot find or join the domain. Unless you are a DNS guru, it is easiest to manually specify the Samba4 server as the DNS server.

In windows, this can be changed by editing the properties of the network connections from Control Panel. Also, because Kerberos is a time-sensitive authentication protocol, Samba requires clients and servers to be in strict time synchronisation. Set the time by right-clicking on the clock (it is also wise to configure your server to use NTP for its time synchronisation). In the long-term Samba4 will include the NTP integration AD uses to make this seamless.

Samba4 may also require you to open a few more holes in any firewalls being configured on the server. Particularly if experiencing any problems, ensure unfiltered access is permitted between testing clients and Samba4.

One of the great powers of Samba4 is the ability to use the native Microsoft administration tools, such as MMC’s Active Directory Users and Computers. This, however, is not distributed with Samba (as it is Microsoft software), nor with WinXP. You can find adminpak.msi on Windows 2003 Server CDs, in the i386 directory.

The best way to administer Samba4 graphically with free software is phpLDAPAdmin. Conveniently, a configuration file for phpLDAPAdmin is generated when running provision. If Apache, PHP, and phpLDAPAdmin are installed on a modern Linux server, then placing this config.php in /etc/phpldapadmin should be sufficient to configure it. Accessing http:// server /phpldapadmin should bring up the login screen.

Note: One tricky point is the login DN: If your selected realm during the provision is samba.example.com, then to log in as Administrator you must use CN=Administrator,CN=Users,DC=samba,DC=example,DC=com alongside your selected password.

The Samba team hopes to add support for other graphical LDAP editors in the future.

Manual editing of the sam.ldb database with the Samba tools such as ldbedit, ldbadd, ldbdel is also encouraged. Run ldbedit-H /usr/local/samba/private/sam.ldb cn=administrator to edit the administrator’s record in your preferred text editor, or substitute’ cn=administrator’ for any valid LDAP query to edit other records.

What did it take to build Samba4?

Samba4 has been developed by a team of 2-5 developers since early 2003. Working alongside the continuing development of Samba 3.0 and 3.2, Samba4 has made slow but steady progress into areas simply not possible with the older codebase.

Because Samba4 is a largely new codebase, it has allowed the Samba team to take a new approach to development. Rather than a reactionary “application Foo doesn’t work” (where Foo is often something as major as Microsoft Excel!), Samba4 has aimed to be proactive on test-driven development: That is, the Samba Team develops a client library and testsuite (generally part of the smbtorture tool), and extensivly tests every known protocol operation, information level, and flag. Only once they have that tool completed do they proceed to write a server implementation, designed to pass that test. (The Samba4 automated testsuite shows quite a respectable 40% code coverage).

How does the team figure it all out?

Sometimes the protocols we work with are documented, with public specifications, and there are even times when the products we must be compatible with follow those specs. But largely the puzzle of working on Samba is a challenge, famously described by Andrew Tridgell as like learning French, by visiting a French Cafe.

Let me explain: Imagine wanting to learn French, but finding there are no French schools, nor books to learn from, so you visit a French Cafe. Just as the Samba Team listens on network packets, you listen in on the conversation– and try and ask for a coffee. In your many attempts you end up first with odd looks, then with a croissant, and eventually a coffee. Mimicry can go a long way, and soon you are eating well.

But it takes time, particularly to ask for a coffee, with milk and two sugars.

The Samba team doesn’t just listen however– the real trick to learning a language is to see the patterns. What appeared to be a lot of cliche phrases turn into a language with a structure.

It was while developing Samba4 that the team got an excellent opportunity to apply this technique to a new, completely undocumented, protocol: SMB2. SMB2 is a new revision of the core file-sharing protocol that Microsoft first implemented in Windows Vista, and while similar to SMB, it has a new structure, and new features. It is perhaps a bit like knowing French and then learning Dutch.

This slow, learning-by-mimicry is tedious, nothing is nearly as frustrating as not knowing the secret code. The Samba team has in a number of cases had to figure out the’ secret knock’, used to authenticate and secure some network traffic. Often the code is known (being the user’s password), but the team must figure out how to present it– do you knock hard for a dash, and what for a dot? Once these are cryptographically encoded, the only hope is trial and error (and a good knowledge of what has been done before).

Sometimes the team finds real surprise. For example, despite changing everything– even the machines involved in the test, passwords and all other variables, the encryption key remains constant. This is highly unusual for a secure system and the team belives it to be an unexpected mistake in Microsoft’s code. In this case the team had to bring about a brute-force attack on the DES cryptography to find the constant string “SystemLibraryDTC” as a encryption key in certain situations!

When will Samba4 release?

As the team makes each release, the inevitable question is when a final or production release of Samba4 will be made. At this time, no decision has been made, except to call for more testing, from more interested sites.

While the team knows much about the protocols Samba4 implements, much less is know about how administrators want to use Samba4. It is hoped with more use of the alpha series that beta releases, a release with a strong focus on the domain control functionality, can be made in 2008.