Ticket-Granting票證

由於 Kerberos 通訊協定 原本是設計，因此使用者的主要金鑰衍生自使用者所提供的密碼。 當使用者登入時，使用者工作站上的 Kerberos 用戶端接受使用者的密碼，並透過單向 雜湊 函式傳遞文字，將其轉換成加密金鑰。 產生的雜湊是使用者 的主要金鑰。 用戶端使用此 主要金鑰 來解密從 KDC 接收的 工作階段金鑰 。

原始 Kerberos 設計的問題在於用戶端每次從 KDC 解密工作階段金鑰時，都需要使用者的主要金鑰。 這表示用戶端必須在每次用戶端/伺服器交換開始時要求使用者輸入密碼，或者用戶端必須將使用者的金鑰儲存在工作站上。 使用者的頻繁中斷太過干擾。 將金鑰儲存在工作站上，可能會危害衍生自使用者密碼的金鑰，這是長期金鑰。

此問題的 Kerberos 通訊協定解決方案是讓用戶端從 KDC 取得暫時金鑰。 此暫存金鑰僅適用于此 登入會話。 當使用者登入時，用戶端會要求 KDC 的票證，就像要求任何其他服務的票證一樣。 KDC 會建立登入工作階段金鑰和特殊伺服器的票證，也就是 KDC 的完整票證授與服務來回應。 登入工作階段金鑰的其中一個複本內嵌在票證中，且票證會以 KDC 的主要金鑰加密。 另一個登入工作階段金鑰的複本會使用衍生自使用者登入密碼的使用者主要金鑰進行加密。 票證和加密工作階段金鑰都會傳送至用戶端。

當用戶端取得 KDC 的回復時，它會使用衍生自使用者密碼的使用者主要金鑰解密登入工作階段金鑰。 用戶端不再需要衍生自使用者密碼的金鑰，因為用戶端現在會使用登入工作階段金鑰來解密它從 KDC 取得的任何伺服器工作階段金鑰複本。 用戶端會將登入工作階段金鑰儲存在其票證快取中，以及 KDC 完整票證授與服務的票證。

完整票證授與服務的票證稱為票證授與票證 (TGT) 。 當用戶端向 KDC 詢問伺服器票證時， 它會以驗證 器訊息和票證的形式呈現認證，在此案例中為 TGT，就如同將認證呈現給任何其他服務一樣。 票證授與服務會開啟 TGT 及其主要金鑰、擷取此用戶端的登入工作階段金鑰，並使用登入工作階段金鑰來加密伺服器的工作階段金鑰複本。