3.3.2 Using the NTLM Protocol [MS-NLMP]

When Kerberos authentication fails or is not configured, the Authentication Client tries the NTLM protocol [MS-NLMP] as the next preferred authentication protocol to prove the identity of the SMB2 client to the SMB2 server. This example describes the interactions between the SMB2 client and the SMB2 server when Kerberos is not configured or is unavailable.

Prerequisites

Initial System State

  • Same as section 3.3.1.

Final System State

  • Same as section 3.3.1.

Sequence of Events

Connecting to an SMB2 share with [MS-NLMP] as the authentication protocol

Figure 33: Connecting to an SMB2 share with [MS-NLMP] as the authentication protocol

The SMB2 client and the SMB2 server negotiate the authentication protocol by using the [MS-SPNG] protocol.

Step 1: Same as step 1 in section 3.3.1.

Step 2: The SMB2 server builds an SMB2 NEGOTIATE Response ([MS-SMB2] section 2.2.4) message with a preferred dialect and a securityBlob field with the GSS token by calling the Authentication Server through the GSS-API GSS_Accept_sec_context function, as described in [RFC2743]. The GSS token contains a NegTokenInit2 ([MS-SPNG] section 2.2.1) message, which includes the preferred authentication protocol mechanism as NegoEx OID and a list of supported authentication mechanisms such as NegoEx, krb5, erroneous Kerberos, usertouser, and NLMP OIDs, as specified in [MS-SPNG] section 1.9.1.

Step 3: The SMB2 client calls the GSS-API GSS_Init_sec_context function ([RFC2743] section 2.2.1) of the Authentication Client to verify the received token and also to obtain the new GSS Spnego Token. Next, the Authentication Client builds the GSS token with NTLM as its preferred authentication mechanism and a NEGOTIATE_MESSAGE ([MS-NLMP] section 2.2.1.1) and hands off to the SMB2 client. The SMB2 client creates an SMB2 SESSION_SETUP Request ([MS-SMB2] section 2.2.5) with securityBlob field values as the GSS token and sends it to the SMB2 server.

Step 4: The SMB2 server asks the Authentication Server to validate the GSS token that was received in the preceding step by calling the GSS-API GSS_Accept_sec_context function ([RFC2743] section 2.2.2). The Authentication Server validates the security token and returns the status code that indicates that a subsequent round trip is required. It also builds the GSS Spnego token with a CHALLENGE_MESSAGE ([MS-NLMP] section 2.2.1.2), which is returned to the SMB2 server. The SMB2 server creates an SMB2 SESSION_SETUP Response ([MS-SMB2] section 2.2.6) with the security field value as the GSS token and sends the response to the SMB2 client.

Step 5: The SMB2 client calls the GSS-API GSS_Init_sec_context function ([RFC2743] section 2.2.1) of the Authentication Client to validate the security token that was received in step 4 and to build the subsequent security token. The Authentication Client builds the GSS-API Spnego token with an AUTHENTICATE_MESSAGE ([MS-NLMP] section 2.2.1.3). The SMB2 client creates the SMB2 SESSION_SETUP Request with the GSS token and sends it to the SMB2 server.

Step 6: The SMB2 server calls the GSS-API GSS_Accept_sec_context function ([RFC2743] section 2.2.2) of the Authentication Server to validate the received token and also builds security tokens if required for further communication. To validate the security token, the Authentication Server contacts the Authentication Authority by sending a NETWORK_NETLOGON_INFO message as described in [MS-APDS] section 2.2.1.

Step 7: The Authentication Authority validates the request message and returns either the NETLOGON_VALIDATION_SAM_INFO2 or the NETLOGON_VALIDATION_SAM_INFO4 message with group membership information to the Authentication Server, depending on the processing rules described in [MS-APDS] section 3.1.5.2.

Step 8: The Authentication Server returns the status indicating that authentication is complete to the SMB2 server. The SMB2 server builds the SMB2 SESSION_SETUP Response message and sends it to the SMB2 client.