2 Protocol Operation Overview

In order to access a file on a server, a client has to:

• Parse the full file name to determine the server name, and the relative name within that server

• Resolve the server name to a transport address (this may be cached)

• Make a connection to the server (if no connection is already available)

• Exchange CIFS messages (see below for an example)

This process may be repeated as many times as desired. Once the connection has been idle for a while, it may be torn down.

2.1 Server Name Determination

How the client determines the name of the server and the relative name within the server is outside of the scope of this document. However, just for expository purposes, here are three examples.

In the URL "file://fs.megacorp.com/users/fred/stuff.txt", the client could take the part between the leading double slashes and the next slash as the server name and the remainder as the relative name in this example "fs.megacorp.com" and "/users/fred/stuff.txt", respectively.

In the path name "\\corpserver\public\policy.doc" the client could take the part between the leading double backslashes and the next slash as the server name, and the remainder as the relative name in this example, "corpserver" and "\public\policy.doc" respectively.

In the path name "x:\policy.doc" the client could use "x" as an index into a table that contains a server name and a file name prefix. If the contents of such a table for "x" were "corpserver" and "\public", then the server name and relative name would be the same as in the previous example.

2.2 Server Name Resolution

Like server name determination, how the client resolves the name to the transport address of the server is outside the scope of this document. All that is required by CIFS is that a CIFS client MUST have some means to resolve the name of a CIFS server to a transport address, and that a CIFS server MUST register its name with a name resolution service known its clients .

Some examples of name resolution mechanisms include: using the Domain Name System (DNS) [1,2], and using NETBIOS name resolution (see RFC 1001 and RFC 1002 [3,4]). The server name might also be specified as the string form of an IPv4 address in the usual dotted decimal notation, e.g., "157.33.135.101"; in this case, "resolution" consists of converting to the 32 bit IPv4 address.

Which method is used is configuration dependent; the default SHOULD be DNS to encourage interoperability over the Internet.

Note: The name resolution mechanism used may place constraints on the form of the server name; for example, in the case of NETBIOS, the server name must be 15 characters or less, and MUST be upper case.

2.3 Sample Message Flow

The following illustrates a typical message exchange sequence for a client connecting to a user level server, opening a file, reading its data, closing the file, and disconnecting from the server. Note: using the CIFS request batching mechanism (called the "AndX" mechanism), the second to sixth messages in this sequence can be combined into one, so that there are really only three round trips in the sequence. The last trip can be handled asynchronously by the client.

Client Command	Server Response
SMB_COM_NEGOTIATE	Must be the first message sent by a client to the server. Includes a list of SMB dialects supported by the client. Server response indicates which SMB dialect should be used.
SMB_COM_SESSION_SETUP_ANDX	Transmits the user's name and credentials to the server for verification. Successful server response has Uid field set in SMB header used for subsequent SMBs on behalf of this user.
SMB_COM_TREE_CONNECT_ANDX	Transmits the name of the disk share (exported disk resource) the client wants to access. Printer device and interprocess communication devices are outside the scope of this document. Successful server response has Tid field set in SMB header used for subsequent SMBs referring to this resource.
SMB_COM_OPEN_ANDX	Transmits the name of the file, relative to Tid, the client wants to open . Successful server response includes a file id (Fid) the client should supply for subsequent operations on this file.
SMB_COM_READ	Client supplies Tid, Fid, file offset, and number of bytes to read. Successful server response includes the requested file data.
SMB_COM_CLOSE	Client closes the file represented by Tid and Fid. Server responds with success code.
SMB_COM_TREE_DISCONNECT	Client disconnects from resource represented by Tid.

2.4 CIFS Protocol Dialect Negotiation

The first message sent from a CIFS client to a CIFS server must be one whose Command field is SMB_COM_NEGOTIATE. The format of this client request includes an array of NULL terminated strings indicating the dialects of the CIFS protocol which the client supports. The server compares this list against the list of dialects the server supports and returns the index of the chosen dialect in the response message.

2.5 Message Transport

CIFS is transport independent. The CIFS protocol assumes:

• A reliable connection oriented message-stream transport, and makes no higher level attempts to ensure sequenced delivery of messages between the client and server.

• A well known endpoint for the CIFS service, such as a designated port number.

