Ticket-Granting 票證

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

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

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

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

完整票證授權服務的票證稱為票證授與票證（TGT）。 當用戶端向 KDC 請求伺服器票證時，它會以驗證訊息和票證的形式提交 憑證，在這個案例中是一個 TGT，就像將憑證提交給其他任何服務一樣。 票證授與服務會使用其主要密鑰開啟 TGT、擷取此用戶端的登入會話密鑰，並使用登入會話密鑰來加密伺服器的會話金鑰複本。