Section 1.4. Connecting to a CIFS File Share

1.4. Connecting to a CIFS File Share

So, what happens when a user types net use p: \\rain\documents? To simplify the answer, let's assume the presence of a name service, a datagram service, and a session service, and ignore the details of whether the underlying network uses the NetBIOS interface or TCP/IP. In Chapter 5, we discuss how a CIFS server such as Samba handles operations such as authentication and authorization when connecting to file and printer shares; for now, let's just assume that these things are working.

Figure 1-10 shows the basic steps that a client will go through in order to access a remote share such as \\RAIN\documents. The diagram assumes that the client, named CATHY, has already resolved the server's name, SAM, to an IP address using either DNS or the NetBIOS mechanisms discussed earlier. Be aware that the steps to connect to a file or printer share are not always the same, because CIFS supports multiple authentication types and models. For now however, just focus on the scenario of an individual connecting to a share using a login name and password for the session credentials. This is by far the most common and intuitive case.

Figure 1-10. Examining what happens when a user types net use p: \\server\share

The first step in establishing the CIFS connection is to negotiate the protocol dialect that the client and server will use. The client transmits a list of dialects that it understands and the server selects the one that it prefers (supposedly the one with the most supported features). Table 1-6 lists the CIFS dialects supported by Samba 3.0.

Developers plan to enhance the POSIX 2 dialect in a future version of Samba so that the client can take more advantage of the Unix CIFS Extensions for file operations. More details on these extensions are covered in Chapter 11.

Table 1-6. CIFS protocol dialects

Protocol name	smb.conf name	Example clients
NT LANMAN 1.0 NT LM 0.12 POSIX 2	NT1	Windows 95, NT 4.0, and later smbclient Linux CIFS FS
LANMAN2.1 LM1.2X002 Samba DOS LM1.2X002	LANMAN2
LANMAN1.0 MICROSOFT NETWORKS 3.0	LANMAN1	MS DOS network client
MICROSOFT NETWORKS 1.03	COREPLUS
PC NETWORK PROGRAM 1.0	CORE

There are other pieces of information in the server's Negotiate Protocol (negprot) reply, such as whether the server supports encrypted passwords, what security level is used when connecting to its shares, and whether the server supports Unicode for handling non-ASCII strings.

Once the client and server have agreed upon the dialect to use, the next step in Figure 1-10 is to authenticate the user's credentials. During this session setup (sesssetup) operation, the login name can be paired with different representations of the user's proof of identify, such as a clear-text password, the response portion of a challenge/response algorithm, or a Kerberos ticket, depending on the capability bits set in the server's negprot reply. If the user is successfully authenticated, the server responds by sending the client a session virtual uid or vuid, a 16-bit token that proves the user's prior authentication. It has no relation to a Unix uid or a Windows SID. If the session is ever broken, the server will have to reauthenticate the user and issue a new vuid before any share connections can be reestablished.

If the session setup step is successful, the client can include the vuid in the tree connection (tcon) request, which is what actually makes the connection to the CIFS share. The server performs any necessary authorization checks by looking up the user's information, such as group membership, based on the vuid that was previously assigned. If the user has the necessary access rights to connect to the share, the server replies with a tree connection ID (tid).

Now the client is able to open and save files on the share just as if it were a local disk. When issuing the open file call in Figure 1-10, the client sends the previously issued tid to point to the root of the directory tree and the vuid for use in the server's file authorization checks.