• Some mechanism to detect failures of either the client or server node, and to deliver such an indication to the client or server software so they can clean up state. When a reliable transport connection from a client terminates, all work in progress by that client is terminated by the server and all resources open by that client on the server are closed.

It can run over any transport that meets these requirements. Some transports do not natively meet all the requirements, and a standard encapsulation of CIFS for that transport may need to be defined. Appendix A defines how to run CIFS over NETBIOS over TCP; Appendix B defines how to run CIFS over TCP.

2.5.1 Connection Management

Once a connection is established, the rules for reliable transport connection dissolution are:

• If a server receives a transport establishment request from a client with which it is already conversing , the server may terminate all other transport connections to that client. This is to recover from the situation where the client was suddenly rebooted and was unable to cleanly terminate its resource sharing activities with the server.

• A server may drop the transport connection to a client at any time if the client is generating malformed or illogical requests . However, wherever possible the server should first return an error code to the client indicating the cause of the abort.

• If a server gets a unrecoverable error on the transport (such as a send failure) the transport connection to that client may be aborted.

• A server may terminate the transport connection when the client has no open resources on the server, however, we recommend that the termination be performed only after some time has passed or if resources are scarce on the server. This will help performance in that the transport connection will not need to be reestablished if activity soon begins anew. Client software is expected to be able to automatically reconnect to the server if this happens.

2.6 Opportunistic Locks

The CIFS protocol includes a mechanism called "opportunistic locks", or oplocks, that allows the client to lock a file in such a manner that the server can revoke the lock. The purpose of oplocks is to allow file data caching on the client to occur safely. It does this by defining the conditions under which an oplock is revoked .

When a client opens a file it may request an oplock on the file. If the oplock is given the client may safely perform caching. At some point in the future a second client may open the file. The following steps provide an overview of the actions taken in response to the open from the second client:

• The server holds off responding to the open from the second client.

• The server revokes the oplock of the first client.

• The first client flushes all cached data to the server.

• The first client acknowledges the revoke of the oplock.

• The server responds to the open from the second client.

As can be seen from the above steps, the first client has the opportunity to write back data and acquire record locks before the second client is allowed to examine the file. Because of this a client that holds an oplock can aggressively cache file data and state.

Anecdotal evidence suggests that oplocks provide a performance boost in many real-world applications running on existing CIFS client implementations while preserving data integrity.

2.6.1 Oplock Types

There are three types of oplocks:

• Exclusive

• Batch

• Level II

Versions of the CIFS file sharing protocol including and newer than the "LANMAN1.0" dialect support oplocks. Level II oplocks were introduced in NTLM 0.12.

2.6.1.1 Exclusive and Batch Oplocks

When a client has an exclusive oplock on a file, it is the only client to have the file open. The exclusive oplock allows the client to safely perform file data read and write caching, metadata caching, and record lock caching. All other operations on the file cannot be safely cached.

The server may revoke the exclusive oplock at any time. The client is guaranteed that the server will revoke the exclusive oplock prior to another client successfully opening the file. This gives the client that holds the oplock the opportunity to write back cached information to the file.

The batch oplock was introduced to allow a client to defer closing a file that was opened and reopened repetitively by an application. It has the same semantics as the exclusive oplock with the following additional guarantee. The client holding a batch oplock has the additional guarantee that the server will revoke the batch oplock prior to another client successfully making any change to the file.

When a client opens a file it can specify that it wants an exclusive oplock, a batch oplock, or no oplock. Exclusive and batch oplocks can only be obtained as a side effect of a file being opened. The protocol does not support other means to obtain exclusive and batch oplocks.

Oplocks can only be obtained on files. Oplocks are not supported on directories and named pipes. However it is not an error to request an oplock on directories and named pipes. In this case the server must return that no oplock was granted.

The server response to a successful open request includes information about what type of oplock was obtained. A server that does not support oplocks should always return that no oplock was granted.

A client that requests an exclusive oplock will get one of the following:

• An exclusive oplock

• A level II oplock

• No oplock

A client that requests a batch oplock will get one of the following:

• A batch oplock

• A level II oplock

• No oplock

A client that requests no oplock will always get no oplock.

The following diagrams the behavior of various clients and the server when an exclusive oplock is obtained on a file and subsequently revoked. The diagram also applies to a batch oplock.

