Recently, it has been tossing about security, Windows authentication, asymmetric encryption, digital certificate, digital signature, TLS/SSL, WS-Security and so on. If time permits, I am happy to write a series of articles to share with netizens. For many readers, today's discussion may be a familiar and unfamiliar topic-Windows authentication. Directory 1. Introduction to Kerberos authentication. Admission is by ticket. Introduction to Kerberos authentication There are two Windows authentication protocols, NTLM(NT LAN Manager) and Kerberos. The former is mainly used in Windows NT and Windows 2000 Server (or higher version) workgroup environment, while the latter is mainly used in Windows 2000 Server (or higher version) domain environment. Kerberos is more efficient and safer than NTLM, and the authentication process is relatively complicated. The name Kerberos comes from Greek mythology and is the name of Guardian in the underworld. Kerberos is a three-headed monster. It is used to name a complete authentication protocol because the whole authentication process involves three parties: client, server and KDC (key distribution center). In Windows domain environment, the role of KDC is played by DC (Domain Controller). When a user logs into a host with a domain account and remotely accesses another host in the same domain, how to authenticate the identity of the visitor and the interviewee (this is a two-way authentication)? This is the scenario that Kerberos needs to solve. Next, I will try to introduce the whole process of Kerberos authentication in a more straightforward language. Kerberos is actually a ticket-based authentication method. In order to access the resources of the server, the client needs to buy the bill approved by the server first. In other words, the client needs to buy tickets in advance before accessing the server and wait for the service to check the tickets before entering the venue. Before this, customers need to buy tickets first, but this ticket cannot be purchased directly, and they need to subscribe for warrants. Customers need to get a subscription warrant in advance before buying tickets. KDC sells the subscription warrants and admission tickets for this server. The figure on the right (click to enlarge) basically reveals the whole authentication process of Kerberos. Second, how to obtain the "warrants"? First of all, let's look at how the client obtained the "warrant". The subscription certificate here has a proper name-TGT (ticket granting ticket), which is an important service of KDC-KAS (Kerberos authentication service). When a user attempts to log in to a host by entering a domain account and password, the Kerberos service of the machine will send an authentication request to the authentication service of KDC. The request mainly includes two parts, the user name in plaintext and the encrypted authenticator used to prove the identity of the visitor (I really can't find a more suitable Chinese translation, and the authenticator here can be understood as only verifying what the double counter knows in advance, which is equivalent to the contact code). When KDC receives the request, it obtains the user's information through AD. A key is generated from the obtained cryptographic information to decrypt the authenticator. If the decrypted content is consistent with the known content, it proves that the requested password is correct, that is, the real identity of the login is determined. After successfully authenticating the identity of the other party, Mr. Xu generated a session key-login session key to ensure the communication security between the user and, and encrypted it with a key derived from the user password. Then, KAS created a "subscription warrant" for user TGT. TGT mainly includes two aspects: user-related information and login session key, and the whole TGT is encrypted with KDC's own key. Finally, the login session key and TGT encrypted by different keys are returned to the client. (The above contents correspond to steps 1 and 2 in the flowchart. 3. How to purchase the Admission Ticket through the Subscription Warrant? After completing the above steps, the client obtains "subscription credentials"-TGT and login session key, which are used to purchase air tickets of other hosts in the same domain, and caches the TGT and login session key locally. If it needs to access the resources of a server now, it needs to use this TGT to buy the corresponding tickets from KDC. The admission ticket here also has a proper noun-service ticket (ST). Specifically, ST is sold through another service of TGS KDC (ticket granting service). The client first sends a st purchase request to TGS, which mainly includes the following contents: the user name of the client; Authenticator; Encrypted by the login session key; TGT and the name of the visited server (actually the service). After receiving the request, TGS now decrypts TGT through its own key to obtain the login session key, and then decrypts the authenticator through the login session key to verify the real identity of the other party. TGS has two fundamental purposes: First, to avoid frequent transmission and theft of users' passwords between clients and KDC. Secondly, because passwords belong to long-term keys (we generally don't update our passwords frequently), the security factor of using them as encryption keys is definitely less than that of short-term keys that change frequently. This short-term key is the login session key, which ensures the communication security between the client and KDC. After TGS completes the authentication of the client, it will generate a session key-service session key to ensure the communication security between the client and the server. The session key is encrypted by the login session key. Then sell the tickets to the client-ST. ST mainly includes two aspects: client user information and service session key, and the whole ST is encrypted by the key derived from the server password. Finally, two encrypted service session keys and ST are returned to the client. (The above contents correspond to steps 3 and 4 in the flowchart) 4. After receiving the TGS reply, the ticket admission client decrypts the cached login session key to obtain the business session key. At the same time, it also got a ticket to enter the server-ST. Then it can use this ST ticket to enter when making a service visit. The client will cache the service session key and ST. However, after receiving ST, how can the server ensure that it is purchased through TGS and not forged by itself? This is easy to handle. Don't forget that ST is encrypted with a key derived from your own password. The specific operation process is as follows: in addition to ST, the service request is accompanied by an authenticator encrypted by the service session key. After receiving the request, the server decrypts st with the secret key derived from its own password and extracts the service session key from it. Then, the authenticator is decrypted by the extracted service session key, and the real identity of the client is verified. In fact, so far, the server has completed the authentication of the client, but the whole authentication process is not over yet. When it comes to authentication, many people think that it is only authentication between the server and the client. In fact, in most cases, what we need is mutual authentication-visitors and interviewees verify each other's identity. Now the server can ensure that the client is who it claims to be and that the client has not confirmed that it is not a phishing service. In order to solve the authentication of the client to the server, the service needs to encrypt the decrypted authenticator again with the service session key and play it to the client. The client decrypts with the cached service session key. If it is exactly the same as the previous content, you can prove that the server you are accessing has the same service session key as yourself. This session key is unknown to outsiders (the above content corresponds to steps 5 and 6 in the flowchart). The above content only tells the general process of Windows authentication based on Kerberos, and does not involve some details, such as how to ensure the synchronization of time and how to resist replay attacks. In addition, due to the limited underlying knowledge of Windows, it is impossible to guarantee that all contents are completely correct. If there are any mistakes, please do not hesitate to correct them. How does Windows security authentication work? [NTLM]