票证类型
票证具有可管理其使用方式的属性。这些属性在创建票证时指定，但之后亦可修改。例如，可将票证从 forwardable 改为 forwarded。可以使用 klist 命令查看票证属性。请参见查看 Kerberos 票证。
以下一个或多个术语对票证进行了描述：
- Forwardable（可转发）/forwarded（已转发）
可转发票证可以从一台主机发送到另一台主机，从而使客户机无需对自身进行重新验证。例如，如果用户 david 登录到用户 jennifer 的计算机时获取了一张可转发票证，则 david 不必获取新的票证（从而对自身进行重新验证）即可登录到自己的计算机。有关可转发票证的示例，请参见Example 6–1。
- Initial（初始）
初始票证是一种直接颁发的票证，而并非基于票证授予票证的票证。某些服务（如用于更改口令的应用程序）可能会要求将票证标记为 "initial"（初始），以便确保客户机可证明其知道密钥。初始票证表明客户机最近已进行了自我验证，而并非依赖于较旧的票证授予票证。
- Invalid（无效）
无效票证是一个尚不可用的以后生效票证。应用服务器会拒绝无效票证，直到其通过验证为止。要进行验证，必须在票证开始时间已过之后由客户机将设置了 –VALIDATE 标志的票证放置在票证授予服务请求的 KDC 中。
- Postdatable（可以后生效）/postdated（以后生效）
以后生效的票证是一种在其创建之后的某个指定时间之前不会生效的票证。例如，此类票证对于计划在深夜运行的批处理作业非常有用，因为如果该票证被盗，则在运行批处理作业之前无法使用该票证。颁发以后生效的票证时，该票证尚未生效，且在其开始时间已过且客户机请求 KDC 进行验证之前一直保持此状态。通常，以后生效的票证在票证授予票证的截止时间之前会一直有效。但是，如果将以后生效的票证标记为可更新，则通常会将其生命周期设置为等于票证授予票证的整个生命周期的持续时间。
- Proxiable（可代理）/proxy（代理）
有时，主体可能需要允许服务代表其执行操作。创建该票证时，必须指定代理的主体名称。Oracle Solaris 不支持可代理票证或代理票证。
代理票证与可转发票证类似，但前者仅对单个服务有效。而可转发票证会向服务授予对客户机身份的完全使用权限。因此，可以将可转发票证视为一种超级代理。
- Renewable（可更新）
由于具有较长生命周期的票证存在安全风险，因此可将票证指定为可更新。可更新票证具有两个截止时间：票证当前实例的截止时间，以及任意票证的最长生命周期（一周）。如果客户机要继续使用票证，则可在第一个截止时间之前更新票证。例如，假设某个票证的有效期为一小时，而所有票证的最长生命周期为 10 小时。如果持有该票证的客户机要将该票证再保留几个小时，则此客户机必须在有效的小时数内更新票证。如果票证到达最长票证生命周期（10 个小时），则该票证将自动过期且无法更新。
有关如何查看票证属性的信息，请参见查看 Kerberos 票证。
票证生命周期
通过 kinit 的 –l 选项指定的生命周期值，前提是使用 kinit 获取票证。缺省情况下，kinit 使用最长生命周期值。
Kerberos 数据库中为提供票证的服务主体指定的最长生命周期值。如果使用 kinit，则服务主体为 krbtgt/realm。
Kerberos 数据库中为请求票证的用户主体指定的最长生命周期值。
当主体获取票证（包括票证授予票证 (Ticket Granting Ticket, TGT)）时，都会将票证的生命周期设置为以下生命周期值中的最小值：
下图显示了 TGT 生命周期的确定方法以及生命周期值的四个来源。当任何主体获取票证时，将以相似方式确定该票证的生命周期。有两处区别：kinit 不提供生命周期值，而提供票证的服务主体（而不是 krbtgt/realm 主体）会提供最长生命周期值。
图 7-1 如何确定 TGT 的生命周期
当使用 kinit 获取或更新票证时，通过 kinit 的 –r 选项指定的可更新生命周期值。
Kerberos 数据库中为提供票证的服务主体指定的最长可更新生命周期值。如果使用 kinit，则服务主体为 krbtgt/realm。
Kerberos 数据库中为请求票证的用户主体指定的最长可更新生命周期值。
可更新票证的生命周期根据四个可更新生命周期值的最小值确定，如下所示：
Kerberos 主体名称
每张票证都以主体名称标识。主体名称可以标识用户或服务。以下示例显示了典型的主体名称：
- changepw/kdc1.example.com@EXAMPLE.COM
更改口令时，允许访问 KDC 的主 KDC 服务器的主体。
- clntconfig/admin@EXAMPLE.COM
kclient 安装实用程序使用的主体。
- ftp/boston.example.com@EXAMPLE.COM
ftp 服务使用的主体。此主体可用于替代 host 主体。
- host/boston.example.com @EXAMPLE.COM
基于 Kerberos 的应用程序（如 klist 和 kprop）和服务（如 ftp 和 telnet）使用的主体。此主体称为 host 或服务主体，用于验证 NFS 挂载。客户机也会使用该主体验证 TGT 是否是从正确的 KDC 颁发给客户机的。
- K/M@EXAMPLE.COM
主密钥名称主体。一个主密钥名称主体可与每个主 KDC 关联。
- kadmin/history@EXAMPLE.COM
一种主体，其中包含用于保存其他主体的口令历史记录的密钥。每个主 KDC 都具有一个这样的主体。
- kadmin/kdc1.example.com@EXAMPLE.COM
允许使用 kadmind 访问 KDC 的主 KDC 服务器的主体。
- kadmin/changepw.example.com @EXAMPLE.COM
一种主体，用于接收来自未运行 Solaris 发行版的客户机的口令更改请求。
- krbtgt/EXAMPLE.COM@EXAMPLE.COM
生成票证授予票证时使用的主体。
- krbtgt/EAST.EXAMPLE.COM@WEST.EXAMPLE.COM
此主体是跨领域的票证授予票证的示例。
- nfs/boston.example.com@EXAMPLE.COM
NFS 服务使用的主体。此主体可用于替代 host 主体。
- root/boston.example.com @EXAMPLE.COM
与客户机上的 root 帐户关联的主体。该主体称为 root 主体，向已挂载 NFS 的文件系统提供 root 访问权限。
- username@EXAMPLE.COM
用户的主体。
- username/admin@EXAMPLE.COM
admin 主体，可用于管理 KDC 数据库。