Exclusive/Batch Protocol Oplock Example
Client A	Client B	< -- >	Server
Open file "foo"		- >
		< -	Open response. Open succeeded. Exclusive oplock granted
Read data		- >
		< -	Read response with data
Write data (cache)
Read data (cache)
	Open file "foo"	- >
		< -	Oplock break to Client A
Write data		- >
		< -	Write response
Discard cached data
Release oplock		- >
		< -	Open response to B. Open succeeded. No oplock granted.

The revoking of an exclusive or batch oplock involves the server sending an oplock break message to the client, followed by the client flushing file information to the server, followed by the client releasing the oplock. If the client does not respond by releasing the oplock within a period of time acceptable to the server, then the server may consider the oplock released and allow pending operations to proceed. The protocol does not define the duration of the time out period.

When a client opens a file that already has an exclusive oplock, the server first checks the share mode on the file. If the sharing allows the client open to succeed then the exclusive oplock is broken, after which the open is allowed to proceed.

When a client opens a file that already has a batch oplock, the server first revokes the batch oplock. Then the open is allowed to proceed. The reason for this server behavior is that it gives the holder of the oplock the opportunity to close the file. This in turn allows the open to obtain an exclusive or batch oplock.

When a client opens a file that has a security descriptor, the server first checks if the open for the desired access is allowed by the security descriptor. If access is not allowed, the open fails. Any exclusive or batch oplock on the file is not disturbed. Because of this behavior a client holding an exclusive or batch oplock cannot safely cache security descriptor information

2.6.1.2 Level II Oplocks

When a client has a level II oplock on a file, it is an indication to the client that other clients may also have the file open. The level II oplock allows the client to safely perform file data read caching. All other operations on the file cannot be safely cached.

The server may revoke the level II oplock at any time. The client is guaranteed that the server will revoke the level II oplock prior to another client successfully writing the file. This gives the client that holds the level II oplock the opportunity to discard its cached data.

Note however that the level II oplock is revoked differently than an exclusive or batch oplock. A level II oplock break is sent to the client, but a response from the client is not expected. The server allows the write to proceed immediately after the level II oplock break is sent to the client.

A client cannot explicitly request that a level II oplock be granted. A level II oplock is granted either when a file is opened or when a server revokes an exclusive or batch oplock.

When a file is opened the client may request an exclusive or batch oplock. The server has the option of granting a level II oplock instead of the requested type of oplock. This is the only way to obtain a level II oplock when a file is opened.

When a server revokes an exclusive or batch oplock, it may indicate to the client that in conjunction with the revocation that the client is being granted a level II oplock.

The following diagrams the behavior of various clients and the server when a level II oplock is obtained on a file and subsequently revoked.

Level II Oplock Protocol Example
Client A	Client B	< -- >	Server
Open file "foo"		- >
		< -	Open response. Open succeeded. Exclusive oplock granted
Read data		- >
		< -	Read response with data
	Open file "foo"	- >
		< -	Oplock break to Client A. Oplock downgraded to level II.
Release oplock to level II		- >
		< -	Open response to B. Open succeeded. Oplock level II granted.

2.6.2 Comparison with Other File Locking Methods

The CIFS protocol has three mechanisms to enable a client to control how other clients access a file.

• Opportunistic locks

• Byte range locks

• Sharing locks

Of the three, the server may revoke only opportunistic locks. Byte range and sharing locks are held for as long as the client desires.

Historically on client systems, byte range and sharing locks are exposed to the application. This allows the application to have explicit control over the obtaining and releasing of these types of locks.

Typically however oplocks are not exposed to the application. They are implemented inside the client operating system. The client operating system decides when it is appropriate to obtain and release oplocks. It also handles all of the issues related to revoking of oplocks by the server.

2.6.3 Oplock SMBs

This section summarizes the SMB commands that affect oplocks.

2.6.3.1 Obtaining an Oplock

The following SMB commands may be used to obtain an oplock:

• SMB_COM_OPEN

• SMB_COM_CREATE

• SMB_COM_CREATE_NEW

• SMB_COM_OPEN_ANDX

• SMB_COM_TRANSACTION2 (OPEN2)

• SMB_COM_NT_CREATE_ANDX

• SMB_COM_NT_TRANSACT (NT_CREATE)

