CIFS Security and Authentication
Each server makes a set of shared resources available to clients on the network. A resource being shared may be a directory tree, a printer, a named pipe, or other object. The CIFS protocol requires server authentication of users before resource accesses are allowed. 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. The granularity of authorization is up to the server. For example, the server may use the account name to check access control lists (ACLs) on individual files, or the server may have one access control list that applies to all files in the directory tree.
When a server validates a user account name and password presented by a client, it returns to the client an identifier representing that authenticated instance of the user in the Uid field of the server response packet. This Uid value must be included in all further client requests made on behalf of the user.
RFC 2478 Authentication
Authentication according to RFC 2478 takes place primarily through a SMB_COM_SESSION_SETUP_ANDX client request following a NEGPROT response. When RFC 2478 authentication is implemented, CIFS authentication is performed in a separate security layer. There is no minimal set of authentication protocols that a CIFS server must support.
Because the CIFS SMB_COM_SESSION_SETUP_ANDX packet has a size limit, the server response may be fragmented. Reassembly is the responsibility of the security layer called by the CIFS server.
NTLM v1 Authentication
NTLM v1 is a legacy form of challenge-response authentication where the client responds to a server challenge.
Implementing NTLM v1 authentication requires hashing the password and applying a DESL encryption process to the challenge and response.
Passwords are converted from string to binary form, using either a case-sensitive or a case-insensitive algorithm.
In the case-sensitive hashing algorithm, the UNICODE password (in cleartext, without any string termination character) is supplied to an MD4 hashing algorithm. The 128bit value of the MD4 hash is used as the password hash.
Kn = MD4( UNICODE( Password ) )
In the case-insensitive hashing algorithm, the password string is converted to DBCS using a platform-specific conversion table, if the string is in UNICODE format. The password string is then converted to uppercase. If the password string is less than 14 characters, it is padded to 14 characters with zeros.
BYTE Password[ 14 ]; memset( Password, 0, 14 ); strncpy( Password, “Password1”, 14 ); strupr( Password ); // ”Password1” -> “PASSWORD1”
The string “KGS!@#$%” is encrypted by DES in ECB mode. This is performed twice. The first 7 bytes of the password provide the first key, the second seven bytes provide the second key.
key1 = DES( “KGS!@#$%”, Password[0..6] ) key2 = DES( “KGS!@#$%”, Password[7..13] )
The two operations are concatenated, and the resulting 128-bit value is used as the password hash.
Kl = key1 || key2
The server sends a random value, C, to the client. The client performs the following algorithm on the challenge and returns it to the server. The server performs the same operation with its known version of the client password; if the results match, then the client knows the password.
The algorithm encrypts an 8-byte block value with a 16-byte key. For example, where DES (d, k) performs DES encryption in ECB mode, and k is the key:
DESL( D, K ) =
DES( D, K[0..6] ) ||
DES( D, K[7..13] ) ||
DES( D, K[14..15] || {0, 0, 0, 0, 0} )
Given server challenge C, and case sensitive password hash Kn and case-insensitive password hash Kl:
NTRESP = DESL( C, Kn ) LMRESP = DESL( C, Kl )
Share-Level Server Security
Share-level server security is a legacy security method.
A share-level server makes some directory on a disk device (or other resource) available. An optional password may be required to gain access. Thus, any user on the network who knows the name of the server, the name of the resource, and the password has access to the resource. Share-level security servers may use different passwords for the same shared resource. Different passwords allow different levels of access.
Share-level clients do not send SMB_COM_SESSION_SETUP_ANDX requests. Instead, they send SMB_COM_TREE_CONNECT_ANDX requests that include a password, or which use challenge/response authentication to prove that they know a password.
A share-level server returns no useful information in the Uid field. If the server is executing in share-level security mode, the Tid field is used to allow access to the shared resource. If the user is able to perform a successful connection to the server specifying the appropriate netname and password (if any), the resource may be accessed according to the access rights associated with the shared resource. These access rights are the same for all clients that gained access this way.
Some client SMB implementations may not be capable of sending an account name and password to the server.
If the client computer name is identical to an account name known on the server, and if the password supplied or authenticated using challenge/response matches that account password, an implicit user logon is performed using those values. If the above fails, the server may fail the request or assign a default account name of its choice. The value of Uid in subsequent requests by the client will be ignored and all access will be validated assuming the account name selected above.