Compartir a través de

3.2.5.3 Receiving an SMB_COM_SESSION_SETUP_ANDX Response

  • Artículo

The processing of an SMB_COM_SESSION_SETUP_ANDX response is handled as specified in [MS-CIFS] section 3.2.5.3 with the following additions:

Extended Security Authentication

If Client.Connection.ServerCapabilities has the CAP_EXTENDED_SECURITY bit set, then the client MUST reject any SMB_COM_SESSION_SETUP_ANDX responses that do not take the form specified in section 2.2.4.6.2. If the Status field of the SMB header is not STATUS_SUCCESS and is not STATUS_MORE_PROCESSING_REQUIRED, then the authentication has failed and the error code MUST be propagated back to the application that initiated the connection attempt. Otherwise, if there is no entry in Client.Connection.SessionTable for the UID in the response, then one MUST be created with the following additional requirements:

  • Client.Session.SessionUID MUST be set to the UID in the response.

  • Client.Session.AuthenticationState MUST be set to InProgress.

  • Client.Session.UserCredentials MUST be set to the authentication credentials of the user that initiated the authentication attempt.

  • Client.Session.SessionKey MUST be set to zero.

  • Client.Session.SessionKeyState MUST be set to Unavailable.

The client MUST then process the GSS token (the SecurityBlob field of the response with its length given in the SecurityBlobLength field).<95> The client MUST use the configured GSS authentication protocol to obtain the next GSS token for the authentication exchange. Based on the status code received in the response and the result from the GSS authentication protocol, one of the following actions MUST be taken:

  • If the GSS authentication protocol indicates an error, then the error MUST be returned to the calling application that initiated the connection.

  • If the Status field of the response contains STATUS_SUCCESS and the GSS authentication protocol does not indicate an error, then authentication is complete. The Client.Session.AuthenticationState MUST be set to Valid and the Client.Session.SessionKey MUST be set using the value queried from the GSS protocol. For information about how this is calculated for Kerberos authentication via Generic Security Service Application Programming Interface (GSS-API), see [MS-KILE]. The client MUST set Client.Session.SessionKeyState to Available.

  • If the Status field of the response contains STATUS_MORE_PROCESSING_REQUIRED and the GSS authentication protocol did not indicate an error, then the client MUST create an SMB_COM_SESSION_SETUP_ANDX request (section 2.2.4.6.1) with the following parameters:

    • The client MUST set CAP_EXTENDED_SECURITY in the Capabilities field and set SMB_FLAGS2_EXTENDED_SECURITY in the SMB header Flags2 field.

    • The SecurityBlob and SecurityBlobLength fields MUST be set to the output token and its length returned by the GSS protocol.

    • The SMB_Header.UID field MUST be set to the value of the SMB_Header.UID field received in the SMB_COM_SESSION_SETUP_ANDX response.

    • This message MUST be sent to the server, and further processing listed in the remainder of this section is not necessary.

NTLM Authentication

If the CAP_EXTENDED_SECURITY bit in Client.Connection.ServerCapabilities is not set, then the client processes the response.<96> If the Status field of the response does not contain STATUS_SUCCESS, then the client MUST propagate the error to the application that initiated the authentication. The connection MUST remain open for the client to attempt another authentication.

If the Status field of the response contains STATUS_SUCCESS, then authentication was successful. The client associates the returned SMB_Header.UID of the response with this user for further requests, as specified in [MS-CIFS]. The Client.Session.AuthenticationState MUST be set to Valid. If the Client.Session.SessionKey is zero, then the client MUST query the authentication package for the 16-byte session key, as specified in [MS-NLMP], and set Client.Session.SessionKey to the returned value. If Client.Session.SessionKey is non-zero, then the client MUST NOT overwrite the existing session key. The client MUST set Client.Session.SessionKeyState to Available.

Activating Signing

If authentication has completed successfully, Client.Connection.IsSigningActive is FALSE, and the targeted behavior for this connection is signed according to the description in section 3.2.4.2.3, then the client MUST determine whether signing is required to be activated.

To determine whether signing is required to be active, the user security context that completed authentication is verified. If the user that authenticated is a guest or is anonymous, then signing MUST NOT be activated. Guest authentication is indicated by bit zero in the Action field of the SMB_COM_SESSION_SETUP_ANDX response being set. Anonymous authentication is indicated by the fact that no credentials are provided.

If neither of these conditions are true, then the client MUST activate signing as follows:

  • If CAP_EXTENDED_SECURITY is set in Client.Connection.ServerCapabilities, the client MUST use GSS-API to query the session key used in this authentication and store the ExportedSessionKey returned by GSS-API into Client.Connection.SigningSessionKey. The client MUST set Client.Connection.SigningChallengeResponse to NULL.

  • If CAP_EXTENDED_SECURITY is not set in Client.Connection.ServerCapabilities, the client MUST use NTLM to query the session key used in this authentication.

    • For NTLMv1 – the client MUST store SessionBaseKey, returned by the NTOWFv1 function defined in [MS-NLMP] section 3.3.1, into Client.Connection.SigningSessionKey.

    • For NTLMv2 – the client MUST store SessionBaseKey, returned by the NTOWFv2 function defined in [MS-NLMP] section 3.3.2, into Client.Connection.SigningSessionKey.

The client MUST set Client.Connection.SigningChallengeResponse to the challenge response that is sent in the SMB_COM_SESSION_SETUP_ANDX request.

Once these steps are completed, the client MUST verify the signature of this response. The client follows the steps specified in section 3.1.5.1, by passing in a sequence number of one because this is the first signed packet.