The server may only grant a level II oplock to a client for a file when that file is opened using one of "SMB_COM_NT_CREATE_ANDX" or "SMB_COM_NT_TRANSACT (NT_CREATE)".

2.6.3.2 Releasing an Oplock

A client releases an oplock with the SMB_COM_LOCKING_ANDX command. Alternatively the client may release the oplock by closing the file with the SMB_COM_CLOSE command. Any operation that would invalidate the file handle results in the oplock being released. This includes disconnecting the tree, logging off the user that opened the file, and any action that would disconnect the session.

A client should release its exclusive or batch oplock on a file in response to the server revoking the oplock. Failure to do so is a violation of the protocol.

A client does not need to release a level II oplock (i.e. respond to the server) on a file in response to the server revoking the oplock. However doing so is not an error.

2.6.3.3 Revoking an Oplock

The server revokes a client's oplock by sending a SMB_COM_LOCKING_ANDX command to the client. The command is sent asynchronously sent from the server to the client. This message has the LOCKING_ANDX_OPLOCK_RELEASE flag set indicating to the client that the oplock is being broken. OplockLevel indicates the type of oplock the client now owns. If OplockLevel is 0, the client possesses no oplocks on the file at all. If OplockLevel is 1, the client possesses a Level II oplock. The client is expected to flush any dirty buffers to the server, submit any file locks, and respond to the server with either an SMB_LOCKING_ANDX SMB having the LOCKING_ANDX_OPLOCK_RELEASE flag set, or with a file close if the file is no longer in use by the client.

2.6.4 Other Issues

Since a close being sent to the server and break oplock notification from the server could cross on the wire, if the client gets an oplock notification on a file that it does not have open, that notification should be ignored. The client is guaranteed that an oplock break notification will not be issued before the server has sent the response to the file open.

Due to timing, the client could get an "oplock broken" notification in a user's data buffer as a result of this notification crossing on the wire with an SMB_COM_READ_RAW request. The client must detect this (use length of message, "FFSMB," MID of -1 and Command of SMB_COM_LOCKING_ANDX) and honor the "oplock broken" notification as usual. The server must also note on receipt of an SMB_COM_READ_RAW request that there is an outstanding (unanswered) "oplock broken" notification to the client; it must then return a zero length response denoting failure of the read raw request. The client should (after responding to the "oplock broken" notification) use a non-raw read request to redo the read. This allows a file to actually contain data matching an "oplock broken" notification and still be read correctly.

When an exclusive or batch oplock is being revoked, more than one client open request may be paused until the oplock is released. Once the oplock is released, the order that the paused open requests are processed is not defined.

The protocol allows a client to obtain an oplock and then issue an operation that causes the oplock to be revoked. An example of this is a client obtaining an exclusive oplock on a file and then opening the file a second time.

The protocol allows a client to have a file open multiple times, and each open could have a level II oplock associated with it. A server may choose not to support this situation by simply not handing out more than one level II oplock for a particular file to a particular client.

The protocol allows a server to grant on a single file a level II oplock for some opens and no oplock for other opens. A server may have heuristics that indicate some file opens would not benefit from a level II oplock.

A server that supports access to files via mechanisms other than this protocol must revoke oplocks as necessary to preserve the semantics expected by the clients owning the oplocks.

A client that has an exclusive or batch oplock on a file may cache file metadata. This includes the following information: create time, modify time, access time, change time, file size, file attributes, and extended attributes size. However a server is not required to break an oplock when a second client examines file metadata. Clients should be aware of this behavior when examining file metadata without having the file open.

When a server revokes an exclusive or batch oplock it may grant a level II oplock in its place. The client should consider the level II oplock in effect after the client has released the exclusive or batch oplock. The server may decide to revoke the level II oplock before the client has released the exclusive or batch oplock. In this situation the client should behave as if the revoke of the level II oplock arrived just after the exclusive or batch oplock was released.

2.7 Security Model

Each server makes a set of resources available to clients on the network. A resource being shared may be a directory tree, printer, etc. So far as clients are concerned , the server has no storage or service dependencies on any other servers; a client considers the server to be the sole provider of the file (or other resource) being accessed.

The CIFS protocol requires server authentication of users before file accesses are allowed, and each server authenticates its own users. A client system must send authentication information to the server before the server will allow access to its resources.

