|
Sams Teach Yourself Samba in 24 Hours |
||||||||||||||
|
Hour 2: Windows Networking |
||||||||||||||
|
CIFSstands for Common Internet File System and is often used interchangeably with the abbreviation SMB. In reality, CIFS is simply the next incarnation of the SMB protocol. Whatever you call it, don't let it get too confusing.
SMB was initially defined by a joint document between Microsoft and Intel in 1987 named "Microsoft Network/OpenNET-File sharing Protocol." Since then, the protocol has gone through many changes, and Paul Leach and Dilip Naik document its latest version in the CIFS 1.0 specification draft. Because it is a draft, the real documentation in practice is simply "how NT does it."
The Server Message Block protocol runs on top of NetBIOS (as seen in Figure 2.5). As discussed in the previous section, NetBIOS can run on top of NetBEUI, IPX/SPX, and TCP/IP. Samba only implements SMB over TCP/IP.
Figure
2.5
SMB over NetBIOS and possible transport layer protocols.
SMB is a connection-oriented protocol meaning that all SMB packets occur within the context of virtual circuit (VC) between the client and server and are delivered in the order that they are sent. If the VC is broken, all the information contained within that circuit becomes invalid. Consider the following four things which represent an SMB connection environment: a virtual circuit between the client and the server, a session uid, a resource connection tree ID (tid), and a file identifier (fid) (as seen in Figure 2.6). The uid is described more in step 2 of the SMB protocol overview. The tid represents the shared resource and the fid represents individual file handles.
Figure
2.6
SMB connection environment.
If any one part of the connection environment becomes invalid, everything contained within that portion of the environment is invalidated as well. The SMB protocol maintains no information about past connections, so that if a connection terminates, everything must be rebuilt from scratch. A session uid that a client obtained from a previous connection will not work with a new connection. All tree connection IDs and file handle IDs must be reopened as well. Any handles to files located on the network resource become useless when the connection is closed.
This is why PC applications that run from a network share crash if the connection terminates while the application is executing. The application attempts to use the file handles that were previously issued. Most clients silently attempt to reconnect the terminated session so that the share connection is available, but none of the file handles that the application is using are valid.
Figure 2.6 describes the environment for some fictitious connection. Now assume that the uid (0x0198) for some reason terminated. Both of the tree connections, x0x7c and 0xa8, would become invalid because they were contained within the uid's environment. Now suppose that the entire virtual circuit terminated. In this case, all the uids, tids, and fids would become invalid because they all occur within the context of the virtual circuit.
When a user connects to a share on a SMB server by, for example, using Explorer's Map Network Drive dialog box or browsing through the Network Neighborhood, three setup stages occur before he or she can access anything on the share. The steps described refer to file and file shares, but the same set of requests and responses is necessary for connecting to remote printers as well.
Figure 2.7 lists the steps in setting up an SMB connection between a client and a server. The chronological flow of the diagram is top to bottom and left to right.
Figure
2.7
Setting up an SMB connection to a shared resource.
1. Negprot--The first step in connecting to an SMB share, shown in the top of Figure 2.7, is to negotiate the protocol dialect to use. In the request packet, the client sends a text listing off all the SMB dialects with which it is familiar. Each SMB dialect (or protocol level) supports certain functionality. The latest CIFS specification draft lists the different commands supported by each level. The server then selects the highest protocol it knows and responds to the client specifying the protocol number from the previous list.
2. sessetup&X--After the client and server have agreed on a protocol level that each will support, the next step is to create a session connection between the two. This step corresponds to the middle portion of Figure 2.7. The client sends a "sessions setup" request including a username and some proof of validity such as a password. The server attempts to validate the requesting user. If successful, the server then returns a session uid to the client. This uid is unique for each session and has no relation to the server internal representation of users. For example, the session uid is not the same thing as the user's UNIX uid or an NT user's security identifier (sid). As you will learn in Hour 6, "Security Levels and Passwords," this description is not entirely accurate. The SMB protocol can operate under different modes of security which affect steps 2 and 3. For the purposes at the moment however, this is a good enough description.
3. tcon&X--The final step necessary before allowing access to files on a remote share, which is depicted in the bottom on Figure 2.7, is to make a tree connection to the shared resource successfully. The client sends a "tree connect" request to the server including the uid issued by the server in the successful session setup. If the user has sufficient access to the share, the client is issued a tree connection ID (tid). The tid is used in all requests to access files contained with the resource referred to by the tid.
When these steps are complete, the user can perform operations on the share such as printing a document or opening a file contained in the share for writing.
|
Sams Teach Yourself Samba in 24 Hours |
||||||||||||||
|
Hour 2: Windows Networking |
||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.