How Kerberos authentication works?

The Kerberos Authentication Process
The Kerberos protocol gets its name from the three-headed dog in Greek mythology. The three components of Kerberos are:
· The client requesting services or authentication.
· The server hosting the services requested by the client.
· A computer that is trusted by the client and server (in this case, a Windows Server 2003 domain controller running the Kerberos Key Distribution Center service).
Kerberos authentication is based on specially formatted data packets known as tickets. In Kerberos, these tickets pass through the network instead of passwords. Transmitting tickets instead of passwords makes the authentication process more resistant to attackers who can intercept the network traffic.
Key Distribution Center
The Key Distribution Center (KDC) maintains a database of account information for all security principals in the domain. The KDC stores a cryptographic key known only to the security principal and the KDC. This key is used in exchanges between the security principal and the KDC and is known as a long term key. The long term key is derived from a user's logon password.
Kerberos authentication process
In a Kerberos environment, the authentication process begins at logon. The following steps describe the Kerberos authentication process:
1. When a user enters a user name and password, the computer sends the user name to the KDC. The KDC contains a master database of unique long term keys for every principal in its realm.
2. The KDC looks up the user's master key (KA), which is based on the user's password. The KDC then creates two items: a session key (SA) to share with the user and a Ticket-Granting Ticket (TGT). The TGT includes a second copy of the SA, the user name, and an expiration time. The KDC encrypts this ticket by using its own master key (KKDC), which only the KDC knows.
Note:
Kerberos implements secret key cryptography, which is different from public key cryptography in that it does not use a public and private key pair.
3. The client computer receives the information from the KDC and runs the user's password through a one-way hashing function, which converts the password into the user's KA. The client computer now has a session key and a TGT so that it can securely communicate with the KDC. The client is now authenticated to the domain and is ready to access other resources in the domain by using the Kerberos protocol.
Important:

When a client receives the session key and TGT from the server, it stores that information in volatile memory and not on the hard disk. Storing the information in the volatile memory and not on the hard disk makes the information more secure, because the information would be lost if the server were physically removed.
4. When a Kerberos client needs to access resources on a server that is a member of the same domain, it contacts the KDC. The client will present its TGT and a timestamp encrypted with the session key that is already shared with the KDC. The KDC decrypts the TGT using its KKDC. The TGT contains the user name and a copy of the SA. The KDC uses the SA to decrypt the timestamp. The KDC can confirm that this request actually comes from the user because only the user can use the SA.
5. Next, the KDC creates a pair of tickets, one for the client and one for the server on which the client needs to access resources. Each ticket contains the name of the user requesting the service, the recipient of the request, a timestamp that declares when the ticket was created, and a time duration that says how long the tickets are valid. Both tickets also contain a new key (KAB) that will be shared between the client and the server so they can securely communicate.
6. The KDC takes the server's ticket and encrypts it using the server master key (KB). Then the KDC nests the server's ticket inside the client's ticket, which also contains the KAB. The KDC encrypts the whole thing using the session key that it shares with the user from the logon process. The KDC then sends all the information to the user.
7. When the user receives the ticket, the user decrypts it using the SA. This exposes the KAB to the client and also exposes the server's ticket. The user cannot read the server's ticket. The user will encrypt the timestamp by using the KAB and send the timestamp and the server's ticket to the server on which the client wants to access resources. When it receives these two items, the server first decrypts its own ticket by using its KB. This permits access to the KAB, which can then decrypt the timestamp from the client.