A server requires the client to provide a user name and some proof of identity (often something cryptographically derived from a password) to gain access. The granularity of authorization is up to the server. For example, it may use the account name to check access control lists on individual files, or may have one access control list that applies to all files in the directory tree.

When a server validates the account name and password presented by the client, an identifier representing that authenticated instance of the user is returned to the client in the Uid field of the response SMB. This Uid must be included in all further requests made on behalf of the user from that client.

2.8 Authentication

This section defines the CIFS user and message authentication protocols. User authentication allows the server to verify that the client knows a password for a user. Message authentication allows messages in a session to be verified by both the server and the client.

2.8.1 Overview

User authentication is based on the shared knowledge of the user's password. There are two styles of user authentication. The first involves the client sending passwords in plain text to the server. The second involves a challenge/response protocol.

Plain text password authentication exposes the user's password to programs that have access to the CIFS protocol data on the network. For this reason plain text password authentication is discouraged and by default should be disabled in CIFS protocol implementations.

With the challenge/response protocol the server sends a "challenge" to the client, which the client responds to in a way that proves it knows the user's password. A "response" is created from the challenge by encrypting it with a 168 bit "session key" computed from the user's password. The response is then returned to the server, which can validate the response by performing the same computation.

The user authentication protocol is described as if the CIFS server keeps a client's password. However an implementation might actually store the passwords on a key distribution server and have servers use a protocol outside the scope of this document to enable them to perform the steps required by this protocol.

Messages may be authenticated by computing a message authentication code (MAC) for each message and attaching it to the message. The MAC used is a keyed MD5 construction similar to that used in IPSec [RFC 1828], using a "MAC key" computed from the session key, and the response to the server's challenge. The MAC is over both the message text and an implicit sequence number, to prevent replay attacks.

2.8.2 Base Algorithms

Following are definitions of algorithms used by the authentication algorithms.

E(K, D)

denote the DES block mode encryption function [FIPS 81], which accepts a seven byte key (K) and an eight byte data block (D) and produces an eight byte encrypted data block as its value.

Ex(K,D)

denote the extension of DES to longer keys and data blocks. If the data to be encrypted is longer than eight bytes, the encryption function is applied to each block of eight bytes in sequence and the results are concatenated together. If the key is longer than seven bytes, each 8 byte block of data is first completely encrypted using the first seven bytes of the key, then the second seven bytes, etc., appending the results each time. For example, to encrypt the 16 byte quantity D0D1 with the 14 byte key K0K1,

Ex(K0K1,D0D1) = concat(E(K0,D0),E(K0,D1),E(K1,D0),E(K1,D1))

concat(A, B, ..., Z)

is the result of concatenating the byte strings A, B, ... Z

head(S, N)

denote the first N bytes of the byte string S.

swab(S)

denote the byte string obtained by reversing the order of the bits in each byte of S, i.e., if S is byte string of length one, with the value 0x37 then swab(S) is 0xEC.

zeros(N)

denote a byte string of length N whose bytes all have value 0 (zero).

ones(N)

denote a byte string of length N whose bytes all have value 255.

xor(A, B)

denote a byte string formed by the bytewise logical "xor" of each of the bytes in A and B.

and(A, B)

denote a byte string formed by the bytewise logical "and" of each of the bytes in A and B.

substr(S, A, B)

denote a byte string of length N obtained by taking N bytes of S starting at byte A. The first byte is numbered zero. I.e., if S is the string "NONCE" then substr(S, 0, 2) is "NO".

2.8.3 Authentication Algorithms

Following are definitions of the authentication algorithms.

2.8.3.1 NT Session Key

The session key S21 and partial MAC key S16 are computed as

S16 = MD4(PN)

S21 = concat(S16, zeros(5))

where

• PN is a Unicode string containing the user's password in clear text, case sensitive, no maximum length

• MD4(x) of an byte string "x" is the 16 byte MD4 message digest [RFC 1320] of that string

2.8.3.2 LM Session Key

The session key S21 and partial MAC key S16 are computed as

S16X = Ex(swab(P14),N8)

S21 = concat(S16X, zeros(5))

S16 = concat(head(S16X, 8), zeros(8))

Where

• P14 is a 14 byte ASCII string containing the user's password in clear text, upper cased, padded with nulls

• N8 is an 8 byte string whose value is {0x4b, 0x47, 0x53, 0x21, 0x40, 0x23, 0x24, 0x25}

