Understanding the sequence of events that occurs during Kerberos authentication may help you determine the cause of authentication problems.
A principal requests a service that requires Kerberos authentication. For example, a user starts the session (a Telnet client) and requests a Telnet connection to a host named telnserv.com.
The application server (in this case, the Telnet daemon on the host) requests authentication from the session.
The Kerberos client checks to see if Kerberos already has a valid ticket-granting ticket (TGT) for this principal. If it doesn't, the Kerberos client sends a request to the Key Distribution Center (KDC) for a TGT.
The KDC verifies that the principal and realm are valid, and then sends a TGT and a session key to the Kerberos client.
The Kerberos client prompts the user for a password. If it matches the password the KDC used to encrypt the TGT and session key, the 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.)
The 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.
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 Kerberos client.
The Kerberos client uses the original session key to extract the service ticket and decrypt the new session key. It then returns control to the session.
The Kerberos client uses presents the service ticket to the Telnet daemon. The Telnet daemon verifies the credentials and in turn authenticates itself to the session 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.
Your session logs in to the host (telnserv.com).