Chapter 1. Learning the Samba

Samba is an extremely useful networking tool for anyone who has both Windows and Unix systems on his network. Running on a Unix system, it allows Windows to share files and printers on the Unix host, and it also allows Unix users to access resources shared by Windows systems.

Although it might seem natural to use a Windows server to serve files and printers to a network containing Windows clients, there are good reasons for preferring a Samba server for this duty. Samba is reliable software that runs on reliable Unix operating systems, resulting in fewer problems and a low cost of maintenance. Samba also offers better performance under heavy loads, outperforming Windows 2000 Server by a factor of 2 to 1 on identical PC hardware, according to published third-party benchmarks. When common, inexpensive PC hardware fails to meet the demands of a huge client load, the Samba server can easily be moved to a proprietary "big iron" Unix mainframe, which can outperform Windows running on a PC many times. If all that weren't enough, Samba has a very nice cost advantage: it's free. Not only is the software itself freely available, but also no client licenses are required, and it runs on high-quality, free operating systems such as Linux and FreeBSD.

After reading the previous paragraph, you might come to the conclusion that Samba is commonly used by large organizations with thousands of users on their networks—and you'd be right! But Samba's user base includes organizations all over the planet, of all types and sizes: from international corporations, to medium and small businesses, to individuals who run Samba on their Linux laptops. In the last case, a tool such as VMware is used to run Windows on the same computer, with Samba enabling the two operating systems to share files.

The types of users vary even more—Samba is used by corporations, banks and other financial institutions, government and military organizations, schools, public libraries, art galleries, families, and even authors! This book was developed on a Linux system running VMware and Windows 2000, with Adobe FrameMaker running on Windows and the document files served by Samba from the Linux filesystem.

Does all this whet your technological appetite? If so, we encourage you to keep reading, learn about Samba, and follow our examples to set up a Samba server of your own. In this and upcoming chapters, we will tell you exactly how to get started.

What Is Samba?

Samba is a suite of Unix applications that speak the Server Message Block (SMB) protocol. Microsoft Windows operating systems and the OS/2 operating system use SMB to perform client-server networking for file and printer sharing and associated operations. By supporting this protocol, Samba enables computers running Unix to get in on the action, communicating with the same networking protocol as Microsoft Windows and appearing as another Windows system on the network from the perspective of a Windows client. A Samba server offers the following services:

Share one or more directory trees
Share one or more Distributed filesystem (Dfs) trees
Share printers installed on the server among Windows clients on the network
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 is the brainchild of Andrew Tridgell, who currently heads the Samba development team. Andrew 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 file-server program for an odd protocol that was part of Pathworks. That protocol later turned out to be SMB. A few years later, he expanded upon his custom-made SMB server and began distributing it as a 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, the Samba suite revolves around a pair of Unix daemons that provide shared resources—called shares or services—to SMB clients on the network. These are:

smbd: A daemon that handles file and printer sharing and provides authentication and authorization for SMB clients.
nmbd: A daemon that supports NetBIOS Name Service and WINS, which is Microsoft's implementation of a NetBIOS Name Server (NBNS). It also assists with network browsing.

