Kerberos Overview
Ticket Granting Ticket (TGT) - A ticket-granting ticket is an authentication ticket used to request service tickets from the TGS for specific resources from the domain.
Key Distribution Center (KDC) - The Key Distribution Center is a service for issuing TGTs and service tickets that consist of the Authentication Service and the Ticket Granting Service.
Authentication Service (AS) - The Authentication Service issues TGTs to be used by the TGS in the domain to request access to other machines and service tickets.
Ticket Granting Service (TGS) - The Ticket Granting Service takes the TGT and returns a ticket to a machine on the domain.
Service Principal Name (SPN) - A Service Principal Name is an identifier given to a service instance to associate a service instance with a domain service account. Windows requires that services have a domain service account which is why a service needs an SPN set. SPN Format are serviceclass/host:port servicename like, MSSQLSvc/SQLSERVER2.corp. local:1433
KDC Long Term Secret Key (KDC LT Key) - The KDC key is based on the KRBTGT service account. It is used to encrypt the TGT and sign the PAC.
Client Long Term Secret Key (Client LT Key) - The client key is based on the computer or service account. It is used to check the encrypted timestamp and encrypt the session key.
Service Long Term Secret Key (Service LT Key) - The service key is based on the service account. It is used to encrypt the service portion of the service ticket and sign the PAC.
Session Key - Issued by the KDC when a TGT is issued. The user will provide the session key to the KDC along with the TGT when requesting a service ticket.
Privilege Attribute Certificate (PAC) - The PAC holds all of the user’s relevant information, it is sent along with the TGT to the KDC to be signed by the Target LT Key and the KDC LT Key in order to validate the user. The authorization step depends on it.
Kerberos in details
AS-REQ
1.A Kerberos client sends its user ID in a clear-text message to the AS. The message does not include the client’s password, nor its secret key based on the password.
2.The AS checks if the client is in the user database.
AS-REP
3. The AS generates the client secret key for the client by hashing the client’s password. Then, the AS sends two messages to the User. the first message, encrypted by the client secret key, contains the ID of the TGS and TGS session key which a randomly generated session key. the second message is the TGT ticket encrypted by TGS secret key, so it’s contents can only be deciphered by the TGS. it contains client ID, client network address, lifetime, timestamp and the TGS session key.
4. the client decrypt the first message by authentication with his password to obtain the TGS session key.
TGS-REQ
5. the user create two new messages. the first one contains the service that the user want to access. the second is the User Authenticator encrypted by the TGS Session key which contains the user/id. then the server send these two messages along with TGT to the TGS.
6. The TGS first checks the service ID if it is available in their database or not. then the TGS will grab a copy of the service secret key.
7. The TGS will decrypt the TGT which contains the TGS Session key with the TGS secret key. Then the User Authenticator will be decrypted by the TGS Session Key. finally, the TGS will check if the information in TGT matches with the User Authenticator if it match the TGS will add it to its cache.
TGS-REP
8. Then, The TGS will create it own messages and send it back to the user. The first message contains the service ID that the user want to access and the message will be encrypted by TGS Session Key. The second message is the service ticket which will be encrypted by Service Secret Key. it contains the id and name of the service and the user name. Also both messages will contain Service Session Key.
The 2nd part Client <-> Service
9. Since the user has the TGS session key before from the AS, he will decrypt the first message using its key. Now the user has access to the Service Session key. So he will create a User Authenticator Message and encrypted with the Service Session Key. Then he will send both the User Authenticator and the Service Ticket to the Service.
10. Now the steps will happen again. the Service will decrypt the Service Ticket with its key. The it will have access to the Service Session Key to use it to decrypt the User Authenticator. lastly The Service will check the matching between the two messages, if they are it will add the User Authenticator to the its cache and then create a Service Authenticator Message encrypted by the Service Session Key and send it to the user.
11. Finally, the User will decrypt the Service Authenticator using the Service Session Key and validate the service name. The mutual authentication is now complete. The Kerberos client can now start issuing service requests, and the Kerberos service can provide the requested services for the client.
Now, you can see the whole walk-through in one image thanks to DestCert.