Samba has been the subject of many cute descriptions in the past, some of which might have included a dancing penguin carrying a Microsoft Windows logo. We have been guilty of these things ourselves at one time or another. Although these pictures and descriptions can make great opening lines for magazine articles, they don’t have the substance to sell IT shops on the elegance with which this piece of software can solve the very complex interopability problems faced by environments composed of Macintosh, Microsoft, and Unix (or Unix-like) systems. If we had to come up with a one-line executive summary to justify the existence of Samba, we would say, “Samba is a software suite that allows a Unix-based system to appear and function as a Microsoft Windows server when viewed by other systems on a network.”
There are many components to Samba. Each of the pieces operate together to implement both the client and server portion of the Common Internet File System (CIFS) protocol. CIFS is the network protocol used by Microsoft operating systems for remote administration and to access shared resources such as files and printers. Despite the name, CIFS is neither a filesystem nor suitable for the Internet. It is, however, the protocol of choice in Windows networks.
There are several reasons to use Samba instead of Windows Server. As many experienced network administrators can testify, Samba provides day-in and day-out reliability, scalability, and flexibility. In addition, Samba offers freedom in both choice and cost. Samba is freely available from http://www.samba.org under the terms of the GNU General Public License (http://www.fsf.org/licensing/licenses/gpl.html). And because of Samba’s portability, you are free to choose which server platform to use, such as FreeBSD, Linux, Solaris, or OS X.
One of the fascinating things about open source software such as Samba is that it creates a community of people surrounding the project, composed of more than just developers. The community of Samba users varies from IT professionals to teachers, consultants, and dentists. Also, many large companies, such as HP, IBM, Sun, Apple, RedHat, and Novell, distribute and commercially support Samba. If a time arises that you need outside support for your Samba servers, you are free to choose any of these providers for your support.
The remainder of this book is dedicated to helping you use Samba to meet the requirements of your network.
Samba is the brainchild of Andrew Tridgell, who started the project in 1991, while working with a Digital Equipment Corporation (DEC) software suite called Pathworks, created for connecting DEC VAX computers to computers made by other companies. Without knowing the significance of what he was doing, Andrew created a fileserver program for an odd protocol that was part of Pathworks. That protocol later turned out to be the Server Message Block (SMB), the predecessor to CIFS. A few years later, he expanded upon his custom-made SMB server and began distributing it as a free product on the Internet under the name “SMB Server.” However, Andrew couldn’t keep that name—it already belonged to another company’s product—so he tried the following Unix renaming approach:
$ grep -i '^s.*m.*b.*' /usr/dict/words
And the response was:
salmonberry samba sawtimber scramble
Thus, the name “Samba” was born. Today Samba is actively developed by a team of programmers distributed around the world.
One of the best ways to describe Samba is to explain some of the things that it can do. As previously mentioned, Samba implements the CIFS network protocol. By supporting this protocol, Samba enables computers running Unix-based operating systems to communicate with Microsoft Windows and other CIFS-enabled clients and servers. Some examples of common services offered by Samba are:
Share one or more directory trees
Provide a Distributed Filesystem (MS-DFS) namespace
Centrally manage printers, print settings, and their associated drivers for access from Windows clients
Assist clients with network browsing
Authenticate clients logging onto a Windows domain
Provide or assist with Windows Internet Name Service (WINS) name-server resolution
The Samba suite also includes client tools that allow users on a Unix system to access folders and printers that Windows systems and Samba servers offer on the network.
Samba’s current stable release, version 3.0, revolves around three Unix daemons:
- smbd
This daemon handles file and printer sharing and provides authentication and authorization for SMB clients.
- nmbd
This daemon handles Samba’s NetBIOS name registration, implements a Microsoft-compatible NetBIOS Name Server (NBNS) service, also referred to as a WINS server, and participates in browsing elections.
- winbindd
This daemon communicates with domain controllers for providing information such as the groups to which a user belongs. It also provides an interface to Windows’ LanManager authentication schemes, commonly referred to as NTLM authentication, for Unix services other than Samba.
As explained earlier, Samba can help Windows and Unix computers coexist in the same network.[*] However, there are some specific reasons why you might want to set up a Samba server on your network:
You do not need—or wish to pay for—a full-fledged Windows server, yet you need the file and print functionality that one provides.
You want to provide a common area for data or user directories to transition from a Windows server to a Unix one, or vice versa.
You want to share printers among Windows and Unix workstations.
You are supporting a group of computer users who have a mixture of Windows and Unix computers.
You want to integrate Unix and Windows authentication, maintaining a single database of user accounts that works with both systems.
You want to network Unix, Windows, Macintosh (OS X), and other systems using a single protocol.
Let’s take a quick tour of Samba in action. Imagine the following basic network configuration: a Samba-enabled Unix system, to which we will assign the name RAIN, and a pair of Windows clients, to which we will assign the names LETTUCE and TOMATO, all connected via a local area network (LAN). The server RAIN has a local inkjet printer connected to it, inkprint, and a disk share named documents—both of
which it can offer to the other two computers. A graphic of this network is shown in Figure 1-1.
In this network, each computer listed shares the same workgroup. A workgroup is a group name tag that identifies an arbitrary collection of computers and their resources on an SMB/CIFS network. Several workgroups can be on the network at any time, but for our basic network example, we’ll have only one: the GARDEN workgroup.
If everything is properly configured, we should be able to see the Samba server, RAIN, through the My Network Places directory on the Windows desktop, as shown in Figure 1-2. In fact, you should also be able to see each host that belongs to the GARDEN workgroup. Note the Microsoft Windows Network icon in the lefthand toolbar. As we just mentioned, more than one workgroup can exist on a network at any given time. A user who clicks this icon will see a list of all the workgroups that currently exist on the network.
We can take a closer look at the RAIN server by double-clicking its icon. This action causes the client to contact the server and request a list of its shares—the file and printer resources—that the computer provides. In this case, a printer named inkprint and a disk share named documents are on the server, as shown in Figure 1-3. Thanks to Samba, Windows sees the Unix server as a valid CIFS server and clients are able to access the documents folder as if it were just another directory on a local disk. Note that Windows displays the names of machines in mixed case (Rain). Case is irrelevant in NetBIOS and DNS names, so you might see rain, Rain, and RAIN in various displays or command output, but they all refer to a single system.
One popular Windows feature is the capability to map a drive letter (such as H:) to a remote shared directory. To create a path that
points to a remote directory or printer, combine the server (\\RAIN) and share name (documents) to form a Universal Naming Convention (UNC) path
(\\RAIN\documents). There are several methods of creating
such a connection. One that works across almost all Windows operating systems
versions is the net.exe command. The following
command connects the P: drive letter to the
documents share on RAIN:
C:\> net use p: \\rain\documentsOnce this drive mapping is established, applications can access the files in the documents folder across the network as if it were an additional local hard disk mounted at P:\. You can store data on it, install and run programs from it, and even restrict access to prevent unwanted visitors. If you have any applications that support multiuser functionality on a network, you can install those programs on the network drive.[*] Figure 1-4 shows the resulting network drive as it would appear with other storage devices in the Windows XP client. Note the pipeline attachment in the icon for the P: drive; this indicates that it is a network drive rather than a fixed drive.
You probably noticed that the printer inkprint appeared under the available shares for RAIN in Figure 1-3, indicating that the Unix server has a printer that can be accessed by various clients. Data sent to the printer from any of the clients will be spooled on the Unix server and printed in the order in which it is received.
Connecting to a Samba printer from a Windows client is even easier than creating a mapping to a disk share. Windows systems support a system called Point and Print by which clients can automatically download the correct driver for a shared printer, and this system works with Samba shared printers just as easily as with Windows Server shared printers. Merely by double-clicking on the printer, the client downloads the necessary files from the server and creates a usable printer connection. An application can then access the print share using the same mechanisms as it would for a local printer. Figure 1-5 display a printer connection to \\RAIN\inkprint along with a local printer named HP LaserJet. Again, note the pipeline attachment below the printer, which identifies it as being on a network. More information on configuring Samba’s printer and driver management features is provided in Chapter 7.
As mentioned earlier, Samba appears in Unix as a set of daemon programs. You can view them with the Unix ps command, you can read any messages they generate through custom debug files or the Unix syslog service (depending on how Samba is
set up), and you can configure them from a single Samba configuration file: smb.conf. Additionally, if you want to get an idea of what the daemons are doing, Samba has a program called smbstatus, which displays the current state of the server’s open client connections and file locks. Here’s an example that shows that the user lizard has a connection to the documents share from the machine lettuce.
$ smbstatus
Samba version 3.0.22
PID Username Group Machine
-------------------------------------------------------
19889 lizard users lettuce (192.168.1.143)
Service pid machine Connected at
-------------------------------------------------------
documents 19889 lettuce Fri Jun 3 01:34:46 2006
No locked filesModern Microsoft operating systems rely upon a resource-sharing protocol known as CIFS. CIFS provides APIs for manipulating files and for implementing remote administration functionality such as user password changes and printing services.
Microsoft would have you think that this is a new protocol unrelated to its predecessor, the SMB protocol, but CIFS is really just the latest variant in a long line of SMB protocol dialects. It could be argued that it is even just a new name for the latest revision of SMB. Frequently, you will see the terms SMB and CIFS used interchangably or perhaps as a combination (e.g., SMB/CIFS). In other contexts, people use CIFS to refer to the NetBIOS-less incarnation of SMB over TCP/445 implemented by Windows 2000 and later operating systems and SMB to refer to Windows 9x/ME and NT systems. The line is never really clear from the perspective of a developer or a network administrator. For simplicity, this book uses CIFS to refer to the combination of SMB and CIFS operations.
Tip
Microsoft has introduced a new variant of the CIFS protocol, called SMB2, in Windows Vista. The details of this new protocol are still emerging. As always, Samba developers continue working to ensure compatibility with the most recent OS releases from Redmond.
CIFS is a connection-oriented, stateful protocol that relies upon three supporting network services:
A name service
A means of sending datagrams to a single or group of hosts
A means of establishing a long-term connection between a client and server
Both Samba 3.0 and Windows 2000/XP/2003 support using standard IP services to meet these requirements. For example, the Domain Name Service (DNS) translates names to addresses, UDP packets provide the datagram service, and the TCP protocol provides the support needed for CIFS sessions. More on TCP/IP and DNS can be found in TCP/IP Network Administration, by Craig Hunt, and DNS and BIND, by Paul Albitz and Cricket Liu, both published by O’Reilly.
Prior to Windows 2000, Microsoft clients relied upon a layer called NetBIOS to provide this supporting infrastructure. Although modern CIFS clients and servers, including Samba, can function without utilizing NetBIOS services, most usually provide a legacy mode of operation for communicating with older CIFS implementations. Figure 1-6 illustrates the relationship between CIFS, hosts on a network, and core network services. The NetBIOS protocol is generally unfamiliar to Unix sysadmins and therefore deserves a little more attention.
To begin, let’s step back in time. In 1984, IBM authored a simple application programming interface (API) for networking its computers, called the Network Basic Input/Output System (NetBIOS). The NetBIOS API provided a rudimentary design for an application to connect and share data with other computers.
It’s helpful to think of the NetBIOS API as networking extensions to the standard BIOS API calls. The BIOS contains low-level code for performing filesystem operations on the local computer. NetBIOS originally had to exchange instructions with computers across IBM PC or Token Ring networks. It therefore required a low-level transport protocol to carry its requests from one computer to the next.
In late 1985, IBM released one such protocol, which it merged with the NetBIOS API to become the NetBIOS Extended User Interface (NetBEUI). NetBEUI was designed for small LANs, and let each computer claim a name (up to 15 characters in length) that wasn’t already in use on the network. By “small LANs,” we mean those with fewer than 255 nodes on the network—which was considered a generous number in 1985!
The NetBEUI protocol was very popular with networking applications, including those running under Windows for Workgroups. Later, implementations of NetBIOS over Novell’s IPX networking protocols also emerged and competed with NetBEUI. However, the network stack of choice for the burgeoning Internet community was TCP/IP, and implementing the NetBIOS APIs over this protocol suite soon became a necessity.
Recall that TCP/IP uses numbers to represent computer addresses (192.168.220.100, for instance), and that NetBIOS uses only names. This difference was a point of contention when trying to integrate the two protocols together. In 1987, the IETF published standardization documents, titled RFC 1001 and 1002, that outlined how NetBIOS would work over a TCP/IP network. This set of documents still governs each implementation that exists today, including those provided by Microsoft with its Windows operating systems, as well as the Samba suite.
Since then, the standard that this document governs has become known as NetBIOS over TCP/IP, or NBT for short.
The NetBIOS name service solves the name-to-address problem mentioned earlier by allowing each computer to declare a specific name on the network that can be translated to a machine-readable IP address. With the current pervasiveness of TCP/IP networks and DNS, which performs a function identical to the three NetBIOS services, it is understandable why Microsoft choose to migrate away from NetBIOS in newer OS releases.
In the NetBIOS world, when each computer comes online, it attempts to claim a name for itself; this process is called name registration. However, no two computers in the same namespace should be able to claim the same name; this state would cause endless confusion for any computer that wanted to communicate with either of them. There are two different approaches to ensure that this doesn’t happen:
Allow each computer on the network to defend its name in the event that another computer attempts to use it. Names are claimed through broadcast packets on local network segments.
Use a WINS server to keep track of which hosts have registered a NetBIOS name. This approach is required when the hosts exist on different network segments that are not reachable via standard broadcast means.
Figure 1-7 illustrates a (failed) name registration, with and without WINS.
As mentioned earlier, there must be a way to resolve a NetBIOS name to a specific IP address; this process is known as name resolution . There are two different approaches with NBT here as well:
Have each computer report back its IP address when it “hears” a broadcast request for its NetBIOS name.
Use WINS to help resolve NetBIOS names to IP addresses.
Figure 1-8 illustrates the two types of name resolution.
As you might expect, having a WINS server on your network can help out tremendously. To see exactly why, let’s look at the broadcast method.
When a client computer boots, it broadcasts a message declaring that it wishes to register a specified NetBIOS name as its own. If nobody objects to the use of the name, it keeps the name. On the other hand, if another computer on the local subnet is currently using the requested name, it sends a message back to the requesting client that the name is already taken. This is known as defending the name. This type of system comes in handy when one client has unexpectedly dropped off the network—another can take its name unchallenged—but it does incur an inordinate amount of traffic on the network for something as simple as name registration.
With WINS, the same thing occurs, except that the communication is confined to the requesting computer, the defending host, and the WINS server. No broadcasting occurs when the computer wishes to register the name; the registration message is simply sent directly from the client to the WINS server, which asks the defending host whether it wishes to continue to use the name. The WINS server reply to the name registration request is determined by the defending host’s reply. This system is known as point-to-point communication , and it is often beneficial on networks with more than one subnet, because routers are generally configured to block incoming packets that are broadcast to all computers in the subnet.
The same principles apply to name resolution. Without WINS, NetBIOS name resolution would also be done with a broadcast mechanism. All request packets would be sent to each computer in the network, with the hope that one computer that might be affected will respond directly back to the computer that asked. Using WINS and point-to-point communication for this purpose is far less taxing on the network than flooding the network with broadcasts for every name-resolution request.
It can be argued that broadcast packets do not cause significant problems in modern, high-bandwidth networks of hosts with fast CPUs, if only a small number of hosts are on the network, or if the demand for bandwidth is low. There are certainly cases where this argument is correct; however, the assumption does not hold in environments that support more than one broadcast segment connected together by routers. Therefore, the advice throughout this book is to avoid relying on broadcasts as much as possible. This rule is good for large, busy networks, and if you follow this advice when configuring a small network, your network will be able to grow without encountering problems later on that might be difficult to diagnose.
Each computer on an NBT network earns one of the following designations, depending on how it handles name registration and resolution: b-node, p-node, m-node, and h-node. The behaviors of each type of node are summarized in Table 1-1.
Table 1-1. NetBIOS node types
|
Role |
Value |
|---|---|
|
b-node |
Uses broadcast registration and resolution only. |
|
p-node |
Uses point-to-point registration and resolution only. |
|
m-node (mixed) |
Uses broadcast for registration. If successful, it notifies the NBNS of the result. Uses broadcast for resolution; uses the NBNS if broadcast is unsuccessful. |
|
h-node (hybrid) |
Uses the NBNS for registration and resolution; uses broadcast if the NBNS is unresponsive or inoperative. |
Windows clients are usually h-nodes. The first three node types appear in RFC 1001/1002. H-nodes were invented later by Microsoft, as a more fault-tolerant method.
You can find the node type of a Windows 95/98/Me computer by running the winipcfg.exe command from the Start → Run dialog box (or from an MS-DOS prompt) and clicking the More Info button. On operating systems based on Windows NT, such as Windows 2000, Windows XP, and Windows 2003, you can use the ipconfig /all command in a command-prompt window, as shown in the next example. In either case, search for the line that says Node Type.
C:\> ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : lettuce
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : localdomain
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . : localdomain
Description . . . . . . . . . . . : AMD PCNET Family PCI Ethernet Adapter #2
Physical Address. . . . . . . . . : 00-0C-29-82-92-98
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.56.129
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . :
DHCP Server . . . . . . . . . . . : 192.168.56.254
DNS Servers . . . . . . . . . . . : 192.168.56.1
Lease Obtained. . . . . . . . . . : Tuesday, June 07, 2005 10:36:24 AM
Lease Expires . . . . . . . . . . : Tuesday, June 07, 2005 11:06:24 AM
The names that NetBIOS uses are quite different from the DNS hostnames with which you might be familiar. First, NetBIOS names exist in a flat namespace. In other words, there are no hierarchical levels, such as in oreilly.com (two levels) or ftp.samba.org (three levels). NetBIOS names consist of a single unique string such as RAIN or SLEET within each WINS server or broadcast segment. Second, NetBIOS names may be no longer than 15 characters in length and can consist only of standard alphanumeric characters (a–z, A–Z, 0–9) plus the following:
! @ # $ % ^ & ( ) - ' { } . ~Any name with fewer than 15 characters is padded with spaces at the end to reach the 15-character length.
Although you are allowed to use a period (.) in a NetBIOS name, it is a very bad idea. A NetBIOS name containing a period is very hard to distinguish from a valid DNS name. Even worse is something like the valid NetBIOS name 192.168.1.100.
It’s not a coincidence that all valid hostnames are also valid NetBIOS names. In fact, the hostname for a Samba server is often reused as its NetBIOS name. For example, if you had a system with a fully qualified DNS name of sleet.plainjoe.org, its NetBIOS name would default to SLEET (followed by 9 spaces).
With NetBIOS, a computer not only advertises its presence, but also tells others what types of services it offers. For example, SLEET can indicate that it’s not just a workstation, but that it’s also a file server and can receive Windows Messenger messages. This is done by adding a sixteenth byte to the end of the machine name, called the resource type (or resource byte), and registering the name multiple times, once for each service that it offers. See Figure 1-9.
The one-byte resource type indicates a unique service that the named computer provides. In this book, you will often see the resource type shown in angle brackets (<>) after the NetBIOS name, such as SLEET<0x00> or SLEET<00>. Note that Samba documentation and tools often use the hash mark in place of angle brackets (SLEET#00).
It is possible to see which names are registered for a particular NBT computer using the Windows command-line nbtstat utility. Because these services are unique (i.e., there cannot be more than one registered), you will see them listed as type UNIQUE in the output. For example, the following partial output describes the SLEET server:
C:\> nbtstat -a sleetNetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- SLEET <00> UNIQUE Registered SLEET <03> UNIQUE Registered SLEET <20> UNIQUE Registered ...
This output indicates that the server has registered the NetBIOS name SLEET as a machine (computer) name, as a recipient of messages from the Windows Messenger service, and as a file server. Some of the attributes a name can have are listed in Table 1-2.
Table 1-2. NetBIOS unique resource types
|
Named resource |
Hexadecimal byte value |
|---|---|
|
Standard Workstation Service |
00 |
|
Messenger Service |
03 |
|
RAS Server Service |
06 |
|
Domain Master Browser Service (associated with primary domain controller) |
1B |
|
Master Browser name |
1D |
|
NetDDE Service |
1F |
|
Fileserver (including printer server) |
20 |
|
RAS Client Service |
21 |
|
Network Monitor Agent |
BE |
|
Network Monitor Utility |
BF |
NetBIOS also uses the concept of groups with which computers can register themselves. Earlier, we mentioned that the computers in our example belonged to a workgroup, which is a partition of computers on the same network. For example, a business might very easily have an ACCOUNTING and a SALES workgroup, each with different servers and printers. In the Windows world, a workgroup and a NetBIOS group are the same thing.
Continuing our nbtstat example, the SLEET Samba server is also a member of the GARDEN workgroup (the GROUP attribute hex 00) and will participate in elections for the browse master (GROUP attribute 1E). Here is the remainder of the nbtstat output:
NetBIOS Remote Machine Name Table Name Type Status --------------------------------------------- GARDEN <00> GROUP Registered GARDEN <1E> GROUP Registered .._ _MSBROWSE_ _.<01> GROUP Registered
The possible group attributes a computer can have are listed in Table 1-3. An excellent reference to the internals of NetBIOS names and services can be found in Chris Hertel’s book, Implementing CIFS: The Common Internet File System (Prentice Hall), available online at http://www.ubiqx.org/cifs.
The final entry, _ _MSBROWSE_ _, is used to announce a group to other master browsers. The nonprinting characters in the name show up as dots in an nbtstat printout. Don’t worry if you don’t understand all of the resource or group types. Some of them you will not need with Samba, and others you will pick up as you move through the rest of the chapter. The important thing to remember here is the logistics of the naming mechanism.
NBT offers two transport services: the session service and the datagram service. Understanding how these two services work is not essential to using Samba, but it does give you an idea of how NBT works and how to troubleshoot Samba when it doesn’t work.
The datagram service has no stable connection between computers. Packets of data are simply sent or broadcast from one computer to another, without regard to the order in which they arrive at the destination, or even if they arrive at all. The use of datagrams requires less processing overhead than sessions, although the reliability of the connection can suffer. Datagrams, therefore, are used for quickly sending nonvital blocks of data to one or more computers. The datagram service communicates using the simple primitives shown in Table 1-4.
Table 1-4. Datagram primitives
|
Primitive |
Description |
|---|---|
|
Send datagram |
Send datagram packet to computer or groups of computers. |
|
Send Broadcast datagram |
Broadcast datagram to any computer waiting with a Receive Broadcast datagram. |
|
Receive datagram |
Receive a datagram from a computer. |
|
Receive Broadcast datagram |
Wait for a Broadcast datagram. |
The session service is more complex. Sessions are a communication method that can, in theory, detect problematic or inoperable connections between two NetBIOS applications. It helps to think of an NBT session as being similar to a telephone call. Once a connection is made on a session, it remains open throughout the duration of the conversation; each side knows who the caller and the called computer are; and each can communicate using the simple primitives shown in Table 1-5.
Table 1-5. Session primitives
|
Primitive |
Description |
|---|---|
|
Call |
Initiate a session with a computer listening under a specified name. |
|
Listen |
Wait for a call from a known caller or any caller. |
|
Hang-up |
Exit a call. |
|
Send |
Send data to the other computer. |
|
Receive |
Receive data from the other computer. |
|
Session status |
Get information on requested sessions. |
Sessions are the backbone of resource sharing on an NBT network. They are typically used for establishing stable connections from client computers to disk or printer shares on a server. The client “calls” the server and starts trading information such as which files it wishes to open, which data it wishes to exchange, and so on. These calls can last a long time—hours, even days—and all of this occurs within the context of a single connection. If there is an error, the session software (TCP) retransmits until the data is received properly, unlike the “punt-and-pray” approach of the datagram service (UDP).
In truth, although sessions are supposed to handle problematic communications, they sometimes don’t. If the connection is interrupted, session information that is open between the two computers becomes invalid. If this happens, the only way to regain the session information is for the same two computers to call each other again and start over.
If you want more information on each service, the best place to look is RFC 1001/1002. Just make sure to keep these two points in mind:
Sessions are always point-to-point, taking place between two NetBIOS computers. If a session service is interrupted, the client is supposed to store sufficient state information for it to reestablish the connection.
Datagrams can be sent to individual computers or broadcast to multiple computers, but they are unreliable. In other words, there is no way for the source to know that the datagrams it sent have indeed arrived at their destinations.
So, what happens when a user types net use p: \\rain\documents? To simplify the answer, let’s assume the presence of a name service, a datagram service, and a session service, and ignore the details of whether the underlying network uses the NetBIOS interface or TCP/IP. In Chapter 5, we discuss how a CIFS server such as Samba handles operations such as authentication and authorization when connecting to file and printer shares; for now, let’s just assume that these things are working.
Figure 1-10 shows the basic steps that a client will go through in order to access a remote share such as \\RAIN\documents. The diagram assumes that the client, named CATHY, has already resolved the server’s name, SAM, to an IP address using either DNS or the NetBIOS mechanisms discussed earlier. Be aware that the steps to connect to a file or printer share are not always the same, because CIFS supports multiple authentication types and models. For now however, just focus on the scenario of an individual connecting to a share using a login name and password for the session credentials. This is by far the most common and intuitive case.
The first step in establishing the CIFS connection is to negotiate the protocol dialect that the client and server will use. The client transmits a list of dialects that it understands and the server selects the one that it prefers (supposedly the one with the most supported features). Table 1-6 lists the CIFS dialects supported by Samba 3.0.
Tip
Developers plan to enhance the POSIX 2 dialect in a future version of Samba so that the client can take more advantage of the Unix CIFS Extensions for file operations. More details on these extensions are covered in Chapter 11.
Table 1-6. CIFS protocol dialects
|
Protocol name |
smb.conf name |
Example clients |
|---|---|---|
|
NT LANMAN 1.0 NT LM 0.12 POSIX 2 |
NT1 |
Windows 95, NT 4.0, and later smbclient Linux CIFS FS |
|
LANMAN2.1 LM1.2X002 Samba DOS LM1.2X002 |
LANMAN2 | |
|
LANMAN1.0 MICROSOFT NETWORKS 3.0 |
LANMAN1 |
MS DOS network client |
|
MICROSOFT NETWORKS 1.03 |
COREPLUS | |
|
PC NETWORK PROGRAM 1.0 |
CORE |
There are other pieces of information in the server’s Negotiate Protocol (negprot) reply, such as whether the server supports encrypted passwords, what security level is used when connecting to its shares, and whether the server supports Unicode for handling non-ASCII strings.
Once the client and server have agreed upon the dialect to use, the next step in Figure 1-10 is to authenticate the user’s credentials. During this session setup (sesssetup) operation, the login name can be paired with different representations of the user’s proof of identify, such as a clear-text password, the response portion of a challenge/response algorithm, or a Kerberos ticket, depending on the capability bits set in the server’s negprot reply. If the user is successfully authenticated, the server responds by sending the client a session virtual uid or vuid, a 16-bit token that proves the user’s prior authentication. It has no relation to a Unix uid or a Windows SID. If the session is ever broken, the server will have to reauthenticate the user and issue a new vuid before any share connections can be reestablished.
If the session setup step is successful, the client can include the vuid in the tree connection (tcon) request, which is what actually makes the connection to the CIFS share. The server performs any necessary authorization checks by looking up the user’s information, such as group membership, based on the vuid that was previously assigned. If the user has the necessary access rights to connect to the share, the server replies with a tree connection ID (tid).
Now the client is able to open and save files on the share just as if it were a local disk. When issuing the open file call in Figure 1-10, the client sends the previously issued tid to point to the root of the directory tree and the vuid for use in the server’s file authorization checks.
Browsing is the process of finding the other computers and shared resources in the Windows network. Note that this is unrelated to web browsing on the Internet, apart from the general idea of “discovering what’s there.” On the other hand, browsing the Windows network is like the Web in one way: what’s out there can change without warning. Also be aware that browsing is not the same thing as searching Active Directory (AD) for hosts or resources. Although the NetBIOS browse service and AD are each a type of directory service, the implementation details are completely different. The comments in this section apply to browsing NetBIOS networks, not AD.
Before browsing existed, users had to know the name of the computer they wanted to connect to on the network and then manually enter a UNC such as \\rain\documents to an application or file manager to access resources. Browsing is much more convenient, making it possible to examine the contents of a network by using the point-and-click My Network Places GUI interface on a Windows client.[*]
You will encounter two types of browsing in an SMB network:
Let’s look at the first type. On each LAN (or subnet) with a workgroup or domain, one computer has the responsibility of maintaining a list of the computers that are currently accessible through the network. This computer is called the local master browser, and the list it maintains is called the browse list. Computers on a subnet use the browse list to cut down on the amount of network traffic generated while browsing. Instead of each computer dynamically polling to determine a list of the currently available computers, the computer can simply query the local master browser to obtain a complete, up-to-date list.
To browse the resources on a computer, a user must connect to the specific computer; this information cannot be obtained from the browse list. Browsing the list of resources on a computer can be done by double-clicking the computer’s icon when it is presented in My Network Places. As you saw at the opening of the chapter, the computer responds with a list of shared resources that can be accessed after the user is successfully authenticated.
Each server in a Windows workgroup is required to announce its presence to the local master browser after it has registered a NetBIOS name, and (theoretically) announce that it is leaving the workgroup when it is shut down. It is the local master browser’s responsibility to record what the servers have announced.
Tip
The My Network Places application can behave oddly, until you select a particular computer to browse. You might see a list of computers that is not quite up-to-date, including hosts that are not longer on the network or new ones that have not been been noticed yet. Put succinctly, once you’ve selected a server and connected to it, you can be a lot more confident that the shares and printers really exist on the network.
Unlike the roles you’ve seen earlier, almost any Windows system can act as a local master browser. The local subnet can also have one or more backup browsers that will take over in the event that the local master browser fails or becomes inaccessible. The local master browser creates one backup browser for each group of 32 Windows NT based hosts on the subnet,[dagger] or each group of 16 Windows 95/98/ME hosts on the subnet (or a fraction of such a group). To ensure fluid operation, the local backup browsers synchronize their browse list frequently with the local master browser. There is currently no upper limit on the number of backup browsers that can be allocated by the local master browser.
Browsing is a critical aspect of any Windows workgroup. However, this can go wrong on any network. For example, let’s say that a computer running Windows on the desk of a small company’s office manager is the local master browser—that is, until she switches it off to plug in a fax machine. At this point, the Windows XP Workstation in the spare parts department might agree to take over the job. However, that computer is currently running a large, poorly written program that has brought its processor to its knees. The moral: browsing has to be very tolerant of servers coming and going. Because nearly every Windows system can serve as a browser, there has to be a way of deciding at any time who will take on the job. This decision-making process is called an election.
An election algorithm is built into all Windows operating systems so that they can agree who is going to be a local master browser and who will be local backup browsers. An election can be forced at any time. For example, let’s assume that the office manager has finished using the fax machine and reboots her desktop PC. As the server comes online, it announces its presence, and an election takes place to see whether the PC in the spare parts department should still be the master browser.
When an election is performed, each computer broadcasts information about itself via datagrams. This information includes the following:
The version of the election protocol used
The operating system on the computer
The amount of time the client has been on the network
The name of the client
These values determine which operating system has seniority and will fulfill the role of the local master browser. (Chapter 8 describes the election process in more detail.) The architecture developed to achieve this is inelegant, and has no built-in security to prevent rogue machines from taking over. Thus it is possible for any computer running a browser service to register itself as participating in the browsing election and (after winning) being able to change the browse list. Nevertheless, browsing is a key feature in many Windows networks, and backward-compatibility requirements will ensure that it is in use for years to come.
Peer-to-peer networks (not to be confused with P2P file sharing) were originally designed to allow users to share resources from their desktop computer with other users across a network. Network browsing was also originally designed to support this type of ad hoc networking in which no central management of disks or printers was needed. Users could turn their PCs on or off at will without fear of disrupting other users or network services (except those people who were accessing files or printers on the now-offline host).
When a request to access a file share or printer was received, the local computer was responsible for handling the authentication request as part of the connection process. Thus, any user account information or passwords had to be stored on the CIFS “server.” If a user required access to shares on six remote machines, the user had to either remember six passwords or keep her account information synchronized across all six servers. Both solutions faced a scalability issue.
The peer-to-peer networking model of local authentication functions fairly well, as long as the number of computers on the network is small and there is a close-knit community of users. However, in larger networks, the simplicity of workgroups becomes a limiting factor. To support the needs of larger networks, such as those found in departmental computing environments, Microsoft introduced domains with Windows NT 3.51. A Windows NT domain is essentially a browsing group of CIFS-enabled computers with one addition: a server acting as a domain controller (see Figure 1-11).
A domain controller in a Windows domain performs a role similar to a Network Information Service (NIS) server or LDAP directory service in a Unix network, maintaining a domain-wide database of user and group information, as well as performing related services. The responsibilities of a domain controller are mainly related to security, including verifying user credentials (authentication) and granting or denying a user access to the resources of the domain (authorization). These tasks are typically done through the use of a username and password. The service that maintains the database on the domain controllers is called the Security Account Manager (SAM).
The Windows security model revolves around security identifiers (SIDs) and access control lists (ACLs). Security identifiers are used to represent objects in the domain, which include (but are not limited to) users, groups, and computers. SIDs are commonly written in ASCII form as hyphen-separated fields, like this:
S-1-5-21-1638239387-7675610646-9254035128-1000
The part of the SID starting with the “S” and leading up to the rightmost hyphen identifies a domain. The number after the rightmost hyphen is called a relative identifier (RID) and is a unique number within the domain that identifies the user, group, computer, or other object. The RID is the analog of a user ID (uid) or group ID (gid) on a Unix system or within an NIS domain.
Because domains centralize the management of account information, users are now able to use just one login name/password combination. However, the downside of this setup is that if the domain controller is unavailable, servers can no longer authenticate user requests. Therefore, Microsoft developed the concept of multiple domain controllers that maintain duplicate copies of the domain’s SAM. For example, Windows NT domains utilize a primary domain controller (PDC) and one or more backup domain controllers (BDCs). A server in a Windows domain can use the SAM of any PDC or BDC to authenticate a user who attempts to access its resources and log on to the domain. If the PDC fails or becomes inaccessible, its duties can be taken over by one of the BDCs. BDCs frequently synchronize their SAM data with the PDC so that if the need arises, any one of them can immediately begin performing domain-controller services without affecting the clients.
However, note that Windows NT BDCs have read-only copies of the SAM database; they can update their data only by synchronizing with a PDC. In AD domains, all domain controllers (DCs) are considered equal. In order to support legacy clients such as Windows NT, one AD DC is designated as the PDC, but all DCs maintain a modifiable copy of the domain’s authentication database. Changes on one domain controller are propagated to other DCs via a multimaster replication protocol.
Domain trust relationships allow clients within one domain to access the resources within another without having to possess a separate account in the second domain. The user’s credentials are passed from the client system in the first domain to the server in the second domain, which consults a domain controller in its own domain. This DC then contacts a DC in the first (trusted) domain to check whether the user is valid before instructing the server to grant access to the resource.
Samba 3.0 can perform the role of a Windows NT domain controller. It is possible to have a Samba PDC and Samba BDCs in the same domain. Samba can even particpate in trust relationships with other domains. However, at the current time of writing, you cannot mix Windows DCs and Samba DCs in the same domain. This rule may change in a future release. Make sure to check the Samba web site for the latest release and updates.
Samba can also function as a domain member server in either a Windows or Samba controlled domain, meaning that it has a computer account in the DC’s account database and is therefore recognized as being part of the domain. A domain member server does not authenticate users logging on to the domain, but still handles security functions (such as file permissions) for domain users accessing its resources.
Samba 3.0 includes many features designed at better integration with Active Directory domains. Additionally, Samba’s implementation of a Windows NT domain controller has become richer, although it is still missing a few features. Samba developers have also continued to improve functionality introduced in earlier releases, such as printing support for Windows 2000/XP clients, filesystem ACLs, and Winbind.
Samba 3.0 includes support for several newer security additions to the CIFS protocol, such as packet integrity checks known as SMB signing, secure channel communication, and the NTLMv2 authentication algorithm. Thus, it is possible to have a Samba server support domain logons for a network of Windows clients, including the most recent releases from Microsoft. This setup can result in a very stable, high-performance, and more secure network; it also provides the benefit of not having to purchase per-seat Windows Client Acccess Licenses (CALs) from Microsoft. The current release also supports migration of user and group information from a Windows NT 4.0 domain to a Samba domain, so that you are able to continue to upgrade your network without the costs of purchasing Windows 2000 Server or newer in order to use Active Directory.
In addition to the NT4 domain mode security provided by Samba 2.x, 3.0 introduces a new ADS domain mode security that allows a Samba host to join an Active Directory domain and authenticate individual connection requests from clients using Kerberos tickets. The winbindd daemon also supports obtaining user and group information via more effecient LDAP searches instead of Remote Procedure Calls (RPC).
Windows has always supported the concept of adding groups as members of other groups. Current Samba releases also support this capability, by using Winbind to define a group that is local to the server and can contain Windows domain groups. Upon receiving a request for the list of users in the local group, Winbind expands the membership of any nested domain groups that it contains. This feature can be useful, such as when you want to set the group ownership of a file that must be accessible by multiple domain groups. You define on the Samba host a local group that contains all of the appropriate domain groups. Of course, it is possible to perform an equivalent function if the filesystem supports access control lists. However, local groups have the advantage of requiring you to deal with only one group instead of many. More on Winbind’s support for local groups is in Chapter 10.
Unicode is the pervasive means of representing non-English character sets on Windows NT-based computers. The older DOS codepage methods used by Windows 9x and Samba prior to 3.0 could support extended character sets, but not in multiple combinations. You could support English and Spanish clients, but not English, Spanish, and French. The UCS2 encoding represents each character using 16 bits, providing more than enough combinations to handle more languages that any of us have to manage on our network. Building Samba to include Unicode support is covered in Chapter 2.
Libraries knows as passdb modules allow an administrator to choose the persistent storage backend for user and group information. Prior versions of Samba supported this feature in a limited fashion and required the storage interface—for example, a flat text file (smbpasswd) or an LDAP directory service—to be defined at compile time. Samba 3.0 supports multiple passdb backends, which can be defined in its configuration file at runtime. This approach allows for easy migration from one storage format to another and to have one Samba package that supports the needs of multiple installations. Users and groups and how they are stored are discussed in Chapter 5.
Samba’s VFS layer allows programmers to write a plug-in that handles all of the disk I/O operations for a particular share. Good examples of current VFS modules are the network recycle bin, virus scanners, and filesystem snapshot tools. Samba 2.2 only allowed one plugin to be used on given file share at any given time. Samba 3.0 allows multiple VFS modules to be chained together in series so that, for example, you could log when a user deleted a file and move it to a trash can rather than actually removing it. Chapter 6 will explore Samba’s VFS.
Recent releases of Samba introduced the ability to grant certain rights, such as the ability to join Windows clients to a Samba domain, to a nonroot user. Prior versions of Samba required the use of a user account with a uid of 0 (that is, the superuser). Being able to delegate such security-sensitive operations goes a long way when managing Samba domains with multiple administrators. Privileges are discussed in the context of users and groups in Chapter 5.
Samba 2.2 began support for the Windows Point and Print model. Samba 3.0 extends this support, with the latest releases able to back up and restore print queues and drivers in bulk as well as migrate printers from a Windows server to a Samba host using Microsoft’s Print Migrator application. Samba’s printing support and the details of Point and Print are explained in Chapter 7.
Samba 4.0 is an ambitous research project, taken up by Samba developers around the time that Samba 3.0.0 was released (in late 2003), to address a desire for newer features that were believed to be extremely hard to achieve in the Samba 3.0 code base. Examples of these projects of these items include:
Support for non-POSIX filesystems
Full NTFS semantics
Active Directory domain control support
At the time of writing, a proof-of-concept AD implementation has been completed, with the exception of the directory replication protocol.
There has been a great deal of confusion about the relationship between Samba 3.0 and Samba 4. Both source code repositories are part of the Samba project. Samba 3.0 is the current production branch, and Samba 4 is the research branch, which is focused on new functionality that will be integrated into production releases once it has matured.
The current question system administrators ask most often is “When will Samba 4 be released?” In our opinion, it is helpful to view Samba 4 as a blueprint of what project leaders want Samba to be. Of course, blueprints often require a prototype, so developers will release technical previews of the Samba 4 branch from time to time as a way to expose designs to a wider audience. Some prototypes succeed; others are thrown away. At some point, the production releases of Samba will look like the working prototypes. Whether this occurs gradually or all at once is yet to be seen.
Pieces of Samba 4 have already been released as production quality services. For example, the samba4wins project (http://enterprisesamba.org) provides a WINS server that supports the Microsoft WINS replication protocol. Other pieces, such as Samba 4’s memory management library, are shipping in Samba 3.0 today. It’s likely that Samba 4 in whole or in part will continue to coexist with Samba 3.0 for several years to come. No one can accurately predict which release will contain the combined features of Samba 3.0 and technology of Samba 4.
For the latest in development and release news, check the Samba news site (http://news.samba.org), available mailing lists hosted at https://lists.samba.org, and community topics at http://wiki.samba.org.
We’ll wrap up by showing how Samba can currently help out and how it is limited. Table 1-7 summarizes the roles that Samba can and cannot play in a Windows NT or Active Directory domain or a Windows workgroup. The Windows domain protocols are proprietary and have not been documented by Microsoft, and therefore must be analyzed by developers before Samba can support them.
Table 1-7. Samba roles (as of version 3.0.22)
|
Role |
Can perform? |
|---|---|
|
File server |
Yes |
|
Printer server |
Yes |
|
Microsoft DFS server |
Yes |
|
Windows NT 4 domain controller |
Yes |
|
Interact with Windows DCs in the same domain |
No |
|
Active Directory DC |
No |
|
Windows 95/98/Me authentication |
Yes |
|
Windows NT/2000/XP/2003 authentication |
Yes |
|
Local master browser |
Yes |
|
Domain master browser |
Yes |
|
Primary WINS server |
Yes |
|
Secondary WINS server |
No |
As mentioned earlier, Samba actually contains several programs that serve different but related purposes. Here we introduce each of them briefly and describe how they work together. These programs are documented fully in Appendix A.
The majority of the programs that come with Samba center on its three major daemons and one management service application. Let’s take a high-level look at the responsibilities of each:
- nmbd
The nmbd daemon is a simple name server that supplies WINS functionality. This daemon listens for name-server requests and provides the appropriate IP addresses when called upon. It also provides browse lists for the My Network Places application and participates in browsing elections.
- smbd
The smbd daemon manages the shared resources between the Samba server and its clients. It provides file and print services to SMB/CIFS clients across one or more networks and handles all notifications between the Samba server and the network clients. In addition, it is responsible for user authentication, resource locking, and data sharing through the SMB/CIFS protocol.
- swat
The Samba Web Administration Tool (SWAT) is a HTTP-based application for managing Samba. In essence, SWAT offers a graphical interface to functions performed by the included command-line tools.
- winbindd
This daemon is used along with the name service switch to get information on users and groups from a Windows domain controller, and allows Samba to authenticate users from a Windows domain.
The Samba distribution also comes with a small set of Unix command-line tools:
- findsmb
A program that searches the local network for computers that respond to SMB protocol and prints information on them. It is written in Perl and is a good example of how scripts can utilize Samba command-line tools to extend functionality.
- net
This new program distributed with Samba 3.0 can be used to perform remote administration of servers. It also includes some local Samba administration functions.
- nmblookup
This program provides NBT name lookups to translate NetBIOS names to network addresses, and vice versa.
- ntlm_auth
This tool provides a command-line interface to Winbind’s NTLM authentication interface. This tool allows third-party applications such as pppd and the squid web proxy server to support NTLM authentication by leveraging Samba’s existing functionality.
- pdbedit
This tool is the replacement program for many of the functions performed by the smbpasswd utility in previous releases. It is the command-line management tool for user account information stored in a passdb backend.
- rpcclient
This program can be used to run MS-RPC functions on Windows clients. Although it can be useful, it is primarily a developer testing tool, and so has a tendency to change frequently. The net command is promoted as the stable, administrative tool for performing similar functions.
- smbcacls
This program is used to set or show ACLs on Windows NT filesystems.
- smbcquotas
This program is used to set or show filesystem quotas on Windows servers.
- smbclient
This ftp-like Unix client connects to SMB shares and operates on them.
- smbcontrol
This simple administrative utility sends messages to nmbd or smbd.
- smbmnt, smbmount, smbumount, mount.cifs, umount.cifs
These helper utilities for the Linux smbfs and cifs filesystems allow Linux systems to access shares offered over SMB/CIFS.
- smbpasswd
This program allows an administrator to change the passwords used by Samba. It also provides a means for a user to remotely change his password on a SMB/CIFS server.
- smbspool
This print-spooling program is used by the Common Unix Printing System (CUPS) to send files to remote printers that are shared on the SMB network.
- smbstatus
This program reports the current network connections to the shares on a Samba server.
- smbtar
This program, similar to the Unix tar command, backs up data in SMB shares. This is another example of a script written around an existing Samba command-line utility.
- smbtree
This program is similar to the findsmb Perl script, but was written using the libsmbclient library.
- smbget
This utility is the SMB equivalent of the GNU wget utility for retreiving files.
- tdbbackup, tdbdump, tdbtool
These tools manipulate Samba’s trivial database (tdb) files.
- testparm
This simple program checks the Samba configuration file.
- wbinfo
This utility queries the winbindd daemon.
Each major release of Samba goes through an exposure test before it’s announced and is quickly updated afterward if problems or unwanted side effects are found. The latest stable distribution as of this writing is Samba 3.0.22, and this book focuses mainly on the functionality supported in this release, as opposed to older versions of Samba.
Source and binary distributions of Samba are available from mirror sites across the Internet. The primary web site for Samba is located at http://www.samba.org. From there, you can select a mirror site that is geographically near you. Most Linux and many Unix vendors provide binary packages. These can be more convenient to install and maintain than the Samba team’s source or binary packages, due to the vendor’s efforts to supply a package that matches its specific products. The next chapter focuses on all the details necessary to get Samba up and running on your server.
[*] The name Unix will be used throughout this book to mean Unix and Unix-like variants such as BSD, Linux, SysV, and Mac OS X.
[*] Be warned that many end-user license agreements forbid installing a program on a network so that multiple clients can access it. Check the legal agreements that accompany the product to be absolutely sure.
[*] This was originally called Network Neighborhood in Windows 95/98/NT. Microsoft has changed the name to My Network Places in the more recent Windows Me/2000/XP.
[dagger] Windows 2000 and later operating systems are all based on Windows NT technology.
Get Using Samba, 3rd Edition now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
