Logging on with a Password

Suppose Alice has a network account in the domain named West. The computer she usually uses, Workstation, also has an account in West. When Alice logs on to the network, she begins by pressing the key combination CTRL+ALT+DEL, which is the Secure Attention Sequence (SAS) on computers with a standard Windows 2000 configuration.

In response to the SAS, Winlogon switches to the logon desktop and dispatches to a DLL called the Graphical Identification and Authentication (GINA), a component loaded in Winlogon's process. GINA is responsible for collecting the logon data from the user, packaging it in a data structure, and sending everything to the LSA for verification. Third parties can develop replacement GINAs, but in this case Winlogon has loaded the standard component (MSGINA.dll) supplied with the Windows 2000 operating system. MSGINA displays the standard logon dialog box.

Alice types her user name and password. She selects West from the list of domain names. When she clicks OK to dismiss the dialog box, MSGINA returns her logon information to Winlogon. Winlogon then sends the information to the LSA for validation by calling LsaLogonUser.

Upon receiving a data structure with Alice's logon data, the LSA immediately converts Alice's plaintext password to a secret key by passing it through a one-way hashing function. It saves the result in the credentials cache, where the hashed password can be retrieved when it is needed for encryption and decryption.

To validate Alice's logon information and set up her logon session on the computer, the LSA must obtain the following:

• A TGT that is good for admission to the ticket-granting service.

• A session ticket that is good for admission to the computer.

The LSA gets these tickets by working through the Kerberos SSP, which exchanges messages directly with the domain's KDC, as illustrated in Figure 11.8.

Figure 11.8 Kerberos Exchanges for Logging on Interactively

The messages follow this sequence:

1. The LSA sends a KRB_AS_REQ message to the KDC's authentication service in the domain West.
   The message includes:

   • The user's principal name (Alice).

   • The name of the account domain (West).

   • Preauthentication data encrypted with the secret key derived from Alice's password.

2. The KDC's authentication service replies with a KRB_AS_REP message.
   The message includes:

   • A session key for Alice to share with the KDC, encrypted with the secret key derived from Alice's password.

   • A TGT for the KDC in the domain West, encrypted with the KDC's secret key. The TGT includes a session key for the KDC to share with Alice and authorization data for Alice.

   The authorization data includes the SID for Alice's account, SIDs for security groups in the domain West that include Alice, and SIDs for universal groups in the enterprise that include either Alice or one of her domain groups.

3. The LSA sends a KRB_TGS_REQ message to the KDC's ticket-granting service in the domain West.
   The message includes:

   • The name of the destination computer (Workstation).

   • The name of the destination computer's domain (West).

   • Alice's TGT.

   • An authenticator encrypted with the session key Alice shares with the KDC.

4. The KDC replies with a KRB_TGS_REP message.
   The message includes:

   • A session key for Alice to share with Workstation, encrypted with the session key Alice shares with the KDC.

   • Alice's session ticket to Workstation, encrypted with the secret key Workstation shares with the KDC.

   The session ticket includes a session key for Workstation to share with Alice and authorization data copied from Alice's TGT.

Upon receipt of Alice's session ticket, the LSA decrypts it with the computer's secret key and extracts her authorization data. It then queries the local Security Accounts Manager (SAM) database to determine whether Alice is a member of any security groups local to the computer and whether she has been given any additional user rights on the local computer. It adds any SIDs returned by this query to the list taken from the ticket's authorization data. The entire list is then used to build an access token. A handle to the access token is then returned to Winlogon, along with the identifier for Alice's logon session and confirmation that her logon information is valid.

Winlogon creates a window station and several desktop objects for Alice, attaches her access token, and starts the shell process she will use to interact with the computer. Alice's access token is subsequently inherited by any application process that she starts during her logon session.