Getting Ready for Samba4
Total Page：16
File Type：pdf, Size：1020Kb
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. Andrew Bartlett Thursday, April 3rd, 2008 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 From www.linux-mag.com/id/5596 1 21 December 2008 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, From www.linux-mag.com/id/5596 2 21 December 2008 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 From www.linux-mag.com/id/5596 3 21 December 2008 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).