3.3.1 Using Kerberos Protocol Extensions [MS-KILE]

This example describes using Kerberos protocol extensions [MS-KILE] to obtain client authentication to connect to an SMB2 share.

Prerequisites

• A file share has been created on an SMB2 server, and the user that initiates the SMB2 client application has been configured for access permissions on the share.

Initial System State

• The user that is running the SMB2 client application has not been authenticated to the Authentication Authority (AA).

Final System State

• The user that is running the SMB2 client application has been authenticated to the AA.

Sequence of Events

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

Negotiating an Authentication Protocol (see section 2.5.5.2)

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

Step 1: When the user tries to access the network share on the SMB2 server, the SMB2 client sends the SMB2 NEGOTIATE Request message ([MS-SMB2] section 2.2.3) to the SMB2 server to negotiate SMB2 capabilities, such as SMB dialects between the SMB2 client and server.

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

The SMB2 client calls the Authentication Client through the GSS-API GSS_Init_sec_context function ([RFC2743] section 2.2.1) to verify the received GSS token and to get the token to prove the SMB2 client's identity to the SMB2 server. The Authentication Client first tries by using the Kerberos protocol to prove the client's identity and to build the security token.

Authenticating an SMB2 Client Identity to a Kerberos Authentication Server (see section 2.5.5.1.1)

The Authentication Client proves the identity of the SMB2 client to the Authentication Authority by using the Kerberos [MS-KILE] protocol to get the service ticket for the SMB2 server.

Step 3: The Authentication Client (Kerberos client) sends a KRB_AS_REQ message ([RFC4120] section 3.1) to the Authentication Authority (Key Distribution Center (KDC)). This message includes the user principal name and a list of supported encryption types in priority order to encrypt the pre-authentication data but does not include the pre-authentication data because its function is to discover the supported encryption types.

Step 4: The KDC checks the user principal name in its account database and the pre-authentication data. If the request message does not contain the pre-authentication data, the KDC responds with an error ([RFC4120] section 3.1.3) and with a list of supported encryption types in its priority order.

Step 5: The Authentication Client sends a KRB_AS_REQ message for a ticket-granting ticket (TGT) with PA-ENC-TIMESTAMP as pre-authentication data to the KDC. The client builds the pre-authentication data by encrypting its timestamp with a secret key derived from the user's password by using an agreed-on encryption method. The client presents its principal name and pre-authentication data in a KRB_AS_REQ message.

Step 6: In response to receiving the KRB_AS_REQ for a TGT, the KDC authenticates the user by checking that the pre-authentication data credentials that are used in the KRB_AS_REQ are the same as those of the user's credentials ([RFC4120] section 3.1) in the account database. The KDC builds the TGT with a PAC ([MS-KILE] section 3.3.5.6.4) that contains group membership information in the authorization_data field of the TGT, generates a KRB_AS_REP message ([RFC4556] section 3.2.2) from the TGT and the session key, and sends the KRB_AS_REP message back to the client.

Authenticating an SMB2 Client Identity to an SMB2 Server (see section 2.5.4.1.1)

Step 7: The Authentication Client sends a KRB_TGS_REQ based on the TGT obtained in step 6 to obtain a service ticket for the SMB2 server. The KRB_TGS_REQ message includes the TGT, the authenticator, and the Service Principal Name (SPN) as cifs/servername.domain, where servername is the actual name of the SMB2 server computer, and domain is the domain or realm of the client computer.

Step 8: The KDC validates the TGT and the authenticator. If these are valid, the KDC returns a service ticket for an SMB2 server and a session key for communication between the SMB2 client and the SMB2 server in a KRB_TGS_REP message.

Step 9: The Authentication Client builds a KRB_AP_REQ message ([RFC4120] section 3.2) with a TGT and the authenticator that is created by encrypting the user name, IP address, and a timestamp with the session key received in step 8. This entire KRB_AP_REQ message, with a MutualRequired flag to indicate that the server authentication is required, is embedded as a KerberosToken in a NegTokenInit message ([RFC4178] section 4.2.1), along with a preferred authentication mechanism, such as krb5, and a list of supported authentication mechanisms, such as krb5, erroneous Kerberos, NegoEx, and NTLM OIDs. This entire NegTokenInit message is enveloped in a GSS-API SPNEGO token and returned to the SMB2 client.

To get a new authenticated session, the SMB2 client sends the SMB2 server an SMB2 SESSION_SETUP Request message ([MS-SMB2] section 2.2.5) with its SecurityMode field set to SMB2_NEGOTIATE_SIGNING_ENABLED. The request message contains a securityBlob field that contains the GSS SPNEGO token that was constructed previously, as well as other capabilities and a security mode.

The SMB2 server calls the Authentication Server on the local machine to verify the client's identity by validating the GSS-API SPNEGO token. The Authentication Server validates the SPNEGO Token contents by calling the GSS_Accept_sec_context function ([RFC2743] section 2.2.2) with the received token. If the validation succeeds, the client identity is proved to the SMB2 server, and the Authentication Server returns the security token to the SMB2 server.

Proving SMB2 server identity to the SMB2 client application (see section 2.5.4.1.2)

Step 10: The SMB2 server generates a signature as described in [MS-SMB2] section 3.1.4.1 and sends the SMB2 client an SMB2 SESSION_SETUP Response message ([MS-SMB2] section 2.2.6). The response contains the signature and the previously received GSS security token, which contains a negTokenResp ([RFC4178] section 4.2.2), which has a KRB_AP_REP message ([RFC4120] section 3.2.4) as its KerberosToken.

The SMB2 client calls the Authentication Client's GSS-API GSS_Init_sec_context function ([RFC2743] section 2.2.1) to verify the GSS token to prove the identity of the SMB2 server and verifies the signature as described in [MS-SMB2] section 3.1.5.1. The Authentication Client verifies the signature and the GSS token as described in [MS-SPNG] and [MS-NEGOEX] and then validates the KRB_AP_REP message. If the validation succeeds, the identity of the server is proven to the SMB2 client.