1.7 Versioning and Capability Negotiation
The SMB Protocol supports dialect negotiation. A dialect is a version of the SMB Protocol that is generally defined in terms of additions and changes relative to a previous version. New SMB dialects typically provide new commands, can include modifications to previous commands, and are likely to include extensions to existing semantics. When the SMB Protocol starts up, its first task is to determine which dialect the client and server use to communicate. See the SMB_COM_NEGOTIATE command for a detailed description of the SMB dialect negotiation process.
In the protocol negotiation process, SMB dialects are identified by Dialect Identifier Strings. For example, the Core Protocol is identified by two strings: "PCLAN1.0" or "PC NETWORK PROGRAM 1.0". Either or both of these strings can be sent by the client. The CIFS dialect is also known as NT LAN Manager (or, simply NT LANMAN), and is identified by the dialect string "NT LM 0.12".
The earliest dialect of SMB is now referred to as the Core Protocol because, for many years, it represented the least common set of commands that were required to be implemented for interoperability--the "core" set. In CIFS, many older commands including some original Core Protocol commands have been declared obsolete and are no longer used. Others are listed as deprecated or obsolescent, which means that they are likely to become obsolete and are not recommended to be used by clients, even though it is recommended that servers support them.
The table below lists the most common or best-known dialects, as well as related documentation (if available).
|
Dialect name |
Dialect Identifier String |
Comments |
|---|---|---|
|
Core Protocol |
PCLAN1.0 |
The dialect supported by IBM Corporation in early implementations of the SMB Protocol. It is documented in [IBM-SMB]. |
|
Core Protocol |
PC NETWORK PROGRAM 1.0 |
Represents the MSNET SMB Protocol, which is also known as the "core protocol". This dialect is identical to the "PCLAN1.0" dialect, and some versions of MSNET accept either dialect string. This dialect is documented in [SMB-CORE]. |
|
Xenix Extensions |
xenix1.1 |
The "xenix1.1" dialect is documented in [MSFT-XEXTNP]. This dialect provides a set of extensions to SMB to support the XENIX operating system. Also known as the XENIX dialect. |
|
Xenix Extensions |
XENIX CORE |
Another dialect supporting XENIX extensions, possibly the same as "xenix1.1". The "XENIX CORE" dialect string is sent in protocol negotiation performed by Windows NT and OS/2, among others. |
|
CorePlus |
MICROSOFT NETWORKS 1.03 |
This string denotes the "CorePlus" dialect, consisting of several minor extensions to the core protocol, including raw read and write commands and compound commands such as SMB_COM_LOCK_AND_READ and SMB_COM_WRITE_AND_UNLOCK. The CorePlus extensions are documented in [XOPEN-SMB]. |
|
LAN Manager 1.0 |
LANMAN1.0 |
The LAN Manager 1.0 extended protocol was created to support OS/2 system functions and file system features. It is documented in [SMB-LM1X] and [XOPEN-SMB]. |
|
DOS LAN Manager 1.0 |
MICROSOFT NETWORKS 3.0 |
This is the DOS LAN Manager 1.0 extended protocol. It is identical to "LANMAN1.0", except that OS/2 error codes are translated to DOS error codes before being transmitted to the client. |
|
LAN Manager 1.2 |
LANMAN1.2 |
The LAN Manager 1.2 extended protocol adds support for additional OS/2 commands and features to "LANMAN1.0". LAN Manager 1.2 is documented in [SMB-LM12] and [XOPEN-SMB]. |
|
LAN Manager 2.0 |
LM1.2X002 |
This represents the LAN Manager 2.0 extended protocol for OS/2. It is documented in [SMB-LM20] and [XOPEN-SMB]. Also known as the LANMAN2.0 dialect. |
|
DOS LAN Manager 2.0 |
DOS LM1.2X002 |
This is the DOS version of LAN Manager 2.0. It is also documented in [SMB-LM20] and [XOPEN-SMB]. When this dialect is selected, OS/2 error codes are translated to DOS error codes by the server before transmission to the client. Also known as the DOS LANMAN2.0 dialect. |
|
LAN Manager 2.1 |
LANMAN2.1 |
LAN Manager 2.1 extended protocol. The additions and changes with respect to LAN Manager 2.0 are documented in [SMB-LM21]. |
|
DOS LAN Manager 2.1 |
DOS LANMAN2.1 |
DOS LAN Manager 2.1 extended protocol. This is, once again, identical to the OS/2 version of the dialect except that error codes are translated. See [SMB-LM21]. |
|
NT LAN Manager |
NT LM 0.12 |
NT LAN Manager extended protocol. This set of extensions was created to support Windows NT. OS/2 LAN Manager 2.1 features are also supported. This dialect was originally documented in [CIFS]. Also known as the NT LANMAN dialect. |
Security Negotiation: During the initialization of the SMB session, the server indicates support for:
Either user-oriented or resource-oriented access controls.
Plaintext or challenge/response authentication.
Message signing. If it is supported, the server indicates that it is required.
If the client or server requires message signing but the other node does not support it, then SMB session establishment fails. Similarly, if either node requires a higher level of authentication security than the other supports, session establishment fails. See the SMB_COM_NEGOTIATE command for a detailed description of security negotiation.
Feature Negotiation: The client and server can negotiate individual features on a per-connection or, in some cases, per-message basis:
CIFS provides a mechanism for negotiating a specific set of Capabilities, including support for Unicode file names, 64-bit file offsets, and Opportunistic Locking. For the complete list of Capabilities, see the SMB_COM_NEGOTIATE command specification. Capabilities are negotiated at session startup.
Each SMB message includes two bit fields (Flags and Flags2) that indicate whether a specific feature or option has been selected for use in that message. These fields are described in section 2.2.3.1.