[Chapter 3] 3.3 An Introduction to SMB/CIFS

3.3 An Introduction to SMB/CIFS

We'll wrap up this chapter with a short tutorial on SMB/CIFS. SMB/CIFS is the protocol that Windows 95/98 and NT machines use to communicate with the Samba server and each other. At a high level, the SMB protocol suite is relatively simple. It includes commands for all of the file and print operations that you might do on a local disk or printer, such as:

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

Each of these operations can be encoded into an SMB message and transmitted to and from a server. The original name SMB comes from their data format: these are versions of the standard DOS system-call data structures, or Server Message Blocks, redesigned for transmitting to another machine across a network.

3.3.1 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. Rarely does a server send a message that is not in response to a client.

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

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.

3.3.1.1 SMB header format

Table 3.1 shows the format of an SMB header. 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 (0xFFFF) is placed in its header field. Other fields may be padded with zeros when not used.

The fields of the SMB header are listed in Table 3.1.

Table 3.1: 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`	Tree identifier; a unique ID for a resource in use by client
`PID`	`2`	Caller process ID
`UID`	`2`	User identifier
`MID`	`2`	Multiplex identifier; used to route requests inside a process

3.3.1.2 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 3.2.

Table 3.2: SMB Command Contents
Field	Size in 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 of these fields; 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 would like an SMB sniffer with a graphical interface, try "ethereal," which uses the GTK libraries; see the Samba homepage for more information on this tool.)

If you would like more information on each of the commands for the SMB protocol, see the SMB/CIFS documentation at ftp://ftp.microsoft.com/developr/drg/CIFS/.

3.3.1.3 SMB variations

The SMB protocol has been extended with new commands several times since its inception. Each new version is backwards compatible with the previous versions. This makes it quite possible for a LAN to have various clients and servers running different versions of the SMB protocol at once.

Table 3.3 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 is used by clients and servers to determine what level of the protocol they will speak to each other.

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

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

3.3.2 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 computers in Figure 3.28. The computer named WIZZIN shares a printer to the network, and the computer named ESCRIME shares a disk directory. WIZZIN is in the client role when accessing ESCRIME's network drive, and in the server role when printing a job for ESCRIME.

Figure 3.28: Two computers that both have resources to share

This brings out an important point in Samba terminology:

A server is a machine with a resource to share.
A client is a machine that wishes to use that resource.
A server can be a client (of another computer's resource) at any given time.

Note that there are no implications as to the amount of resources that make up a server, or whether it has a large disk space or fast processor. A server could be an old 486 with a printer attached to it, or it could be an UltraSparc station with a 10 gigabyte disk service.

Microsoft Windows products have both the SMB client and server built in to the operating system. Wndows NT 4.0 uses a newer SMB protocol than Windows for Workgroups, and it offers an enhanced form of network security which will be discussed in Chapter 6. In addition, there are a large number of commercial SMB server products available from companies such as Sun, Compaq, SCO, Hewlett-Packard, Syntax, and IBM. Unfortunately, on the client side there are far fewer offerings, limited mainly to Digital Equipment's Pathworks product, and of course, Samba.

3.3.3 A Simple SMB Connection

Before we close this chapter, let's take a look at a simple SMB connection. This is some pretty technical data - which isn't really necessary to administer Samba - so you can skip over it if you like. We present this information largely as a way to help you get familiar with how the SMB protocol negotiates connections with other computers on the network.

There are four steps that the client and server must complete in order to establish a connection to a resource:

Establish a virtual connection.
Negotiate the protocol variant to speak.
Set session parameters.
Make a tree connection to a resource.

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

You can download this program at samba.org in the samba/ftp/tcpdump-smb directory; the latest version as of this writing is 3.4-5. 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.

3.3.3.1 Establishing a virtual connection

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 virtual channel between the client and server. In reality, there are only two messages that the client and server need to establish this connection. This is shown in the following example session request and response, as captured by tcpdump :

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

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

3.3.4 Negotiating the Protocol Variant

At this point, there is an open channel between the client and server. 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, since 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 of the variants that it can speak, not vice versa.

The server responds to the SMBnegprot request with an index into the list of variants that the client offered, starting with index 0, or with the value 0xFF if none of the protocol variants are acceptable. Continuing 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:

>>> 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       =  5371
UID           =  0
MID           =  385
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

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

SMB PACKET: SMBnegprot (REPLY)
SMB Command   =  0x72
Error class   =  0x0
Error code    =  0
Flags1        =  0x0
Flags2        =  0x1
Tree ID       =  0
Proc ID       =  5371
UID           =  0
MID           =  385
Word Count    =  02
[000] 05 00

3.3.5 Set Session and Login Parameters

The next step is to transmit session and login parameters for the session. This includes the account name and password (if there is one), the workgroup name, the maximum size of data that can be transferred, and the number of pending requests that may be in the queue at any one time.

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

Note that the TID is still zero. The server will provide a TID to the client once the session has been established and a connection has been made to the requested resource. In addition, note that the password is sent in the open. We can change this later using encrypted passwords:

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

SMB PACKET: SMBsesssetupX (REQUEST)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x10
Flags2        =  0x0
Tree ID       =  0
Proc ID       =  5371
UID           =  1
MID           =  385
Word Count    =  13
Com2=0x75
Res1=0x0
Off2=106
MaxBuffer=2920
MaxMpx=2
VcNumber=0
SessionKey=0x1FF2
CaseInsensitivePasswordLength=1
CaseSensitivePasswordLength=1
Res=0x0
Capabilities=0x1
Pass1&Pass2&Account&Domain&OS&LanMan=  
  KRISTIN PARKSTR Windows 4.0 Windows 4.0
PassLen=2
Passwd&Path&Device=
smb_bcc=22
smb_buf[]=\\ESCRIME\PUBLIC

3.3.6 Making Connection to a Resource

For the final step, 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. It also sets the ServiceType field 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

The output is:

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

SMB PACKET: SMBsesssetupX (REPLY)
SMB Command   =  0x73
Error class   =  0x0
Error code    =  0
Flags1        =  0x80
Flags2        =  0x1
Tree ID       =  121
Proc ID       =  5371
UID           =  1
MID           =  385
Word Count    =  3
Com2=0x75
Off2=68
Action=0x1
[000] Unix Samba 1.9.1
[010] PARKSTR

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

Now that a TID has been assigned, the client may issue any sort of command 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.


3.2 Setting Up Windows NT 4.0 Computers		4. Disk Shares

Using Samba