Samba is currently maintained and extended by a group of volunteers under the active supervision of Andrew Tridgell. Like the Linux operating system, Samba is distributed as open source software (http://opensource.org) by its authors and is distributed under the GNU General Public License (GPL). Since its inception, development of Samba has been sponsored in part by the Australian National University, where Andrew Tridgell earned his Ph.D. Since then, many other organizations have sponsored Samba developers, including LinuxCare, VA Linux Systems, Hewlett-Packard, and IBM. It is a true testament to Samba that both commercial and noncommercial entities are prepared to spend money to support an open source effort.

Microsoft has also contributed by offering its definition of the SMB protocol to the Internet Engineering Task Force (IETF) in 1996 as the Common Internet File System (CIFS). Although we prefer to use the term "SMB" in this book, you will also often find the protocol being referred to as "CIFS." This is especially true on Microsoft's web site.

What Can Samba Do for Me?

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 don't want to pay for—or can't afford—a full-fledged Windows server, yet you still need the functionality that one provides.
The Client Access Licenses (CALs) that Microsoft requires for each Windows client to access a Windows server are unaffordable.
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. Assume that we have the following basic network configuration: a Samba-enabled Unix system, to which we will assign the name toltec, and a pair of Windows clients, to which we will assign the names maya and aztec, all connected via a local area network (LAN). Let's also assume that toltec also has a local inkjet printer connected to it, lp, and a disk share named spirit—both of which it can offer to the other two computers. A graphic of this network is shown in Figure 1-1.

Figure 1-1. A simple network set up with a Samba server

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 network. Several workgroups can be on the network at any time, but for our basic network example, we'll have only one: the METRAN workgroup.

Sharing a Disk Service

If everything is properly configured, we should be able to see the Samba server, toltec, through the Network Neighborhood of the maya Windows desktop. In fact, Figure 1-2 shows the Network Neighborhood of the maya computer, including toltec and each computer that resides in the METRAN workgroup. Note the Entire Network icon at the top of the list. As we just mentioned, more than one workgroup can be on an SMB network at any given time. If a user clicks the Entire Network icon, she will see a list of all the workgroups that currently exist on the network.

Figure 1-2. The Network Neighborhood directory

We can take a closer look at the toltec server by double-clicking its icon. This contacts toltec itself and requests a list of its shares—the file and printer resources—that the computer provides. In this case, a printer named lp, a home directory named jay, and a disk share named spirit are on the server, as shown in Figure 1-3. Note that the Windows display shows hostnames in mixed case (Toltec). Case is irrelevant in hostnames, so you might see toltec, Toltec, and TOLTEC in various displays or command output, but they all refer to a single system. Thanks to Samba, Windows 98 sees the Unix server as a valid SMB server and can access the spirit folder as if it were just another system folder.

Figure 1-3. Shares available on the Toltec server as viewed from maya

One popular Windows feature is the ability to map a drive letter (such as E:, F:, or Z:) to a shared directory on the network using the Map Network Drive option in Windows Explorer.[1] Once you do so, your applications can access the folder across the network using the drive letter. You can store data on it, install and run programs from it, and even password-protect it against unwanted visitors. See Figure 1-4 for an example of mapping a drive letter to a network directory.

Figure 1-4. Mapping a network drive to a Windows drive letter

Take a look at the Path: entry in the dialog box of Figure 1-4. An equivalent way to represent a directory on a network computer is by using two backslashes, followed by the name of the networked computer, another backslash, and the networked directory of the computer, as shown here:

\\network-computer\directory

This is known as the Universal Naming Convention (UNC) in the Windows world. For example, the dialog box in Figure 1-4 represents the network directory on the toltec server as:

\\toltec\spirit

If this looks somewhat familiar to you, you're probably thinking of uniform resource locators (URLs), which are addresses that web browsers such as Netscape Navigator and Internet Explorer use to resolve systems across the Internet. Be sure not to confuse the two: URLs such as http://www.oreilly.com use forward slashes instead of backslashes, and they precede the initial slashes with the data transfer protocol (i.e., ftp, http) and a colon (:). In reality, URLs and UNCs are two completely separate things, although sometimes you can specify an SMB share using a URL rather than a UNC. As a URL, the \\toltec\spirit share would be specified as smb://toltec/spirit.

Once the network drive is set up, Windows and its programs behave as if the networked directory were a local disk. If you have any applications that support multiuser functionality on a network, you can install those programs on the network drive.[2] Figure 1-5 shows the resulting network drive as it would appear with other storage devices in the Windows 98 client. Note the pipeline attachment in the icon for the J: drive; this indicates that it is a network drive rather than a fixed drive.

Figure 1-5. The Network directory mapped to the client drive letter J

My Network Places, found in Windows Me, 2000, and XP, works differently from Network Neighborhood. It is necessary to click a few more icons, but eventually we can get to the view of the toltec server as shown in Figure 1-6. This is from a Windows 2000 system. Setting up the network drive using the Map Network Drive option in Windows 2000 works similarly to other Windows versions.

Figure 1-6. Shares available on Toltec (viewed from dine)

Sharing a Printer

You probably noticed that the printer lp appeared under the available shares for toltec in Figure 1-3. This indicates that the Unix server has a printer that can be shared by the various SMB clients in the workgroup. 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.

Setting up a Samba-enabled printer on the Windows side is even easier than setting up a disk share. By double-clicking the printer and identifying the manufacturer and model, you can install a driver for this printer on the Windows client. Windows can then properly format any information sent to the network printer and access it as if it were a local printer. On Windows 98, double-clicking the Printers icon in the Control Panel opens the Printers window shown in Figure 1-7. Again, note the pipeline attachment below the printer, which identifies it as being on a network.

Figure 1-7. A network printer available on Toltec

Seeing things from the Unix side

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 (depending on how Samba is set up); and you can configure them from a single Samba configuration file: smb.conf. In addition, if you want to get an idea of what the daemons are doing, Samba has a program called smbstatus that will lay it all on the line. Here is how it works:

# smbstatus
Processing section "[homes]"
Processing section "[printers]"
Processing section "[spirit]"

Samba version 2.2.6
Service     uid    gid    pid     machine
-----------------------------------------
spirit      jay    jay    7735    maya     (172.16.1.6) Sun Aug 12 12:17:14 2002
spirit      jay    jay    7779    aztec    (172.16.1.2) Sun Aug 12 12:49:11 2002
jay         jay    jay    7735    maya     (172.16.1.6) Sun Aug 12 12:56:19 2002

Locked files:
Pid    DenyMode   R/W        Oplock     Name
--------------------------------------------------
7735   DENY_WRITE RDONLY     NONE       /u/RegClean.exe   Sun Aug 12 13:01:22 2002

Share mode memory usage (bytes):
   1048368(99%) free + 136(0%) used + 72(0%) overhead = 1048576(100%) total

The Samba status from this output provides three sets of data, each divided into separate sections. The first section tells which systems have connected to the Samba server, identifying each client by its machine name (maya and aztec) and IP (Internet Protocol) address. The second section reports the name and status of the files that are currently in use on a share on the server, including the read/write status and any locks on the files. Finally, Samba reports the amount of memory it has currently allocated to the shares that it administers, including the amount actively used by the shares plus additional overhead. (Note that this is not the same as the total amount of memory that the smbd or nmbd processes are using.)

Don't worry if you don't understand these statistics; they will become easier to understand as you move through the book.

Getting Familiar with an SMB Network

Now that you have had a brief tour of Samba, let's take some time to get familiar with Samba's adopted environment: an SMB network. Networking with SMB is significantly different from working with common TCP/IP protocols such as FTP and Telnet because there are several new concepts to learn and a lot of information to cover. First, we will discuss the basic concepts behind an SMB network, followed by some Microsoft implementations of it, and finally we will show you where a Samba server can and cannot fit into the picture.

Understanding NetBIOS

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 it let each computer claim a name (up to 15 characters) that wasn't already in use on the network. By a "small LAN," we mean 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, which competed with NetBEUI. However, the networking protocols of choice for the burgeoning Internet community were TCP/IP and UDP/IP, and implementing the NetBIOS APIs over those protocols soon became a necessity.

Recall that TCP/IP uses numbers to represent computer addresses (192.168.220.100, for instance) while NetBIOS uses only names. This was a major issue when trying to mesh 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/UDP 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.[3]

The NBT standard (RFC 1001/1002) currently outlines a trio of services on a network:

A name service
Two communication services:
- Datagrams
- Sessions

The name service solves the name-to-address problem mentioned earlier; it allows each computer to declare a specific name on the network that can be translated to a machine-readable IP address, much like today's Domain Name System (DNS) on the Internet. The datagram and session services are both secondary communication protocols used to transmit data back and forth from NetBIOS computers across the network.

Getting a Name

In the NetBIOS world, when each computer comes online, it wants to claim a name for itself; this is called name registration. However, no two computers in the same workgroup should be able to claim the same name; this would cause endless confusion for any computer that wanted to communicate with either of them. There are two different approaches to ensuring that this doesn't happen:

Use an NBNS to keep track of which hosts have registered a NetBIOS name.
Allow each computer on the network to defend its name in the event that another computer attempts to use it.

Figure 1-8 illustrates a (failed) name registration, with and without an NBNS.

Figure 1-8. Broadcast versus NBNS name registration

As mentioned earlier, there must be a way to resolve a NetBIOS name to a specific IP address; this 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 an NBNS to help resolve NetBIOS names to IP addresses.

Figure 1-9 illustrates the two types of name resolution.

Figure 1-9. Broadcast versus NBNS name resolution

As you might expect, having an NBNS on your network can help out tremendously. To see exactly why, let's look at the broadcast method.

Here, when a client computer boots, it will broadcast 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 will send a message back to the requesting client that the name is already taken. This is known as defending the hostname. 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 an NBNS, the same thing occurs, except the communication is confined to the requesting computer and the NBNS. No broadcasting occurs when the computer wishes to register the name; the registration message is simply sent directly from the client to the NBNS, and the NBNS replies regardless of whether the name is already taken. This is known as point-to-point communication, and it is often beneficial on networks with more than one subnet. This is 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 an NBNS, 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 an NBNS 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 the demand for bandwidth is low. There are certainly cases where this is true; however, our advice throughout this book is to avoid relying on broadcasts as much as possible. This is a good rule to follow for large, busy networks, and if you follow our advice when configuring a small network, your network will be able to grow without encountering problems later on that might be difficult to diagnose.

Node Types

How can you tell what strategy each client on your network will use when performing name registration and resolution? 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.

In the case of Windows clients, you will usually find them listed as h-nodes or hybrid nodes. The first three node types appear in RFC 1001/1002, and 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 command from the Start → Run dialog (or from an MS-DOS prompt) and clicking the More Info>> button. On Windows NT/2000/XP, you can use the ipconfig /all command in a command-prompt window. In either case, search for the line that says Node Type.

What's in a Name?

The names NetBIOS uses are quite different from the DNS hostnames you might be familiar with. 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 navaho or hopi within each workgroup or domain. Second, NetBIOS names are allowed to be only 15 characters and can consist only of standard alphanumeric characters (a-z, A-Z, 0-9) and the following:

! @ # $ % ^ & ( ) - ' { } . ~

Although you are allowed to use a period (.) in a NetBIOS name, we recommend against it because those names are not guaranteed to work in future versions of NBT.

It's not a coincidence that all valid DNS names are also valid NetBIOS names. In fact, the unqualified DNS name for a Samba server is often reused as its NetBIOS name. For example, if you had a system with a hostname of mixtec.ora.com , its NetBIOS name would likely be MIXTEC (followed by 9 spaces).

Resource names and types

With NetBIOS, a computer not only advertises its presence, but also tells others what types of services it offers. For example, mixtec 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 16th byte to the end of the machine (resource) name, called the resource type, and registering the name multiple times, once for each service that it offers. See Figure 1-10.

Figure 1-10. The structure of NetBIOS names

The 1-byte resource type indicates a unique service that the named computer provides. In this book, you will often see the resource type shown in angled brackets (<>) after the NetBIOS name, such as:

MIXTEC<00>

You can 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 toltec server:

C:\>nbtstat -a toltec

       NetBIOS Remote Machine Name Table
   Name               Type         Status
---------------------------------------------
TOLTEC          <00>  UNIQUE      Registered
TOLTEC          <03>  UNIQUE      Registered
TOLTEC          <20>  UNIQUE      Registered
...

This says the server has registered the NetBIOS name toltec as a machine (computer) name, as a recipient of messages from the Windows Messenger service, and as a file server. Some possible 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

Group names and types

SMB 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 an SMB group are the same thing.

Continuing our nbtstat example, the toltec Samba server is also a member of the METRAN 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
---------------------------------------------
METRAN         <00>   GROUP       Registered
METRAN         <1E>   GROUP       Registered
..__MSBROWSE__.<01>   GROUP       Registered

The possible group attributes a computer can have are illustrated in Table 1-3. More information is available in Windows NT in a Nutshell by Eric Pearce, also published by O'Reilly.

Table 1-3. NetBIOS group resource types

Named resource	Hexadecimal byte value
Standard Workstation group	00
Logon server	1C
Master Browser name	1D
Normal Group name (used in browser elections)	1E
Internet Group name (administrative)	20
`<01><02>_ _MSBROWSE_ _<02>`	01

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.

Scope ID

In the dark ages of SMB networking before NetBIOS groups were introduced, you could use a very primitive method to isolate groups of computers from the rest of the network. Each SMB packet contains a field called the scope ID, with the idea being that systems on the network could be configured to accept only packets with a scope ID matching that of their configuration. This feature was hardly ever used and unfortunately lingers in modern implementations. Some of the utilities included in the Samba distribution allow the scope ID to be set. Setting the scope ID in a network is likely to cause problems, and we are mentioning scope ID only so that you will not be confused by it when you later encounter it in various places.

Datagrams and Sessions

At this point, let's digress to discuss the responsibility of NBT: to provide connection services between two NetBIOS computers. NBT offers two 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, in theory, offers the ability to detect problematic or inoperable connections between two NetBIOS applications. It helps to think of an NBT session as being similar to a telephone call, an analogy that obviously influenced the design of the CIFS standard.

Once the connection is made, it remains open throughout the duration of the conversation, each side knows who the caller and the called computer are, and each can communicate with 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, etc. 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) will retransmit until the data is received properly, unlike the "punt-and-pray" approach of the datagram service (UDP).

