Shulou(Shulou.com)05/31 Report--

In this issue, Xiaobian will bring you about the foundation of Kerberos authentication. The article is rich in content and analyzed and described from a professional perspective. After reading this article, I hope you can gain something.

In Greek mythology Kerberos refers to a three-headed dog guarding the gates of Hell, forbidding any human from entering it. Kerberos is a network authentication protocol designed to provide strong authentication services for client/server applications through a key system. Kerberos is preferred by default in domain environments.

Here is the Kerberos protocol framework:

As you can see from the above figure, there are three important roles in the authentication process: Client, Server, and KDC. Here are a few related terms:

1. Access the Client of the service.

2. Server providing services.

KDC (Key Distribution Center): Key Distribution Center.

KDC is divided into two parts: Authentication Service(AS) and Ticket Granting Service(TGS).

DC (Domain Controller): Domain Controller;AD (Active Directory): Active Directory.

DC has a special user named:krbtgt, which is an account that cannot be logged in. It is automatically created by the system when creating the domain. Its Hash value will be used many times for verification in the whole keranthus authentication.

AD maintains an Account Database. It stores password hashes and whitelists for all users in the domain. Only clients whose account passwords are on the whitelist can apply for TGT.

For a simple chestnut: If the ticket class in Kerberos is compared to an access card, then the Client side is the guest, the Server side is the room, and the KDC is the access control of the community. If a resident wants to enter the community, he needs to have an access card corresponding to the access control. Only by passing the authentication of the access control can he open the access control and enter the community. The whole process is equivalent to a reduced version of Kerberos authentication.

Kerberos detailed authentication process:

When the Client wants to access a service on the Server, it needs to prove its identity to the AS first, and after verification, the AS will issue a TGT. Then the Client proves its identity to the TGS again, and after verification, the TGS will issue a ST. Finally, the Client initiates an authentication request to the Server. This process is divided into three parts:

Interaction between Client and AS

Interaction between Client and TGS

Interaction between Client and Server

1. Interaction between Client and AS 1. Preparation:

After the user enters the account password in the Client, the Client will hash the password, which we call the Master Key.

Request: The Client first sends Authenticator(Authenticator) to the AS of KDC, we call it Authenticator1, in order to ensure that Authenticator1 is only known to itself and KDC, the Client uses its own Master Key to encrypt its body.

It reads:

1)TimeStamp encrypted by ClientMaster Key(NTLM Hash of user).

2)Some information about the Client (info), such as the username.

II. Response:

1. After receiving Authenticator1, AS will search AD for whether the username submitted by Client is in the whitelist, and then query the password of the username, extract the Master key corresponding to Client, decrypt TimeStamp, if it is a legal Timestamp, it proves that the username and password provided by Client exist in AD, and the Timestamp extracted by AS cannot exceed 5 minutes, otherwise AS will directly refuse Client's request.

2. After the TimeStamp is verified, the AS sends the Client a Login Session Key encrypted by the Client's Master Key and a client-server-ticket (TGT). Content of TGT: Logo Session Key and TimeStamp encrypted by Master Key(krbtgt NTLM Hash) in KDC, TGS session key, user information, TGT expiration time.

When the Client passes the AS authentication and successfully gets the TGT, the first step of Kerberos authentication is completed.

You need to understand the Logo Session Key:

What is a Logo Session Key:

That is, temporary session key a,Client initiates an application for TGT to KDC, saying that he wants to access a service on the Server. After receiving the request,KDC will generate a Session Key (SKDC-Client, also known as Login Session Key) for secure communication between the Client and KDC. Here KDC does not save SKDC-Client.

It should be noted that SKDC-Client is a temporary session key, so it has its own life cycle, and TGT and Session are interrelated. When the Login Session Key expires,TGT will also expire.

2. In the second step, there is also a Session Key(temporary session key b), which is used for communication between Client and Server (SServer-Client), where Server will not save SServer-Client.

Interaction between Client and TGS

Client uses TGT to get a server-based Ticket from KDC:

I. Requests:

After the Client decrypts the first part with its own Master key to obtain the Logon Session Key, it carries the TGT to send a request to the TGT. Client is the unopened TGT, which is submitted to TGS as a Client authenticated ticket.

Content of request:

1. TGT: TGT obtained by Client interacting with AS, encrypted by Master Key of KDC.

Authenticator2: The Client uses the Logo Session Key to encrypt it. Authenticator2 is actually some information about the Client and a Timestamp of the current time to prove whether the owner of the TGT is himself.

II. Response-ST(Service Ticket) will be issued after TGS verification:

TGS receives Client request to verify identity:

Before sending the real Ticket to the Client, the TGS checks whether the service requested by the Client exists. If the service exists, it must also determine whether the TGT provided by the Client is issued to it by the AS, so it must be proved by Authenticator2 provided by the Client. Authentication2 is encrypted using the Client's Logo Session Key, which TGS does not store. Therefore, TGS must first decrypt the TGT provided by the Client through its own Master Key(password hash processing of krbtgt) to obtain Client Info and Logo Session Key (SKDC-Client), and then decrypt Authenticator2 through this Logo Session Key to obtain Client Info, and compare the two Client Info to verify the true identity of the other party.

Response content:

After authentication, TGS will generate a Session Key (SServer-Client) encrypted by Logo Session Key (SKDC-Client) for communication between Client and Server, and ST(Service Ticket) encrypted by Master Key of KDC.

1. Session Key between Client and Server encrypted by Logo Session Key

2. ST(Service Ticket) encrypted by Server Master Key. Ticket contains the following contents: Session Key (SServer-Client) Domain Name\Client. Ticket expiration time.

The Client receives the response from TGS, decrypts the first part using the Logo session key, and obtains the Session Key (note the difference between the steps of obtaining the Logo Session Key and the Session Key). With Session Key and ST(Service Ticket), clients can interact directly with servers without having to act as intermediaries through KDC.

Client and Server interaction and two-way authentication:

Server Authentication Client: Client obtains Session Key to access Server by interacting with TGS, and then in order to prove that he is the real owner of ST(Service Ticket), he extracts Authenticator and timestamp, and encrypts it with Session Key. Finally, the encrypted Authenticator3 and ST are sent to the Server as a request packet. A Flag is also included to indicate whether the Client needs two-way authentication.

After receiving the Request, the Server first decrypts the ST with its Master Key(NTLM Hash processing of krbtgt) to obtain the Session Key. Then decrypt Authenticator3 through the decrypted Session Key to verify the identity of the other party. If the authentication is successful, the Client is allowed to access the corresponding resource, otherwise the request is rejected directly.

So far, the server has completed the authentication of the client, but the entire authentication process is not over. The Client then authenticates with the Server to ensure that the Client is not accessing a phishing service.

The Server needs to encrypt the Timestamp decrypted in Authenticator3 again with the Session Key and send it to the Client. The Client then decrypts the cached Session Key. If the Timestamp is exactly the same as the previous one, it can prove that the Server at this time is the Server it wants to access.

This completes the entire Kerberos authentication process.

The above is what the Kerberos authentication basis shared by Xiaobian is. If there is a similar doubt, please refer to the above analysis for understanding. If you want to know more about it, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.