How does Windows security authentication work?

Security has been a problem recently, such as Windows authentication, asymmetric encryption, digital certificates, digital signatures, TLS/SSL, and WS-Security. If time permits, I would like to write a series of articles to share and exchange with the majority of users. For many readers, Windows certification is a familiar and unfamiliar topic.

1. Introduction to Kerberos Authentication

Windows authentication protocols include NTLM (nt lan Manager) and Kerberos. The former is mainly used in Windows NT and Windows 2000 Server (or Later) workgroup environments, the latter is mainly used in the Windows 2000 Server (or Later) Domain environment. Kerberos is more efficient and secure than NTLM, and the authentication process is also relatively complex. The Kerberos name comes from Greek mythology and is the name of the Guardian beast in the underworld. Kerberos is a three-headed monster. It is used to name a full authentication protocol because the entire authentication process involves three parties: client, server, and KDC (Key Distribution Center ). In Windows, the role of KDC is played by DC (Domain Controller.

When a user logs on to a host using a domain account and remotely accesses another host in the same domain, how does one perform identity verification (a two-way authentication) on the visitor and the visitor )? This is the scenario that Kerberos needs to solve. Next, I try to introduce the entire Kerberos authentication process in a straightforward language.

Kerberos is actually a Ticket-based authentication method. To access server resources, the client must first purchase a ticket approved by the server. That is to say, the client needs to buy a ticket in advance before accessing the server and wait for the service to pass the ticket. Before that, the client needs to buy a ticket first, but this ticket cannot be purchased directly, and a warrant is required. The client needs to obtain a subscription Certificate in advance before buying a ticket. KDC is available for both the authentication certificate and the admission ticket to the server. The figure on the right shows the entire Kerberos authentication process.

2. How to obtain the "subscription Certificate "?

First, let's take a look at how the client obtains the "subscription certificate ". Here, the warrants have a proprietary name, TGT (Ticket Granting Ticket), while TGT is an important Service of KDC-Authentication Service (KAS: Kerberos Authentication Service ). When a user attempts to log on to a host by entering the domain account and password, the Kerberos service of the local machine sends an authentication request to the authentication service of KDC. The request consists of two parts: the user name in plain text and the Authenticator encrypted to prove the identity of the visitor (I can't find a more appropriate Chinese translation, here, Authenticator can be understood to be limited to verifying the pre-known content of Dual-anti-DDoS, which is equivalent to a contact ID ).

After receiving the request, KDC obtains the user information through AD. The obtained password generates a key to decrypt the Authenticator. If the decrypted content is consistent with the known content, it indicates that the password provided by the request is correct, that is, the real identity of the attacker is determined.

After KAS successfully authenticates the identity of the other party, it will generate a Session Key-Logon Session Key, which is used to ensure the communication security between the user and KDC, and use the secret Key derived from the user's password for encryption. KAS then creates a "subscription Certificate"-TGT for the user. TGT mainly includes user-related information and Logon Session Key. The entire TGT is encrypted by KDC's own Key. Finally, the Logon Session Key and TGT encrypted by different keys are returned to the client. (The above content corresponds to steps 1 and 2 in the flowchart)

3. How can I purchase a "admission ticket" through the "subscription Certificate "?

After the above steps, the client obtains the "subscription credential"-TGT, and Logon Session Key for the purchase of tickets for other hosts in the same domain. It caches the TGT and Logon Session Key locally. If it needs to access the resources of a server, it needs to use this TGT to buy the corresponding admission ticket from KDC. The Ticket here also has a proprietary name-Service Ticket (ST: Service Ticket ).

Specifically, ST is sold through another KDC Service TGS (Ticket Granting Service. The client first sends a ST purchase request to TGS. The request mainly includes the following content: client user name; Authenticator encrypted by the Logon Session Key; TGT and the accessed server (actually a service) name.

After receiving the request, TGS decrypts TGT with its own Key and obtains the Logon Session Key. Then, it decrypts the Authenticator through the Logon Session Key to verify the real identity of the other party.

There are two fundamental aspects of TGS: one is to prevent frequent transmission between the user's password client and KDC from being stolen. The second reason is that the password belongs to the Long Term Key (we generally do not frequently update our own password), so that the security factor of the Key as the encryption Key must be less than the Short Term Key that is frequently changed ). The Short Term Key is the Logon Session Key, which ensures the communication security between the client and KDC.

After TGS authenticates the client, a Session Key-Service Session Key-is generated to ensure secure communication between the client and the server. The Session Key is encrypted using the Logon Session Key. Then sell the ticket to the client-ST. ST mainly includes two aspects: client user information and Service Session Key. The entire ST is encrypted by the secret Key derived from the server password. Finally, two encrypted Service Session keys and ST are returned to the client. (The above content corresponds to Steps 3 and 4 in the flowchart)

4. Admission by ticket

After receiving a TGS reply, the client decrypts the cached Logon Session Key to obtain the Service Session Key. At the same time, it also gets the admission ticket to the server-ST. Then it can use this ST ticket to access the site during service access. The Serivce Session Key and ST will be cached by the client.

However, after receiving the ST, how can the server ensure that it is purchased through TGS instead of forged by itself? This is easy to handle. Do not forget that ST is encrypted by the secret key derived from its own password. The specific operation process is like this. In addition to the ST, the Service request also attaches an Authenticator encrypted by the Service Session Key. After receiving the request, the server first decrypts the ST with the secret Key derived from its own password and extracts the Service Session Key from it. The extracted Service Session Key is used to decrypt the Authenticator, and then the real identity of the client is verified.

In fact, the server has completed the client verification so far, but the entire authentication process has not ended. When it comes to Authentication, many people think that the server only authenticates the client. In fact, in most cases, what we need is Mutual Authentication (Mutual Authentication)-Mutual identity verification between the visitor and the visitor. Now the server can ensure that the client is the user it claims, and the client has not confirmed that it is not accessing a phishing service.

To verify the server on the client, the Service needs to encrypt the decrypted Authenticator with the Service Session Key again and play it to the client. The client decrypts the client with the cached Service Session Key. If the client is identical with the previous content, it can prove that the server you are accessing has the same Service Session Key as the client, this session key is not known to outsiders (the above content corresponds to Steps 5 and 6 in the flowchart)

The above content only describes the general process of Windows Authentication Based on Kerberos, and does not involve some details, such as how to ensure time synchronization and how to defend against Replay Attack. In addition, due to the limited knowledge of the underlying Windows layer, we cannot ensure that all content is completely correct. If there is an error, we will still correct it.