In truth, while 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 might become invalid. If that 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, we recommend you look at RFC 1001. However, there are two important things to remember here:

Sessions always occur 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. However, in practice, this often does not happen.
Datagrams can be 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.

An Introduction to the SMB Protocol

Now we're going to cover some low-level technical details and explore the elementals of the SMB protocol. You probably don't need to know much about this to implement a simple Samba network, and therefore you might want to skip or skim over this section and go on to the next one ("Windows Workgroups and Domains") on your first reading. However, assuming you are going to be responsible for long-term maintenance of a Samba network, it will help if you understand how it actually works. You will more easily be able to diagnose and correct any odd problems that pop up.

At a high level, the SMB protocol suite is relatively simple. It includes commands for all the file and print operations that you might perform on a local disk or printer, such as:

Opening and closing files
Creating and deleting files and directories
Reading and writing files
Searching for files
Queueing and dequeueing files in a print spool

Each operation can be encoded into an SMB message and transmitted to and from a server. The original name "SMB" comes from the way in which the commands are formatted: they are versions of the standard DOS system-call data structures, or Server Message Blocks, redesigned for transmitting to another computer across a network.

SMB Format

Richard Sharpe of the Samba team defines SMB as a request-response protocol.[4] In effect, this means that a client sends an SMB request to a server and the server sends an SMB response back to the client. In only one rare circumstance does a server send a message that is not in response to a client.

