Show Contents / Index / Search

The Kerberos Authentication Process

Understanding the sequence of events that occurs during Kerberos authentication may help you determine the cause of authentication problems.

  1. A principal requests a service that requires Kerberos authentication. For example, a user starts Reflection (a Telnet client) and requests a Telnet connection to a host named telnserv.com.
  2. The application server (in this case, the Telnet daemon on the host) requests authentication from Reflection.
  3. Reflection checks to see if Kerberos already has a valid ticket-granting ticket (TGT) for this principal. If it doesn't, the Reflection Kerberos client sends a request to the Key Distribution Center (KDC) for a TGT.
  4. The KDC verifies that the principal and realm are valid, and then sends a TGT and a session key to the Reflection Kerberos client.
  5. The Reflection Kerberos client prompts the user for a password. If it matches the password the KDC used to encrypt the TGT and session key, the Reflection Kerberos client can decrypt the message and obtain the session key. (If the password is incorrect, the user sees an error message and authentication fails.)
  6. The Reflection Kerberos client generates the request for the service that the user originally requested (a Telnet connection to telnserv.com), and sends it to the KDC. This request contains the TGT, an authenticator that verifies the principal's identity, and the name of the service the principal wants to use, all encrypted in the session key.
  7. The KDC decrypts the TGT, and then generates a new key for the session between the workstation and the service (in this case, between the Telnet client and the Telnet daemon on telnserv.com), and a service ticket for the Telnet connection to telnserv.com, which is encrypted with the service's secret key. It encrypts this message with the original session key, and returns it to the Reflection Kerberos client.
  8. The Reflection Kerberos client uses the original session key to extract the service ticket and decrypt the new session key. It then returns control to Reflection.
  9. Reflection presents the service ticket to the Telnet daemon. The Telnet daemon verifies the credentials and in turn authenticates itself to Reflection using information it extracted from the service ticket. Since the service ticket was encrypted with the service's secret key, only the service for which the ticket was generated could decrypt the ticket.
  10. Reflection logs in to the host (telnserv.com).