票证类型

票证具有可管理其使用方式的属性。这些属性是在创建票证时指定给票证的，但稍后可修改票证的属性。例如，可将票证从 forwardable 更改为 forwarded。可以使用 klist 命令查看票证属性。请参见查看 Kerberos 票证。

以下一个或多个术语对票证进行了描述：

Forwardable（可转发）/forwarded（已转发）

可转发票证可以从一台主机发送到另一台主机，从而使客户机无需对其自身进行重新验证。例如，如果用户 david 在用户 jennifer 的计算机上时获取了一个可转发票证，则前者可登录到自己的计算机，而不必获取新的票证（从而对自身进行重新验证）。有关可转发票证的示例，请参见示例－创建 Kerberos 票证。

Initial（初始）

初始票证是一种直接颁发的票证，而并非基于票证授予票证的票证。某些服务（如用于更改口令的应用程序）可能会要求将票证标记为初始，以便向这些程序本身确保客户机可知道其私钥。初始票证表明客户机最近已进行了自我验证，而并非依赖于已长期使用的票证授予票证。

Invalid（未生效）

无效票证是一个尚未变为可用的未生效的票证。应用程序服务器会拒绝无效票证，直到其经过验证为止。要进行验证，必须在票证开始时间已过之后由客户机将设置了 VALIDATE 标志的票证放置在票证授予服务请求的 KDC 中。

Postdatable（可以后生效）/postdated（以后生效）

以后生效的票证是一种在其创建之后的某个指定时间之前不会生效的票证。例如，此类票证对于计划在深夜运行的批处理作业非常有用，因为如果该票证被盗，则在运行批处理作业之前，将无法使用该票证。颁发以后生效的票证时，该票证未生效，并在其开始时间已过且客户机请求 KDC 进行验证之前一直保持此状态。通常，以后生效的票证在票证授予票证的到期时间之前会一直有效。但是，如果将以后生效的票证标记为可更新，则通常会将其生命周期设置为等于票证授予票证的整个生命周期的持续时间。

Proxiable（可代理）/proxy（代理）

有时，主体需要允许服务代表其执行操作。创建该票证时，必须指定代理的主体名称。Solaris 发行版不支持可代理票证或代理票证。

可代理票证与可转发票证类似，但前者仅对单个服务有效，而可转发票证授予服务对客户机身份的完全使用权限。因此，可以将可转发票证视为一种超级代理。

Renewable（可更新）

由于拥有很长生命周期的票证存在安全风险，因此可将票证指定为可更新票证。可更新票证具有两个到期时间：票证当前实例的到期时间以及任意票证的最长生命周期（一周）。如果客户机要继续使用票证，则可在第一个到期时间之前更新票证。例如，某个票证的有效期可为一个小时，而所有票证的最长生命周期为 10 个小时。如果持有该票证的客户机要将该票证再保留几个小时，则此客户机必须在有效的小时数内更新票证。如果票证到达最长票证生命周期（10 个小时），则该票证将自动到期且无法更新。

有关如何查看票证属性的信息，请参见查看 Kerberos 票证。

票证生命周期

每当主体获取包括票证授予票证 (Ticket–Granting Ticket, TGT) 在内的票证时，都会将票证的生命周期设置为以下生命周期值中的最小值：

• 通过 kinit 的 -l 选项指定的生命周期值，前提是使用 kinit 获取票证。缺省情况下，kinit 使用最长生命周期值。

• kdc.conf 文件中指定的最长生命周期值 (max_life)。

• Kerberos 数据库中为提供票证的服务主体指定的最长生命周期值。如果使用 kinit，则服务主体为 krbtgt/realm。

• Kerberos 数据库中为请求票证的用户主体指定的最长生命周期值。

图 26–1 说明了如何确定 TGT 的生命周期以及四个生命周期值的来源。虽然该图说明的是如何确定 TGT 的生命周期，但所有主体获取票证时的情况基本相同。唯一的区别在于，kinit 不提供生命周期值，而提供票证的服务主体（非 krbtgt/realm 主体）会提供最长生命周期值。

图 26–1 如何确定 TGT 的生命周期

可更新票证生命周期也是由四个值中的最小值确定的，但是使用的却是可更新的生命周期值，如下所示：

• 通过 kinit 的 -r 选项指定的可更新生命周期值，前提是使用 kinit 获取或更新票证。

• kdc.conf 文件中指定的最长可更新生命周期值 (max_renewable_life)。

• Kerberos 数据库中为提供票证的服务主体指定的最长可更新生命周期值。如果使用 kinit，则服务主体为 krbtgt/realm。

• Kerberos 数据库中为请求票证的用户主体指定的最长可更新生命周期值。

Kerberos 主体名称

每个票证都使用主体名称进行标识。主体名称可以标识用户或服务。以下是一些主体名称的示例：

表 26–4 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 挂载。
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 数据库。