許可證類型

許可證的內容可以監管其使用方式。這些內容是在建立許可證時指派的，不過您可以隨時修改一張許可證的內容。（例如，一張許可證可以由可轉遞的變更為轉遞的的）。您可以利用 klist 指令來檢視許可證的內容（請參見 "如何檢視許可證"）。

許可證可以分為下列幾種﹕

可轉遞/轉遞的

您可以從一個主機將一張可轉遞的許可證送到另一個主機，以免客戶端重新自我辯證。舉例來說，如果使用者 david 在 jennifer 的機器上取得一張可轉遞的許可證，他就可以登入自己的機器，而不需要申請新的許可證（因而再次自我辯證）。（請參見 "範例 - 建立一張許可證" 中可轉遞許可證的範例。）請將一張可轉遞的許可證與下方所示的可代理許可證做一個比較。

初始的

初始的許可證是一張直接核發的許可證，並不以能賦予許可證的許可證為基礎。某些服務，例如變更密碼的應用程式，可以要求將許可證標為初始的，以確保客戶端的確知道其保密性的密鑰內容-因為一張初始的許可證表明了該客戶端最近才經過自我辯證（而非依賴一張可能已經存在有一段時間的能賦予許可證的許可證）。

無效的

無效的許可證是一張尚未生效的遠期許可證。（請參見下方遠期的）它在被驗證之前會被一個應用程式伺服器所拒。要將一張無效的許可證驗證，在生效時間開始以後，客戶端必須將它附在一個 TGS 要求中提交給 KDC，並且設定 VALIDATE 旗標。

可遠期/遠期

遠期的許可證是一張在建立之後某特定時間才會生效的許可證。此種許可證很有用，例如，某些必須夜間才能執行的工作，就算其許可證被偷，也無法在要執行這些工作之前使用此許可證。核發一張遠期的許可證時，其狀態為無效的，一直要到其開始時間 KDC 要求客戶端驗證以後才會生效。（請參見上方無效的）一張遠期的許可證通常在能賦予許可證的許可證截止時間之前都有效。不過如果標明為可更新的話，其壽命通常被設定為與能賦予許可證的許可證的整個壽命一樣長。請參見下方的可更新。

可代理/代理

有時候主管必須允許一項服務來代表它執行某個操作。（例如當一位主管要求一項服務在第三個主機之上執行列印工作時。）這時服務必須成為客戶端的身份，只為了執行那一項單一操作。如此一來，伺服器就會被視為該客戶端的代理。在建立許可證時，必須指定代理的主管名稱。

除了只適用於單一服務之外，可代理許可證類似於一張可轉遞許可證，而可轉遞許可證則會將客戶端的身份整個都賦予代理服務。因此可以將一張可轉遞許可證視為某種超級代理。

可更新

因為壽命太長的許可證會產生安全上的顧慮，因此我們可以將許可證指定為可更新的許可證。一張可更新許可證有兩個截止時間﹕一是目前的許可證實例過期的時間，二是任何許可證的最長壽命。如果一個客戶端想要繼續使用同一張許可證，它可以在第一次截止之前將它更新。例如在一個小時之內有效的許可證，其最長壽命可以高達十個鐘頭。如果持有許可證的客戶端想要使用一個小時以上的話，客戶端必須在一個小時之內更新許可證。當一張許可證到達其最大的許可證壽命（10 小時）之後，會自動過期失效而無法再加以更新。

如需有關如何檢視許可證屬性的資訊，請見 "如何檢視許可證"。

許可證壽命

每當主管取得一張許可證，包括一張能賦予許可證-的許可證時，許可證的壽命會被設定為下列最小的壽命數值﹕

• 使用 kinit 來取得許可證時，kinit 的 -l 選項所指定的壽命值

• kdc.conf 檔案中所指定的最大壽命值 (max_life)

• Kerberos 資料庫中為提供許可證的服務主管所指定的最大壽命值。（在 kinit 一例中，服務主管為 krbtgt/ 範疇）

• Kerberos 資料庫中為要求許可證的使用者主管所指定的最大壽命值。

圖 7-1 會說明應如何決定一張 TGT 的壽命，以及這四種壽命值是如何而來。即使 圖 7-1 已說明一張 TGT 的壽命是如何得出，基本上任何主管取得一張許可證時也是同樣的情況。唯一的不同是 kinit 並不提供一個壽命值，而是由提供許可證的服務主管處取得最大壽命值（而非 krbtgt/ 範疇主管）。

圖 7-1 如何決定一張 TGT 的壽命

可更新許可證的壽命也是由四個數值中最小的一個來決定的，但下面情況則要使用可更新壽命值﹕

• kinit 的 -r 選項所指定之可更新壽命值，如果是以 kinit 來取得或更新許可證的話

• kdc.conf 檔案中指定的最大可更新壽命值 (max_renewable_life)

• Kerberos 資料庫中為提供許可證的服務主管所指定的最大壽命可更新值（在 kinit 一例中，服務主管為 krbtgt/ 範疇）

• Kerberos 資料庫中為要求許可證的使用者主管所指定的最大壽命可更新值

主管名稱

每張許可證都是依據主管的名稱來識別的。主管名稱可以識別一位使用者或是一項服務。以下為數個主管名稱的範例。

表 7-4 主管名稱範例

主管名稱	說明
root/boston.acme.com@ACME.COM	與 NFS 客戶端之上的 root 帳號有關的一位主管。稱為 root 主管，為成功裝載經過辯證的 NFS 所不可或缺。
host/boston.acme.com@ACME.COM	Kerberos化應用程式（如 klist 及 kprop）和服務（如 ftp 及 telnet）所使用的一位主管。稱為主機或服務主管。
username@ACME.COM	一位使用者的主管
username/admin@ACME.COM	一位用來管理 KDC 資料庫的管理主管
ftp/boston.acme.com@ACME.COM	ftp 服務所用的一位主管。可以用它來取代 主機 主管。
K/M@ACME.COM	主密鑰名稱主管。每個主 KDC 都有一個相關的主密鑰名稱主管
kadmin/history@ACME.COM	一位包括用來保存其他主管密碼歷程的密鑰的主管。每個主 KDC 都有一個這種主管。
kadmin/kdc1.acme.com@ACME.COM	一位允許使用 kadmind 來存取 KDC 的主 KDC 伺服器主管
changepw/kdc1.acme.com@ACME.COM	一位允許在變更密碼時存取 KDC 的主 KDC 伺服器主管
krbtgt/ACME.COM@ACME.COM	在生成一張能賦予許可證的許可證時會使用此主管。