2.8.3.3 Response

The response to the challenge RN is computed as

RN = EX(S21, C8)

Where

• C8 is a 8 byte challenge selected by the server

• S21 is the LM session key or NT session key as determined above

2.8.3.4 MAC key

The MAC key is computed as follows :

K = concat(S16, RN)

Where

• S16 is the partial MAC key computed with the LM session key or NT session key as determined above

• RN is the response to the challenge as determined above

• The result K is either 40 or 44 bytes long, depending on the length of RN. [ed: what determines length of RN?]

2.8.3.5 Message Authentication Code

The MAC is the keyed MD5 construction:

MAC(K, text) = head(MD5(concat(K, text)), 8)

Where

• MD5 is the MD5 hash function; see RFC 1321

• K is the MAC key determined above

• text is the message whose MAC is being computed.

2.8.4 Session Authentication Protocol

2.8.4.1 Plain Text Password

If plaintext password authentication was negotiated, clients send the plaintext password in SMB_COM_TREE_CONNECT , SMB_COM_TREE_CONNECT_ANDX , and/or SMB_COM_SESSION_SETUP_ANDX . The SMB field used to contain the response depends upon the request:

• Password in SMB_COM_TREE_CONNECT

• Password in SMB_COM_TREE_CONNECT_ANDX

• AccountPassword in SMB_COM_SESSION_SETUP_ANDX in dialects prior to "NTLM 0.12"

• CaseInsensitivePassword in SMB_COM_SESSION_SETUP_ANDX in the "NTLM 0.12" dialect

• CaseSensitivePassword in SMB_COM_SESSION_SETUP_ANDX in the "NTLM 0.12" dialect

2.8.4.2 Challenge/Response

The challenge C8 from the server to the client is contained in the EncryptionKey field in the SMB_COM_NEGPROT response. Clients send the response to the challenge in SMB_COM_TREE_CONNECT , SMB_COM_TREE_CONNECT_ANDX , and/or SMB_COM_SESSION_SETUP_ANDX . The SMB field used to contain the response depends upon the request:

• Password in SMB_COM_TREE_CONNECT

• Password in SMB_COM_TREE_CONNECT_ANDX

• AccountPassword in SMB_COM_SESSION_SETUP_ANDX in dialects prior to "NTLM 0.12"

• CaseInsensitivePassword in SMB_COM_SESSION_SETUP_ANDX for a response computed using the "LM session key" in the "NTLM 0.12" dialect

• CaseSensitivePassword in SMB_COM_SESSION_SETUP_ANDX for a response computed using the "NT session key" in the "NTLM 0.12" dialect

The challenge/response authentication protocol has the following steps:

• The server chooses an 8 byte challenge C8 and sends it to the client.

• The client computes RN as described above

• The client sends the 24 byte response RN to the server

• The server computes RN as described above and compares the received response with its computed value for RN; if equal, the client has authenticated.

2.8.5 Message authentication code

Once a user logon has been authenticated, each message can be authenticated as well. This will prevent man in the middle attacks, replay attacks, and active message modification attacks.

To use message authentication, the client sets SMB_FLAGS2_SMB_SECURITY_SIGNATURE in SMB_COM_SESSION_SETUP_ANDX request to the server, and includes a MAC. If the resulting logon is non-null and non-guest, then the SMB_COM_SESSION_SETUP_ANDX response and all subsequent SMB requests and responses must include a MAC. The first non-null, non-guest logon determines the key to be used for the MAC for all subsequent sessions.

Message authentication may only be requested when the "NTLM 0.12" dialect has been negotiated. If message authentication is used, raw mode MUST not be used (because some raw mode messages have no headers in which to carry the MAC).

Let

• SN be a request sequence number, initially set to 0. Both client and server have one SN for each connection between them.

• RSN be the sequence number expected on the response to a request.

• req_msg be a request message

• rsp_msg be a response message

The SN is logically contained in each message and participates in the computation of the MAC.

For each message sent in the session, the following procedure is followed:

• Client computes MAC(req_msg) using SN, and sends it to the server in the request message. If there are multiple requests in the message (using the "AndX" facility), then the MAC is calculated as if it were a single large request.

• Client increments its SN and saves it as RSN

• Client increments its SN this is the SN it will use in its next request