An SMB message is not as complex as you might think. Let's take a closer look at the internal structure of such a message. It can be broken down into two parts: the header, which is a fixed size, and the command string, whose size can vary dramatically based on the contents of the message.

SMB header format

Table 1-6 shows the format of an SMB header. The COM field identifies the command being performed. SMB commands are not required to use all the fields in the SMB header. For example, when a client first attempts to connect to a server, it does not yet have a tree identifier (TID) value—one is assigned after it successfully connects—so a null TID is placed in its header field. Other fields can be padded with zeros when not used.

The SMB header fields are listed in Table 1-6.

Table 1-6. SMB header fields

Field	Size (bytes)	Description
`0xFF 'SMB`'	`1`	Protocol identifier
`COM`	`1`	Command code, from 0x00 to 0xFF
`RCLS`	`1`	Error class
`REH`	`1`	Reserved
`ERR`	`2`	Error code
`REB`	`1`	Reserved
`RES`	`14`	Reserved
`TID`	`2`	TID; a unique ID for a resource in use by the client
`PID`	`2`	Caller process ID
`UID`	`2`	User identifier
`MID`	`2`	Multiplex identifier; used to route requests inside a process

SMB command format

Immediately after the header is a variable number of bytes that constitute an SMB command or reply. Each command, such as Open File (COM field identifier: SMBopen) or Get Print Queue (SMBsplretq ), has its own set of parameters and data. Like the SMB header fields, not all of the command fields need to be filled, depending on the specific command. For example, the Get Server Attributes (SMBdskattr) command sets the WCT and BCC fields to zero. The fields of the command segment are shown in Table 1-7.

Table 1-7. SMB command contents

Field	Size (bytes)	Description
`WCT`	`1`	Word count
`VWV`	Variable	Parameter words (size given by WCT)
`BCC`	`2`	Parameter byte count
`DATA`	Variable	Data (size given by BCC)

