3.2.4.2.4 User Authentication
Processing of this event is handled as specified in [MS-CIFS] section 3.2.4.2.4, with the following additions:
If Client.Connection.ShareLevelAccessControl is FALSE:
For each existing Connection to the server in Client.ConnectionTable[ServerName], the client MUST search the Client.Connection.SessionTable for a Session that corresponds to the user that establishes the connection to the share. The client MUST search for a valid Session by either a security context or a UID representing the user.
If a Connection with an existing Session for this user is found, then the client MUST reuse the Session and continue processing.
If none of the existing Connections to the server has a valid Session for this user, the client SHOULD<80> reuse one of the existing Connections identified or established in section 3.2.4.2.1. The client MUST establish a new Session for the user. The user's credentials, typically a username or principal and an associated password or password hash, MUST be stored in Client.Session.UserCredentials.
Signing
The client-global Client.MessageSigningPolicy MUST be compared against the selected Client.Connection.ServerSigningState, as per the following table. If the result is Blocked, the underlying transport connection SHOULD be closed.<81>
Client signing state |
Server signing state |
|||
---|---|---|---|---|
|
Disabled |
Declined |
Enabled |
Required |
Disabled |
Message Unsigned |
Message Unsigned |
Message Unsigned |
Blocked |
Declined |
Message Unsigned |
Message Unsigned |
Message Unsigned |
Message Signed |
Enabled |
Message Unsigned |
Message Unsigned |
Message Signed |
Message Signed |
Required |
Blocked |
Message Signed |
Message Signed |
Message Signed |
If the client's Client.MessageSigningPolicy is "Required", the client MUST set the SMB_FLAGS2_SMB_SECURITY_SIGNATURE_REQUIRED bit in the Flags2 field of the SMB_COM_SESSION_SETUP_ANDX request SMB header to indicate that the client refuses to connect if signing is not used.
Extended Security
If Client.Connection.ServerCapabilities has the CAP_EXTENDED_SECURITY flag set (which indicates that the server supports extended security), then the client MUST construct an SMB_COM_SESSION_SETUP_ANDX request, as specified in section 2.2.4.6.1.
The client MUST do one of the following:
Pass the Client.Connection.GSSNegotiateToken (if valid) to the configured GSS authentication mechanism to obtain a GSS output token for the authentication protocol exchange.<82>
Choose to ignore the Client.Connection.GSSNegotiateToken received from the server, and give an empty input token to the configured GSS authentication protocol to obtain a GSS output token for the authentication protocol exchange.
In either case, the client MUST initiate the GSS authentication protocol via the GSS_Init_sec_context() interface, as specified in [RFC2743], passing in the input Client.Connection.GSSNegotiateToken as previously described, along with the credentials from Client.Session.UserCredentials. The client MUST set the MutualAuth and Delegate options which are specified in [MS-KILE] section 3.2.1.<83>
The client MUST then create an SMB_COM_SESSION_SETUP_ANDX request (section 2.2.4.6.1) message. The client MUST set CAP_EXTENDED_SECURITY in the Capabilities field, SMB_FLAGS2_EXTENDED_SECURITY in the SMB_Header.Flags2 field, the SMB_Data.Bytes.SecurityBlob field to the GSS output token generated by the GSS_Init_sec_context() interface, and the SMB_Parameters.Words.SecurityBlobLength to the length of the GSS output token.