• Server receives each req_msg, validates MAC(req_msg) using SN, and responds ACCESS_DENIED if invalid

• Server increments its SN and saves it as RSN

• Server increments its SN this is the SN it will expect in the next request

• Server computes MAC(rsp_msg) using RSN, and sends it to client in the response message. If there are multiple responses in the message (using the "AndX" facility), then the MAC is calculated as if it were a single large response.

• Client receives each rsp_msg, validates MAC(rsp_msg) using RSN, and discards the response message if invalid

In each message that contains a MAC, the following bit is set in the flags2 field:

 #define SMB_FLAGS2_SMB_SECURITY_SIGNATURES 0x0004 

The sender of a message inserts the sequence number SSN into the message by putting it into the first 4 bytes of the SecuritySignature field and zeroing the last 4 bytes, computes the MAC over the entire message, then puts the MAC in the field. The receiver of a message validates the MAC by extracting the value of the SecuritySignature field, putting its ESN into the first 4 bytes of the SecuritySignature field and zeroing the last 4 bytes, computing the MAC, and comparing it to the extracted value.

Oplock break messages from the server to the client may not use message authentication, even if it has been negotiated.

2.8.6 Security Level

The SMB_COM_NEGPROT response from a server has the following bits in its SecurityMode field:

 #define NEGOTIATE_SECURITY_USER_LEVEL          0x01 #define NEGOTIATE_SECURITY_CHALLENGE_RESPONSE  0x02 #define NEGOTIATE_SECURITY_SIGNATURES_ENABLED  0x04 #define NEGOTIATE_SECURITY_SIGNATURES_REQUIRED 0x08 

If NEGOTIATE_SECURITY_USER_LEVEL is set, then "user level" security is in effect for all the shares on the server. This means that the client must establish a logon (with SMB_COM_SESSION_SETUP_ANDX) to authenticate the user before connecting to a share, and the password to use in the authentication protocol described above is the user's password. If NEGOTIATE_SECURITY_USER_LEVEL is clear, then "share level" security is in effect for all the shares in the server. In this case the authentication protocol is a password for the share.

If NEGOTIATE_SECURITY_CHALLENGE_RESPONSE is clear, then the server is requesting plaintext passwords.

If NEGOTIATE_SECURITY_CHALLENGE_RESPONSE is set, then the server supports the challenge/response session authentication protocol described above, and clients should use it. Servers may refuse connections that do not use it.

If the dialect is earlier than "NTLM 0.12" then the client computes the response using the "LM session key". If the dialect is "NTLM 0.12" then the client may compute the response either using the "LM session key", or the "NT session key", or both. The server may choose to refuse responses computed using the "LM session key".

If NEGOTIATE_SECURITY_SIGNATURES_ENABLED is set, then the server supports the message authentication protocol described above, and the client may use it. This bit may only be set if NEGOTIATE_SECURITY_CHALLENGE_RESPONSE is set.

If NEGOTIATE_SECURITY_SIGNATURES_REQUIRED is set, then the server requires the use of the message authentication protocol described above, and the client must use it. This bit may only be set if NEGOTIATE_SECURITY_SIGNATURES_ENABLED is set. This bit must not be set if NEGOTIATE_SECURITY_USER_LEVEL is clear (i.e., for servers using "share level" security).

2.9 Distributed File System (DFS) Support

Protocol dialects of NT LM 0.12 and later support distributed filesystem operations. The distributed filesystem gives a way for this protocol to use a single consistent file naming scheme which may span a collection of different servers and shares. The distributed filesystem model employed is a referral - based model. This protocol specifies the manner in which clients receive referrals.

The client can set a flag in the request SMB header indicating that the client wants the server to resolve this SMB's paths within the DFS known to the server. The server attempts to resolve the requested name to a file contained within the local directory tree indicated by the TID of the request and proceeds normally. If the request pathname resolves to a file on a different system, the server returns the following error:

STATUS_DFS_PATH_NOT_COVERED - the server does not support the part of the DFS namespace needed to resolve the pathname in the request. The client should request a referral from this server for further information.

A client asks for a referral with the TRANS2_DFS_GET_REFERRAL request containing the DFS pathname of interest. The response from the server indicates how the client should proceed.

The method by which the topological knowledge of the DFS is stored and maintained by the servers is not specified by this protocol.