3.2.1 Interactive Domain Logon by Using Passwords
This example describes interactive logon by using a password to obtain a service ticket. It covers the use cases Authenticate User or Computer Identity Using Username and Password (section 2.5.5.1.1) and Interactive Domain Logon: Service Ticket for Client Computer (section 2.5.3.1.1).
Prerequisites
The Authentication Authority (AA) is available.
The user account is provisioned in the account database.
Initial System State
The user has not been authenticated to the AA.
The Authentication Client does not have a service ticket for the client computer.
Final System State
The AA has interactively authenticated the user, and the Authentication Client has obtained a service ticket for the client computer.
Sequence of Events
Figure 30: Interactive domain logon that uses passwords
Authentication of User Identity to Authentication Authority by Using Kerberos (see section 2.5.5.1.1)
Step 1: The logon attempt is made through the Kerberos protocol. The Authentication Client (the Kerberos client) sends a KRB_AS_REQ message ([RFC4120] section 3.1) to the Authentication Authority (the Key Distribution Center (KDC)). This message includes the user principal name and a list of supported encryption types in preferred priority order. This message does not include the pre-authentication data because its function is to discover the supported encryption types.
Step 2: The KDC checks the user principal name in its account database. Because the request message does not contain the pre-authentication data, the KDC responds with an error ([RFC4120] section 3.1.3) and also with a list supported encryption types in its priority order.
Step 3: 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 one of the commonly supported encryption methods.
Step 4: In response to receiving the KRB_AS_REQ message for a TGT, the KDC authenticates the user by checking the pre-authentication data and ensuring that the 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 privilege attribute certificate (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 from the TGT and the session key, and sends the KRB_AS_REP message back to the client.
Service Ticket for Client Computer (see section 2.5.3.1.1)
Step 5: The client sends a KRB_TGS_REQ message ([RFC4120] section 3.3) based on the TGT from step 4 to obtain a service ticket for the target computer. The client presents the TGT, the authenticator, and the service principal name (SPN) as host/hostname.domain, where hostname is the actual name of the client computer, and domain is the domain or realm of the client computer.
Step 6: The KDC validates the TGT and the authenticator. If these are valid, the KDC returns a service ticket for a client computer in a KRB_TGS_REP message with user logon information.
The client validates the KRB_TGS_REP message ([MS-KILE] section 3.3.4). If KRB_TGS_REP is valid, then the Kerberos runtime interprets the service ticket within the local client computer.