Winlogon/Gina/Kerberos/KDC during Windows logon

Http://topic.csdn.net/t/20060301/15/4585911.html #

Failed. if not properly handled, windows may fail.

During the "Interactive login" process, Winlogon calls the Gina group file to convey the account and password provided by the user to Gina. Gina is responsible for verifying the validity of the account and password, then, the verification result is fed back to the Winlogon program. When talking with winlogon.exe, ginawill first determine the current status of winlogon.exe and then perform different verification tasks based on different statuses. Generally, winlogon.exe has three statuses:

1. logged-on status

As the name suggests, after a user successfully logs on, the user enters the "logged on" status ". In this status, you can perform any operation with control permissions.

2. canceled

After you select the "logout" command in the logged-on status, the user enters the "logged-out status" and displays the Winlogon desktop. Gina displays the logon dialog box or welcome screen.

3. Locked

When the user presses the "win + L" key to lock the computer, it enters the "locked state ". In this status, Gina is responsible for displaying the dialog box for user login. At this time, the user has two options: one is to enter the current user's password and return the "logged-on status"; the other is to enter the Administrator account and password and return the "logged-off status ", however, the status and unsaved data of the original user are lost.

//// The process of logging on to the Local Machine

1. Press CTRL + ALT + DEL.

2. Winlogon detects that the user presses the SAS key and calls Gina. The logon dialog box is displayed for the user to enter the account and password.

3. the user enters the account and password. After confirming, Gina sends the information to LSA for verification.

4. When a user logs on to the local machine, lsa will call the msv1_0.dll verification package to process user information and generate a key, which is compared with the key stored in the SAM Database.

5. If the user is valid after comparison, Sam will send the user's Sid (Security Identifier-Security ID), user group Sid, and other related information to LSA.

6.lsacreate a security token for the received sidinformation, and then send the token and token to winlogon.exe.

7.winlogon.exe completes the entire logon process after a user logs on.

//// Process of logging on to the domain

The verification process for logging on to the domain also has different verification methods for different verification protocols. If the domain controller is Windows NT 4.0, the NTLM authentication protocol is used. The verification process is similar to the previous "login to local machine process, the difference is that the Account Verification is not performed in the local Sam database, but in the domain controller. For Windows 2000 and Windows 2003 domain controllers, generally, the Kerberos V5 protocol is more secure and reliable. To log on to the domain through this protocol, you must prove to the domain controller that your domain account is valid. You must first apply for the TGS (ticket-granting service-ticket granting service) that allows the domain ). After the permission is granted, the user applies for a session ticket for the computer to be logged on, and finally needs to apply for access to the local system service of the computer.

The process is as follows:

1. Press CTRL + ALT + DEL.

2. Winlogon detects that the user presses the SAS key and calls Gina. The logon dialog box is displayed for the user to enter the account and password.

3. Select the domain to be logged on and enter the account and password. After confirming, Gina sends the information entered by the user to LSA for verification.

4. When a user logs on to the local machine, lsa sends the request to the Kerberos authentication package. A hash algorithm is used to generate a key based on user information and store the key in the certificate cache.

5. the Kerberos validators send a verification service request to KDC (Key Distribution Center-Key Distribution Center) that contains user identity information and authentication pre-processing data, it includes the user certificate and hash algorithm encryption time.

6. After KDC receives data, it uses its own key to decrypt the time mark in the request. The user can determine whether the decryption time mark is correct.
7. If the user is valid, KDC will send the user a TGT (ticket-granting ticket -- ticket to authorize the ticket ). The TGT (as_rep) decrypts the user's key, this includes the session key, the name of the user to which the session key points, the maximum life cycle of the ticket, and other data and settings that may be required. The ticket applied by the user is encrypted in the KDC key and attached to as_rep. The authorization data section of TGT contains the SID of the user account, the global group to which the user belongs, and the SID of the general group. Note: The SID returned to the LSA contains the user's access token. The maximum life cycle of a ticket is determined by the Domain Policy. If the ticket exceeds the validity period in the active Session, the user must apply for a new ticket.

8. When a user tries to access resources, the customer system uses the Kerberos TGS request service ticket (tgs_req) of TGT from the domain controller ). Then, TGS sends the service bill (tgs_rep) to the customer. The service ticket is encrypted using the server key. At the same time, the SID is copied from TGT by the Kerberos service to all sub-sequence service tickets contained in the Kerberos service.

9. The customer submits the ticket directly to the network service to be accessed. The service ticket can prove the user's identity and permissions for the service, as well as the user's identity for the service.