Compartir a través de

3.2.4.2.4 User Authentication

  • Artículo

If Client.Connection.ShareLevelAccessControl is TRUE:<199>

  • Share level access control is required by the server. If no authentication has been performed on the SMB connection, (Client.Connection.SessionTable is empty), the client MUST use anonymous authentication to create a "null session". Application-provided credentials MUST NOT be used.<200>

    The client MUST send only one session setup request. An SMB_COM_SESSION_SETUP_ANDX Request MUST be constructed as specified in section 2.2.4.53.1, with the following additional requirements. In the SMB_Parameters block of the SMB_COM_SESSION_SETUP_ANDX Request:

    • The AccountName field MUST be the empty string.

    • The OEMPassword and UnicodePassword fields MUST be empty (zero length).

  • If the establishment of a null session fails, no further processing is possible. The connection MUST be closed and an implementation-specific error message MUST be returned.

    The use of share level access control is deprecated.<201>

If Client.Connection.ShareLevelAccessControl is FALSE:

  • User level access control is required by the server. The client MUST look up Session from Client.Connection.SessionTable where Session.UserCredentials matches the application-supplied UserCredentials. If a session is found, it MUST be reused. Otherwise, the client MUST create an SMB_COM_SESSION_SETUP_ANDX Request (section 2.2.4.53.1)  and MUST attempt to establish an authenticated session for the user with the application-supplied UserCredentials.

  • Authentication:

    If Client.Connection.ServerChallengeResponse is FALSE and Client.PlaintextAuthenticationPolicy is Disabled, the client SHOULD fail the request with an implementation-dependent error.

    If Client.Connection.ServerChallengeResponse is FALSE and Client.PlaintextAuthenticationPolicy is Enabled, the client MUST use plaintext authentication.

    • If the server supports Unicode (as indicated in Client.Connection.ServerCapabilities) the client MAY send the plaintext password in Unicode. The Unicode password is placed into the UnicodePassword field of the SMB_COM_SESSION_SETUP_ANDX Request as an array of bytes (not a null-terminated string). No alignment padding is used. The UnicodePasswordLen field is set to the length, in bytes, of the Unicode password.

    • If neither the client nor the server supports Unicode, or the client sends the password in OEM character set format, the password is placed into the OEMPassword field of the SMB_COM_SESSION_SETUP_ANDX Request as an array of bytes (not a null-terminated string). The OEMPasswordLen field is set to the length, in bytes, of the password.

      If Client.Connection.ServerChallengeResponse is TRUE, the server can accept challenge/response authentication. The server MAY also accept plaintext authentication. The client MUST determine the authentication type that it uses based upon local configuration (the Client.PlaintextAuthenticationPolicy, Client.LMAuthenticationPolicy, and Client.NTLMAuthenticationPolicy values) in an implementation-specific manner.<202>

      The LAN Manager (LM) response and the LAN Manager version 2 (LMv2) response are mutually exclusive. The implementation MUST select either the LM or the LMv2 response and send it in the OEMPassword field of the SMB_COM_SESSION_SETUP_ANDX Request as an array of bytes (not a null-terminated string). The OEMPasswordLen field MUST be set to the length in bytes of the LM or LMv2 response.

      The NT LAN Manager (NTLM) response and the NT LAN Manager version 2 (NTLMv2) response are mutually exclusive. The implementation MUST select either the NTLM or the NTLMv2 response and send it in the UnicodePassword field of the SMB_COM_SESSION_SETUP_ANDX Request as an array of bytes (not a null-terminated string). The UnicodePasswordLen field MUST be set to the length, in bytes of the NTLM or NTLMv2 response.

      If authentication fails, and the local configuration permits, the client MAY attempt authentication again using alternative response calculations (for example, replacing the LMv2 response with an LM response).<203> If all authentication attempts fail, and no authenticated SMB session exists, the underlying transport connection MUST be closed, and an implementation-specific error MUST be returned to the application.

  • Guest Authentication

    Guest access occurs in one of two ways:

    1. The client logs on as a guest using the normal authentication process.

    2. The client attempts to log on as some other user, but authentication fails. In this case, the server MAY choose to permit access via the guest user account. The Session Setup succeeds, but the SMB_SETUP_GUEST flag of the Action field in the SMB_COM_SESSION_SETUP_ANDX Response MUST be set to indicate guest access (see Session Setup in sections 2.2.4.53.2 and 3.3.5.43).

  • Signing:

    If Client.Connection.IsSigningActive is FALSE and:

    • A failed authentication resulted in guest access (as described above under Guest Authentication option #2), or

    • Authentication was anonymous (resulting in a null session),

      Then signing MUST NOT be enabled for this authentication.

      If the combination of Client.MessageSigningPolicy and Client.Connection.ServerSigningState results in "Messages Signed" in the following table, the client MUST set the Client.Connection.IsSigningActive variable to TRUE and MUST set SMB_FLAGS2_SMB_SECURITY_SIGNATURE to TRUE in the SMB Header of the SMB_COM_SESSION_SETUP_ANDX Request message. Setting this value indicates to the server that signing is requested. Client.Connection.ServerSigningState was initialized during the processing of a negotiation response, as specified in section 3.2.5.2.

      Otherwise, if Client.Connection.IsSigningActive is FALSE and the result is "Blocked" in the following table, the underlying transport connection MUST be closed and an implementation-specific error MUST be returned to the application.

If Client.Connection.IsSigningActive becomes TRUE as a result of the authentication process, Client.Connection.SigningSessionKey and Client.Connection.SigningChallengeResponse MUST be set as specified in section 3.2.5.3.

If authentication succeeds, the newly created Client.Session MUST be inserted into the Client.Connection.SessionTable. The client MUST query the authentication subsystem for the cryptographic session key of the newly authenticated user, as specified in [MS-NLMP], and store it in Client.Session.SessionKey. The client MUST set Client.Session.UserCredentials to the application-supplied UserCredentials.