Don't worry if you don't understand each field; they are not necessary for using Samba at an administrator level. However, they do come in handy when debugging system messages. We will show you some of the more common SMB messages that clients and servers send using a modified version of tcpdump later in this section. (If you prefer an SMB sniffer with a graphical interface, try Ethereal, which uses the GTK libraries; see http://www.ethereal.com for more information on this tool.)

TIP

For more information on each command in the SMB protocol, see the CIFS Technical Reference at http://www.snia.org/tech_activities/CIFS.

SMB variations

The SMB protocol has been extended with new commands several times since its inception. Each new version is backward-compatible with the previous versions, so it is possible for a LAN to have clients and servers concurrently running different versions of the SMB protocol.

Table 1-8 outlines the major versions of the SMB protocol. Within each "dialect" of SMB are many sub-versions that include commands supporting particular releases of major operating systems. The ID string in column 2 is used by clients and servers to determine in which level of the protocol they will speak to each other.

Table 1-8. SMB protocol dialects

Protocol name	ID string	Used by
Core	`PC NETWORK PROGRAM 1.0`
Core Plus	`MICROSOFT NETWORKS 1.03`
LAN Manager 1.0	`LANMAN1.0`
LAN Manager 2.0	`LM1.2X002`
LAN Manager 2.1	`LANMAN2.1`
NT LAN Manager 1.0	`NT LM 0.12`	Windows NT 4.0
Samba's NT LM 0.12	`Samba`	Samba
Common Internet File System	`CIFS 1.0`	Windows 2000/XP

Samba implements the NT LM 0.12 specification for NT LAN Manager 1.0. It is backward-compatible with all the other SMB variants. The CIFS specification is, in reality, LAN Manager 0.12 with a few specific additions.

SMB Clients and Servers

As mentioned earlier, SMB is a client/server protocol. In the purest sense, this means that a client sends a request to a server, which acts on the request and returns a reply. However, the client/server roles can often be reversed, sometimes within the context of a single SMB session. For example, consider the two Windows 95/98/Me computers in Figure 1-11. The computer named maya shares a printer to the network, and the computer named toltec shares a disk directory. maya is in the client role when accessing toltec's network drive and in the server role when printing a job for toltec.

Figure 1-11. Two computers that both have resources to share

This brings out an important point in Samba terminology:

A server is a computer with a resource to share.
A client is a computer that wishes to use that resource.
A computer can be a client, a server, or both, or it can be neither at any given time.

Microsoft Windows products have both the SMB client and server built into the operating system, and it is common to find Windows acting as a server, client, both, or neither at any given time in a production network. Although Samba has been developed primarily to function as a server, there are also ways that it and associated software can act as an SMB client. As with Windows, it is even possible to set up a Unix system to act as an SMB client and not as a server. See Chapter 5 for more details on this topic.

A Simple SMB Connection

The client and server must complete three steps to establish a connection to a resource:

Establish a NetBIOS session.
Negotiate the protocol variant.
Set session parameters, and make a tree connection to a resource.

We will examine each step through the eyes of a useful tool that we mentioned earlier: the modified tcpdump that is available from the Samba web site.

TIP

You can download the tcpdump program at http://www.samba.org in the samba/ftp/tcpdump-smb directory; the latest version as of this writing is 3.4-10. Use this program as you would use the standard tcpdump application, but add the -s 1500 switch to ensure that you get the whole packet and not just the first few bytes.

Establishing a NetBIOS Session

When a user first makes a request to access a network disk or send a print job to a remote printer, NetBIOS takes care of making a connection at the session layer. The result is a bidirectional channel between the client and server. The client and server need only two messages to establish this connection. This is shown in the following example session request and response, as captured by tcpdump .

First, the client sends a request to open a session, and tcpdump reports:

>>> NBT Packet
NBT Session Request
Flags=0x81000044
Destination=TOLTEC      NameType=0x20 (Server)
Source=MAYA             NameType=0x00 (Workstation)

Then the server responds, granting a session to the client:

>>> NBT Packet
NBT Session Granted
Flags=0x82000000

At this point, there is an open channel between the client and server.

Negotiating the Protocol Variant

Next, the client sends a message to the server to negotiate an SMB protocol. As mentioned earlier, the client sets its tree identifier (TID) field to zero, because it does not yet know what TID to use. A tree identifier is a number that represents a connection to a share on a server.

The command in the message is SMBnegprot, a request to negotiate a protocol variant that will be used for the entire session. Note that the client sends to the server a list of all the variants that it can speak, not vice versa:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=154

SMB PACKET: SMBnegprot (REQUEST)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5315
UID           =  0
MID           =  257
Word Count    =  0
Dialect=PC NETWORK PROGRAM 1.0
Dialect=MICROSOFT NETWORKS 3.0
Dialect=DOS LM1.2X002
Dialect=DOS LANMAN2.1
Dialect=Windows for Workgroups 3.1a
Dialect=NT LM 0.12

The server responds to the SMBnegprot request with an index (with counting starting at 0) into the list of variants that the client offered, or with the value 0xFF if none of the protocol variants is acceptable:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=84

SMB PACKET: SMBnegprot (REPLY)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  0
Proc ID       =  5315
UID           =  0
MID           =  257
Word Count    =  17
NT1 Protocol
DialectIndex=5
[...]

In this example, the server responds with the value 5, which indicates that the NT LM 0.12 dialect will be used for the remainder of the session.

Set Session and Login Parameters

The next step is to transmit session and login parameters for the session, which you do using the SMBSesssetupX command. The parameters include the following:

The account name and password (if there is one)
The workgroup name
The maximum size of data that can be transferred
The number of pending requests that can be in the queue at a time

The resulting output from tcpdump is:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=150

SMB PACKET: SMBsesssetupX (REQUEST)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x10
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5315
UID           =  1
MID           =  257
Word Count    =  13
Com2=0x75
Res1=0x0
Off2=120
MaxBuffer=2920
MaxMpx=50
VcNumber=0
SessionKey=0x1380
CaseInsensitivePasswordLength=24
CaseSensitivePasswordLength=0
Res=0x0
Capabilities=0x1
Pass1&Pass2&Account&Domain&OS&LanMan=  
  JAY METRAN Windows 4.0 Windows 4.0

SMB PACKET: SMBtconX (REQUEST) (CHAINED)
smbvwv[]=
Com2=0xFF
Off2=0
Flags=0x2
PassLen=1
Passwd&Path&Device=
smb_bcc=23
smb_buf[]=\\TOLTEC\SPIRIT

In this example, the SMBsesssetupX Session Setup command allows for an additional SMB command to be piggybacked onto it (indicated by the letter X at the end of the command name). The hexadecimal code of the second command is given in the Com2 field. In this case the command is 0x75, which is the SMBtconX (Tree Connect and X) command. The SMBtconX message looks for the name of the resource in the smb_buf buffer. In this example, smb_buf contains the string \\TOLTEC\SPIRIT, which is the full pathname to a shared directory on toltec. Using the "and X" commands like this speeds up each transaction because the server doesn't have to wait on the client to make a second request.

Note that the TID is still zero. Finally, the server returns a TID to the client, indicating that the user has been authorized access and that the resource is ready to be used:

>>> NBT Packet
NBT Session Packet
Flags=0x0
Length=85

SMB PACKET: SMBsesssetupX (REPLY)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  1
Proc ID       =  5315
UID           =  100
MID           =  257
Word Count    =  3
Com2=0x75
Off2=68
Action=0x1
[000] Unix Samba 2.2.6
[010] METRAN

SMB PACKET: SMBtconX (REPLY) (CHAINED)
smbvwv[]=
Com2=0xFF
Off2=0
smbbuf[]=
ServiceType=A:

The ServiceType field is set to "A" to indicate that this is a file service. Available service types are:

"A" for a disk or file
"LPT1" for a spooled output
"COMM" for a direct-connect printer or modem
"IPC" for a named pipe

Now that a TID has been assigned, the client can use it as a handle to perform any operation that it would use on a local disk drive. It can open files, read and write to them, delete them, create new files, search for filenames, and so on.

Windows Workgroups and Domains

Up to now, we've covered basic SMB technology, which is all you would need if you had nothing more advanced than MS-DOS clients on your network. We do assume you want to support Windows clients, especially the more recent versions, so next we'll describe the enhancements Microsoft has added to SMB networking—namely, Windows for Workgroups and Windows domains.

Windows Workgroups

Windows Workgroups are very similar to the SMB groups already described. You need to know just a few additional things.

Browsing

Browsing is the process of finding the other computers and shared resources in the Windows network. Note that there is no connection with a World Wide Web browser, apart from the general idea of "discovering what's there." On the other hand, browsing the Windows network is like the Web in that what's out there can change without warning.

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 the following into an application or file manager to access resources:

\\toltec\spirit\

Browsing is much more convenient, making it possible to examine the contents of a network by using the point-and-click GUI interface of the Network Neighborhood (or My Network Places [5]) on a Windows client.

You will encounter two types of browsing in an SMB network:

Browsing a list of computers and shared resources
Browsing the shared resource of a specific computer

Let's look at the first one. On each LAN (or subnet) with a Windows 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 that 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 the Network Neighborhood. As you saw at the opening of the chapter, the computer will respond with a list of shared resources that can be accessed after the user is successfully authenticated.

Each server on 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.

WARNING

The Windows Network Neighborhood can behave oddly: until you select a particular computer to browse, the Network Neighborhood window might contain data that is not up-to-date. That means the Network Neighborhood window can be showing computers that have crashed or can be missing computers that haven't 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 (including Windows for Workgroups and Windows 95/98/Me or NT/2000/XP) can act as a local master browser. The local master browser can have one or more backup browsers on the local subnet that will take over in the event that the local master browser fails or becomes inaccessible. To ensure fluid operation, the local backup browsers will frequently synchronize their browse list with the local master browser.

Here is how to calculate the minimum number of backup browsers that will be allocated on a workgroup:

If up to 32 Windows NT/2000/XP workstations are on the network, or up to 16 Windows 95/98/Me computers are on the network, the local master browser allocates one backup browser in addition to the local master browser.
If the number of Windows NT/2000/XP workstations falls between 33 and 64, or the number of Windows 95/98/Me workstations falls between 17 and 32, the local master browser allocates two backup browsers.
For each group of 32 NT/2000/XP workstations or 16 Windows 95/98/Me computers beyond this, the local master browser allocates another backup browser.

There is currently no upper limit on the number of backup browsers that can be allocated by the local master browser.

Browsing elections

Browsing is a critical aspect of any Windows workgroup. However, not everything runs perfectly on any network. For example, let's say that a computer running Windows on the desk of a small company's CEO is the local master browser—that is, until he switches it off while plugging in his massage chair. At this point the Windows NT 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 nearly all Windows operating systems such that they can each 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 CEO has finished his massage and reboots his server. As the server comes online, it will announce its presence, and an election will take place to see if 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 hostname of the client

These values determine which operating system has seniority and will fulfill the role of the local master browser. (Chapter 7 describes the election process in more detail.) The architecture developed to achieve this is not elegant and has built-in security problems. While a browsing domain can be integrated with domain security, the election algorithm does not take into consideration which computers become browsers. 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 of Windows networking, and backward-compatibility requirements will ensure that it is in use for years to come.

Windows 95/98/Me authentication

Three types of passwords arise when Windows 95/98/Me is operating in a Windows workgroup:

A Windows password
A Windows Networking password
A password for each shared resource that has been assigned password protection

The Windows password functions in a manner that might be a source of confusion for Unix system administrators. It is not there to prevent unauthorized users from using the computer. (If you don't believe that, try clicking the Cancel button on the password dialog box and see what happens!) Instead, the Windows password is used to gain access to a file that contains the Windows Networking and network resource passwords. There is one such file per registered user of the system, and they can be found in the C:\Windows directory with a name composed of the user's account name, followed by a .pwl extension. For example, if the user's account name is "sarah," the file will be C:\Windows\sarah.pwl. This file is encrypted using the Windows password as the encryption key.

TIP

As a security measure, you might want to check for junk .pwl files on Windows 95/98/Me clients, which might have been created by mistakes users made while attempting to log on. A .pwl file is easily cracked and can contain valid passwords for Samba accounts and network shares.

The first time the network is accessed, Windows attempts to use the Windows password as the Windows Networking password. If this is successful, the user will not be prompted for two separate passwords, and subsequent logins to the Windows system will automatically result in logging on to the Windows network as well, making things much simpler for the user.

Shared network resources in the workgroup can also have passwords assigned to them to limit their accessibility. The first time a user attempts to access the resource, she is asked for its password, and a checkbox in the password dialog box gives the user the option to add the password to her password list. This is the default; if it is accepted, Windows will store the password in the user's .pwl file, and all further authentication to the resource will be handled automatically by Windows.

Samba's approach to workgroup authentication is a little different, which is a result of blending the Windows workgroup model with that of the Unix host upon which Samba runs. This will be discussed further in Chapter 9.

Windows NT Domains

The peer-to-peer networking model of workgroups 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. Workgroups offer only the most basic level of security, and because each resource can have its own password, it is inconvenient (to say the least) for users to remember the password for each resource in a large network. Even if that were not a problem, many people find it frustrating to have to interrupt their creative workflow to enter a shared password into a dialog box every time another network resource is accessed.

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 workgroup of SMB computers that has one addition: a server acting as a domain controller (see Figure 1-12).

Figure 1-12. A simple Windows domain

Domain controllers

A domain controller in a Windows NT domain functions much like a Network Information Service (NIS) server 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 centered around security, including authentication, the process of granting or denying a user access to the resources of the domain. This is 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 NT 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, computers, and processes. SIDs are commonly written in ASCII form as hyphen-separated fields, like this:

S-1-5-21-1638239387-7675610646-9254035128-545

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.

ACLs supply the same function as "rwx" file permissions that are common in Unix systems. However, ACLs are more versatile. Unix file permissions only set permissions for the owner and group to which the file belongs, and "other," meaning everyone else. Windows NT/2000/XP ACLs allow permissions to be set individually for any number of arbitrary users and/or groups. ACLs are made up of one or more access control entries (ACEs), each of which contains an SID and the access rights associated with it.

ACL support has been added as a standard feature for some Unix variants and is available as an add-on for others. Samba supports mappings between Windows and Unix ACLs, and this will be covered in Chapter 8.

Primary and backup domain controllers

You've already read about master and backup browsers. Domain controllers are similar in that a domain has a primary domain controller (PDC) and can have one or more backup domain controllers (BDCs) as well. If the PDC fails or becomes inaccessible, its duties are automatically taken over by one of the BDCs. BDCs frequently synchronize their SAM data with the PDC so if the need arises, any one of them can immediately begin performing domain-controller services without impacting the clients. However, note that BDCs have read-only copies of the SAM database; they can update their data only by synchronizing with a PDC. 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.

All recent versions of Windows can log on to a domain as clients to access the resources of the domain servers. The systems that are considered members of the domain are a more exclusive class, composed of the PDC and BDCs, as well as domain member servers, which are systems that have joined a domain as members, and are known to the domain controllers by having a computer account in the SAM database.

Authentication

When a user logs on to a Windows domain by typing in a username and password, a secure challenge and response protocol is invoked between the client computer and a domain controller to verify that the username and password are valid. Then the domain controller sends a SID back to the client, which uses it to create a Security Access Token (SAT) that is valid only for that system, to be used for further authentication. This access token has information about the user coded into it, including the username, the group, and the rights the user has within the domain. At this point, the user is logged on to the domain.

Subsequently, when the client attempts to access a shared resource within the domain, the client system enters into a secure challenge and response exchange with the server of the resource. The server then enters into another secure challenge and response conversation with a domain controller to check that the client is valid. (What actually happens is that the server uses information it gets from the client to pretend to be the client and authenticate itself with the domain controller. If the domain controller validates the credentials, it sends an SID back to the server, which uses the SID to create its own SAT for the client to enable access to its local resources on the client's behalf.) At this point, the client is authenticated for resources on the server and is allowed to access them. The server then uses the SID in the access token to determine what permissions the client has to use and modify the requested resource by comparing them to entries in the ACL of the resource.

Although this method of authentication might seem overly complicated, it allows clients to authenticate without having plain-text passwords travel through the network, and it is much more difficult to crack than the relatively weak workgroup security we described earlier.

Name service with WINS and DNS

The Windows Internet Name Service (WINS) is Microsoft's implementation of a NetBIOS name server (NBNS). As such, WINS inherits much of NetBIOS's characteristics. First, WINS is flat; you can have only simple machine names such as inca, mixtec, or navaho, and workgroups such as PERU, MEXICO, or USA. In addition, WINS is dynamic: when a client first comes online, it is required to report its hostname, its address, and its workgroup to the local WINS server. This WINS server will retain the information so long as the client periodically refreshes its WINS registration, which indicates that it's still connected to the network. Note that WINS servers are not workgroup- or domain-specific; they can contain information for multiple domains and/or workgroups, which might exist on more than one subnet.

Multiple WINS servers can be set to synchronize with each other. This allows entries for computers that come online and go offline in the network to propagate from one WINS server to another. While in theory this seems efficient, it can quickly become cumbersome if several WINS servers are covering a network. Because WINS services can cross multiple subnets (you'll either hardcode the address of a WINS server in each of your clients or obtain it via DHCP), it is often more efficient to have each Windows client, regardless of the number of Windows domains, point themselves to the same WINS server. That way, only one authoritative WINS server will have the correct information, instead of several WINS servers continually struggling to synchronize themselves with the most recent changes.

The currently active WINS server is known as the primary WINS server. You can also install a secondary WINS server, which will take over if the primary WINS server fails or becomes inaccessible. Both the primary and any other WINS servers will synchronize their address databases on a periodic basis.

In the Windows family of operating systems, only a server edition of Windows NT/2000 can act as a WINS server. Samba 2.2 can function as a primary WINS server, but cannot synchronize its database with other WINS servers. It therefore cannot act as a secondary WINS server or as a primary WINS server for a Windows secondary WINS server.

WINS handles name service by default, although Microsoft added DNS starting with Windows NT 4 Server. It is compatible with DNS that is standard on virtually every Unix system, and a Unix server (such as the Samba host) can also be used for DNS.

Trust relationships

One additional aspect of Windows NT domains not yet supported in Samba 2.2 is that it is possible to set up a trust relationship between domains, allowing clients within one domain to access the resources within another without the user having to go through additional authentication. The protocol that is followed is called pass-through authentication, in which 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 the first (trusted) domain to check that the user is valid before granting access to the resource.

Note that in many aspects, the behaviors of a Windows workgroup and a Windows NT domain overlap. For example, the master and backup browsers in a domain are always the PDC and BDC, respectively. Let's update our Windows domain diagram to include both a local master and local backup browser. The result is shown in Figure 1-13.

Figure 1-13. A Windows domain with a local master and local backup browser

The similarity between workgroups and NT domains is not accidental because the concept of Windows domains did not evolve until Windows NT 3.5 was introduced, and Windows domains were forced to remain backward-compatible with the workgroups present in Windows for Workgroups.

Samba can function as a primary domain controller for Windows 95/98/Me and Windows NT/2000/XP clients with the limitation that it can act as a PDC only, and not as a BDC.

Samba can also function as a domain member server, meaning that it has a computer account in the PDC'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.

If it exists, a PDC always plays the role of the domain master browser. By Microsoft design, the two always share the NetBIOS resource type <1B> and (unfortunately) cannot be separated.
Windows 95/98/Me computers cannot become or even contact a domain master browser. This means that it is necessary to have at least one Windows NT/2000/XP system (or Samba server) on each subnet of a multisubnet workgroup.

Each subnet's local master browser continues to maintain the browse list for its subnet, for which it becomes authoritative. So if a computer wants to see a list of servers within its own subnet, the local master browser of that subnet will be queried. If a computer wants to see a list of servers outside the subnet, it can still go only as far as the local master browser. This works because at appointed intervals, the authoritative browse list of a subnet's local master browser is synchronized with the domain master browser, which is synchronized with the local master browser of the other subnets in the domain. This is called browse list propagation.

Samba can act as a domain master browser in a Windows NT domain, or it can act as a local master browser for a subnet, synchronizing its browse list with the domain master browser.

What's New in Samba 2.2?

In Version 2.2, Samba has more advanced support for Windows networking, including the ability to perform the more important tasks necessary for acting in a Windows NT domain. In addition, Samba 2.2 has some support for technologies that Microsoft introduced in Windows 2000, although the Samba team has saved Active Directory support for Version 3.0.

PDC Support for Windows 2000/XP Clients

Samba previously could act as a PDC to authenticate Windows 95/98/Me and Windows NT 4 systems. This functionality has been extended in Release 2.2 to include Windows 2000 and Windows XP. Thus, it is possible to have a Samba server supporting domain logons for a network of Windows clients, including the most recent releases from Microsoft. This can result in a very stable, high-performance, and more secure network, and gives you the added benefit of not having to purchase per-seat Windows CALs from Microsoft.

Microsoft Dfs Support

Microsoft Dfs allows shared resources that are dispersed among a number of servers in the network to be gathered together and appear to users as if they all exist in a single directory tree on one server. This method of organization makes life much simpler for users. Instead of having to browse around the network on a treasure hunt to locate the resource they want to use, they can go directly to the Dfs server and grab what they want. Samba 2.2 offers support for serving Dfs, so a Windows server is no longer needed for this purpose.

Windows NT/2000/XP Printing Support

Windows NT/2000/XP has a different Remote Procedure Call (RPC)-based printer interface than Windows 95/98/Me does. In Samba 2.2, the Windows NT/2000/XP interface is supported. Along with this, the Samba team has been adding support for automatically downloading the printer driver from the Samba server while adding a new printer to a Windows client.

ACLs

Samba now supports ACLs on its Unix host for Unix variants that support them. The list includes Solaris 2.6, 7, and 8, Irix, AIX, Linux (with either the ACL patch for the ext2/ext3 filesystem from http://acl.bestbits.at or when using the XFS filesystem), and FreeBSD (Version 5.0 and later). When using ACL support, Samba translates between Unix ACLs and Windows NT/2000/XP ACLs, making the Samba host look and act more like a Windows NT/2000/XP server from the point of view of Windows clients.

Support for Windows Client Administration Tools

Windows comes with tools that can be used from a client to manage shared resources remotely on a Windows server. Samba 2.2 allows these tools to operate on shares on the Samba server as well.

Integration with Winbind

Winbind is a facility that allows users whose account information is stored in a Windows domain database to authenticate on a Unix system. The result is a unified logon environment, in which a user account can be kept on either the Unix system or a Windows NT/2000 domain controller. This greatly facilitates account management because administrators no longer need to keep the two systems synchronized, and it is possible for users whose accounts are held in a Windows domain to authenticate when accessing Samba shares.

Unix CIFS Extensions

The Unix CIFS extensions were developed at Hewlett-Packard and introduced in Samba 2.2.4. They allow Samba servers to support Unix filesystem attributes, such as links and permissions, when sharing files with other Unix systems. This allows Samba to be used as an alternative to network file sharing (NFS) for Unix-to-Unix file sharing. An advantage of using Samba is that it authenticates individual users, whereas NFS authenticates only clients (based on their IP addresses, which is a poor security model). This gives Samba an edge in the area of security, along with its much greater configurability. See Chapter 5 for information on how to operate Unix systems as Samba clients.

And More...

As usual, the code has numerous improvements that do not show up at the administrative level in an immediate or obvious way. Samba now functions better on systems that employ PAM (Pluggable Authentication Modules), and there is new support for profiling. Samba's support for oplocks has been strengthened, offering better integration with NFS server-terminated leases (currently on Irix and Linux only) and in the local filesystem with SMB locks mapped to POSIX locks (which is dependent on each Unix variant's implementation of POSIX locks). And of course there have been the usual bug fixes.

What's New in Samba 3.0?

The main distinguishing feature of Samba 3.0 is that it includes support for Kerberos 5 authentication and LDAP, which are required to act as clients in an Active Directory domain. Another feature that appeared in Samba 3.0 is support for Unicode, which greatly simplifies supporting international languages.

In later Version 3 releases, the Samba team plans to develop support for WINS replication, allowing Samba to act as a secondary WINS server or as a primary WINS server with Windows or Samba secondary WINS servers. Also planned are support for acting as a Windows NT BDC and support for Windows NT domain trust relationships.

What Can Samba Do?

Now let's wrap up by showing where Samba can help out and where it is limited. Table 1-9 summarizes which roles Samba can and cannot play in a Windows NT or Active Directory domain or a Windows workgroup. Many of the Windows domain protocols are proprietary and have not been documented by Microsoft and therefore must be reverse-engineered by the Samba team before Samba can support them. As of Version 3.0, Samba cannot act as a backup in most roles and does not yet fully support Active Directory.

Table 1-9. Samba roles (as of Version 3.0)

Role	Can perform?
File server	Yes
Printer server	Yes
Microsoft Dfs server	Yes
Primary domain controller	Yes
Backup domain controller	No
Active Directory domain controller	No
Windows 95/98/Me authentication	Yes
Windows NT/2000/XP authentication	Yes
Local master browser	Yes
Local backup browser	Yes
Domain master browser	Yes
Primary WINS server	Yes
Secondary WINS server	No

An Overview of the Samba Distribution

As mentioned earlier, Samba actually contains several programs that serve different but related purposes. These programs are documented more fully in Appendix C. For now, we will introduce each of them briefly and describe how they work together.

The majority of the programs that come with Samba center on its two daemons. Let's take a refined look at the responsibilities of each daemon:

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 Network Neighborhood and participates in browsing elections.
smbd: The smbd daemon manages the shared resources between the Samba server and its clients. It provides file, print, and browse services to SMB 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 protocol.

New with Version 2.2, there is an additional daemon:

winbindd: This daemon is used along with the name service switch to get information on users and groups from a Windows NT server and allows Samba to authorize users through a Windows NT/2000 server.

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.
make_smbcodepage: A program used when working with Samba's internationalization features for telling Samba how to convert between upper- and lowercase in different character sets.
make_unicodemap: Another internationalization program used with Samba for compiling Unicode map files that Samba uses to translate DOS codepages or Unix character sets into 16-bit unicode.
net: A new program distributed with Samba 3.0 that can be used to perform remote administration of servers.
nmblookup: A program that provides NBT name lookups to find a computer's IP address when given its machine name.
pdbedit: A new program distributed with Samba 3.0 that is helpful for managing user accounts held in SAM databases.
rpcclient: A program that can be used to run MS-RPC functions on Windows clients.
smbcacls: A program that is used to set or show ACLs on Windows NT filesystems.
smbclient: An ftp-like Unix client that can be used to connect to SMB shares and operate on them. The smbclient command is discussed in detail in Chapter 5.
smbcontrol: A simple administrative utility that sends messages to nmbd or smbd.
smbgroupedit: A command that can be used to define mappings between Windows NT groups and Unix groups. It is new in Samba 3.0.
smbmnt: A helper utility used along with smbmount.
smbmount: A program that mounts an smbfs filesystem, allowing remote SMB shares to be mounted in the filesystem of the Samba host.
smbpasswd: A program that allows an administrator to change the passwords used by Samba.
smbsh: A tool that functions like a command shell to allow access to a remote SMB filesystem and allow Unix utilities to operate on it. This command is covered in Chapter 5.
smbspool: A print-spooling program used to send files to remote printers that are shared on the SMB network.
smbstatus: A program that reports the current network connections to the shares on a Samba server.
smbtar: A program similar to the Unix tar command, for backing up data in SMB shares.
smbumount: A program that works along with smbmount to unmount smbfs filesystems.
testparm: A simple program for checking the Samba configuration file.
testprns: A program that tests whether printers on the Samba host are recognized by the smbd daemon.
wbinfo: A utility used to query the winbindd daemon.

Each major release of Samba goes through an exposure test before it's announced. In addition, it is quickly updated afterward if problems or unwanted side effects are found. The latest stable distribution as of this writing is Samba 2.2.6, and this book focuses mainly on the functionality supported in Samba 2.2.6, as opposed to older versions of Samba.

How Can I Get 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.

Footnotes

[1] You can also right-click the shared resource in the Network Neighborhood and then select the Map Network Drive menu item.

[2] 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.

[3] You might also see the abbreviation NetBT, which is common in Microsoft literature.

[4] See http://www.samba.org/cifs/docs/what-is-smb.html for Richard's excellent summary of SMB.

[5] This was originally called Network Neighborhood in Windows 95/98/NT, but Microsoft has changed the name to My Network Places in the more recent Windows Me/2000/XP. We will continue to call it Network Neighborhood, and if you're using a new version of Windows, be aware that My Network Places can act a little differently in some ways.