How Kerberos Authentication Works

- It works in a client/server model

- SSO open-standards protocol for authentication in a single security domain.

- Authentication protocol that uses symetric key encryption in three key pairs

- Two authentication pairs are shared by the authenticator and a single principal and one session pair is shared between principals.

- The session-key pair is distributed in such a way that principals are required to trust the authenticator than each other.

- Every user shares a unique, secret key based on password with KDC.

- Each available service (object) in the system also shares a unique key with the KDC.

  1. To sign-on, the user sends the pw through the Kerberos client software on the workstation to the KDC.
  2. The authentication server of the KDC searches the KDC DB to verify that the user is permitted access to the requested service, and sends an encrypted ticket to the user which includes the UserID, the session key, and the ticket for access to the requested service (object), encrypted with the key the object shares with the KDC.
  3. The Kerberos client on the user workstation receives the ticket and request the user´s pw. This is converted to the user´s key and used to decrypt the user´s part of the authentication-server reply.
  4. If the decryption succeeds, the user is authenticated and when ready, sends the ticket containg the ClientID and session key, encrypted with the key the object shares with the authentications server, to the appl server with a request for service.
  5. Using the key it shares with the KDC, the appl server decrypts the ticket.
  6. If the decryption is successful, because of its trust relationship with the KDC, the object now knows the identity of the user, has the session key, and can conduct encrypted communications sessions with the client.
  7. Alternatively, if the client is going to need repeated services during the day, the client will request a TGT (Ticket Granting Ticket) from the authetication server that will enable it to deal directly with the TGS (Ticket Granting Server) to obtain a ticket without further interaction with the authentication server.
KDC - It provides an authentication service, as well as key distribution functionality. It works as both an AS (Authentication Server) and TGS.

The AS authenticates a principal via a pre-exchanged Secret Key based on the user´s pw that is shared with the KDC and stored in the KDC DB.

After receiving a request for service from the user, all further transmissions with the user´s worksation are encrypted using this shared key.

Authentication occurs when the Kerberos software on the user´s authentication request the pw to created a shared key to decrypt the ticket from AS.

The ticket contains the session key necessary to communicate with the desired appl server. This ensures that if the wrong pw is supplied, the ticket can´t be decrypted and the access attempt fails.

The TGS provides a continuous means of obtaining additional tickets for the same or other appls after the initial authentication by the AS.


Lifetime- Tickets have a lifetime of a day or less. Lifetimes for authentication credentials shoud be as shor as feasible and should use time stamps to minimize the threat of replayed credentials.

The KDC must be physically secured.

Redundant authentication servers are strongly recommended.

The KDC should be hardened and should not allow any non-Kerberos network activity


The security domain over which the KDC has control is called the Realm. Symmetric keys between realms can be a scalability issue.

Many Kerberos implementations are built for single factor (pw only) authentication, which may be inadequate for some situations. Kerberos based on smart card logon (PKI) is the (expensive) solution to this problem.

  1. User authenticate to AS
  2. AS sends initial ticket to user
  3. User requests to access file server
  4. TGS creates a new ticket with sessions keys
  5. User extracts one session key and sends ticket to service server (file, print)