Chapter 1. Learning the Samba

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

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

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

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

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

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.

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 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:

1. Establish a NetBIOS session.

2. Negotiate the protocol variant.

3. 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

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

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

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.

Active Directory Domains

Starting with Windows 2000, Microsoft has introduced Active Directory, the next step beyond Windows NT domains. We won't go into much detail concerning Active Directory because it is a huge topic. Samba 2.2 doesn't support Active Directory at all, and support in Samba 3.0 is limited to acting as a client. For now, be aware that with Active Directory, the authentication model is centered around Lightweight Directory Access Protocol (LDAP), and name service is provided by DNS instead of WINS. Domains in Active Directory can be organized in a hierarchical tree structure, in which each domain controller operates as a peer, with no distinction between primary and backup controllers as in Windows NT domains.

Windows 2000/XP systems can be set up as simple workgroup or Windows NT domain clients (which will function with Samba). The server editions of Windows 2000 can be set up to run Active Directory and support Windows NT domains for backward compatibility (mixed mode). In this case, Samba 2.2 works with Windows 2000 servers in the same way it works with Windows NT 4.0 servers. When set up to operate in native mode, Windows 2000 servers support only Active Directory. Even so, Samba 2.2 can operate as a server in a domain hosted by a native-mode Windows 2000 server, using the Windows 2000 server's PDC emulation mode. However, it is not possible for Samba 2.2 or 3.0 to operate as a domain controller in a Windows 2000 Active Directory domain.

If you want to know more about Active Directory, we encourage you to obtain a copy of the O'Reilly book, Windows 2000 Active Directory.

Can a Windows Workgroup Span Multiple Subnets?

Yes, but most people who have done it have had their share of headaches. Spanning multiple subnets was not part of the initial design of Windows NT 3.5 or Windows for Workgroups. As a result, a Windows domain that spans two or more subnets is, in reality, the "gluing" together of two or more workgroups that share an identical name. The good news is that you can still use a PDC to control authentication across each subnet. The bad news is that things are not as simple with browsing.

As mentioned previously, each subnet must have its own local master browser. When a Windows domain spans multiple subnets, a system administrator will have to assign one of the computers as the domain master browser. The domain master browser will keep a browse list for the entire Windows domain. This browse list is created by periodically synchronizing the browse lists of each local master browser with the browse list of the domain master browser. After the synchronization, the local master browser and the domain master browser should contain identical entries. See Figure 1-14 for an illustration.

Figure 1-14. A workgroup that spans more than one subnet

Sound good? Well, it's not quite nirvana for the following reasons:

• 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.

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.