Three steps to understand Kerberos Protocol easily

Kerberos It's an authentication protocol , It serves as a trusted third-party authentication service , By using symmetric encryption technology for the client / Server applications provide strong authentication . In domain environment ,AD Domain use Kerberos Protocol verification , Be familiar with and master Kerberos Protocol is the basis of learning domain penetration .

Kerberos Three main roles in the protocol ：

1. Access to the service Client2. serviceable Server3.KDC： Key distribution center , It is installed on the domain controller by default     AS： Authentication service     TGS： Ticket granting service 

Kerberos Protocol authentication process ：

The agreement can be divided into three steps ： One is to obtain the bill permit , The second is to obtain service license bills , Third, access to services .

First step ： Get a note permit note

KRB_AS_REQ： Used to direct to KDC request TGT

When the user enters the domain user and password on the client side , The client converts the user's password to hash As an encryption key , Encrypt the timestamp as request credentials .

cipher： Encrypted timestamp , That is, the current time of the client and the user's hash The result of encryption 

KRB_AS_REQ The packets are as follows ：

KRB_AS_REP： Used by KDC Pass on TGT

Upon receipt of the request ,KDC from AD Domain database to find the user's hash Decrypt the timestamp to verify the user's identity . If the timestamp is within the allowed time range , Then it will generate a session key （Session key）, With AS_REP The packet responds .

AS_REP Include information ：

ticket： Use krbtgt hash encryption , Include user name / Session key and expiration time .enc-part： Using the user hash encryption , Contains the session key /TGT Expiration time and random number （ Anti replay ）

KRB_AS_REP The packets are as follows ：

The second step ： Get a service license ticket

KRB_TGS_REQ： Use TGT towards KDC request TGS

The client gets TGT And user key encryption enc-part, Using the user hash Decrypt enc-part Get session key （Session key）, Then use the session key to change the user name / The timestamp is encrypted , Generate authenticator and TGT Send to TGS.

ticket： It's actually a picture of TGT, The client doesn't have  krbtgt hash, So we can't decrypt TGT.

KRB_TGS_REQ The packets are as follows ：

KRB_TGS_REP： adopt KDC Pass on TGS

TGS received KRB_TGS_REQ After the request , Use krbtgt hash Decrypt ticket Get session key （Session key）, Then decrypt it with the session key authenticator Get the user name and timestamp for authentication . After confirming the information , Create a service session key （Service Session key）.

ticket： Encrypt with the corresponding service key , Contains the service session key / user name / Expiration time and other information , It's essentially a piece of ST（Service Ticket）.enc-part： Contains the service session key encrypted with the session key （Service Session key）

KRB_TGS_REP The packets are as follows ：

The third step ： Get services

KRB_AP_REQ： Use TGS, The service authenticates the user

The client already has a valid TGS Can interact with services , Decrypt with session key enc-part, obtain Service session key （Service Session key）, Put the user name / Information such as timestamps uses the service session key （Service Session key） To encrypt , Get new Authentication.

KRB_AP_REP： Used by a service to identify itself to a user

The server receives the request , Use your own hash Decrypt TGS Get the service session key （Service Session key） And authorized user information , Then decrypt it using the service session key Authentication, Compare user names and timestamps , If there are mutual verification marks , The client sends the session key to the encrypted service with a timestamp , The client decrypts the timestamp and verifies the server , And then you start asking for services .