第 7 章 SEAM 参考

本章列示属于 SEAM 产品之一部分的许多文件、命令和守候程序。另外，本章提供关于 Kerberos 鉴别系统如何工作的详细的信息。

这是本章中的参考信息的一个列表。

• "SEAM 文件"

• "SEAM 命令"

• "SEAM 守候程序"

• "SEAM 命名法"

• "鉴别系统如何工作"

• "借助 SEAM，获得对一个服务的访问"

• "使用gsscred 表"

SEAM 文件

PAM 配置文件

与 SEAM 一同交付的默认的 PAM 配置文件包括用于处理新的 Kerberized 应用程序的条目。新的文件包括用于鉴别服务、帐户管理、对话管理以及口令管理模块的条目。

对于鉴别模块，新的条目是针对 rlogin、 login、 dtlogin、krlogin、 ktelnet 和 krsh 的。下文显示有此类条目的一个示例。所有这些服务均使用新的 PAM 库，/usr/lib/security/pam_krb5.so.1，来提供 Kerberos 鉴别。

前面三个条目使用 try_first_pass 选项，这请求使用用户的初始口令进行鉴别。使用初始口令是指不提示用户键入另一口令，即使列示了多重机制。

后面三个条目使用 acceptor 选项来避免该 PAM 模块进行获得初始的具有票券授予权的票券的步骤。对于 Kerberized 服务器应用程序，交换业已由应用程序进行，因而不必通过 PAM 进行该步骤。另外还包含有一个 other条目，用作所有未加指定而需要鉴别的条目的默认条目。

# cat /etc/pam.conf
.
.
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

对于帐户管理，dtlogin 拥有一个使用 Kerberos 库的新的条目，如下文所示。包含有一个 other 条目，用以提供一个默认的规则。目前，other 条目并不采取任何动作。

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

/etc/pam.conf 文件中的最后两个条目在如下有示。用于对话管理的 other 条目销毁用户资格。用于口令管理的新的 other 条目选择 Kerberos 库。

other session optional /usr/lib/security/pam_krb5.so.1  
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

SEAM 命令

本节列示 SEAM 产品中所包含的某些命令。

对share 命令的变更

作为对新的 SEAM 命令的补充, SEAM 产品包括对 share 命令的变更，此类变更业已交付给 Solaris 2.6 和 Solaris 7 发行版。三个新的安全模式可以为 share 命令所用:

krb5

选择 Kerberos 鉴别

krb5i

选择带完整性的 Kerberos 鉴别

krb5p

选择带完整性和隐私的 Kerberos 鉴别

当多重模式与 share 命令包含在一起时，如果客户机没有指定一个安全模式的话，就默认使用所列的第一个模式。否则，使用客户机所选的模式。

如果一个使用 Kerberos 模式的装配请求失败，则装配将 none 用作安全模式，继续完成装配。这在 NFS 客户机上的 root 授权对象未经鉴别时经常发生。装配请求可能会成功，但是用户将无法访问文件，除非文件通过 Kerberos 得到鉴别。客户机和服务器之间的任何事务，均要求 Kerberos 鉴别，即使文件系统并非是使用 Kerberos 安全模式进行装配的。

SEAM 守候程序

SEAM 产品上所使用的守候程序列于下表。

SEAM 命名法

下面一节展示 SEAM 文档从头至尾所使用的术语及其定义。为了能够领会许多讨论，必需理解这些术语。

鉴别特定的命名法

下文所讨论的术语，是理解鉴别步骤所必需的。程序员和系统管理员应当熟悉这些术语。

客户机是运行在一个用户的工作站上的软件。运行在客户机上的 SEAM 软件在该步骤过程中发出许多请求，而将该软件的动作从用户区分开来很重要。

术语服务器和服务经常互相换用。为了将其分清，术语服务器 被用来定义 SEAM 软件运行时所在的物理系统。术语服务对应于服务器上所支持的一个具体功能 (例如， ftp 或 nfs)。文档经常将服务器作为一个服务的一部分而加以提及，但是使用这一定义模糊了该术语的意义; 因此，服务器是指物理系统而服务是指软件。

SEAM 产品包括三个类型的密钥。其中一个是私有密钥。该密钥被给予每个用户授权对象，且只为授权对象的用户以及 KDC 所知晓。对于用户授权对象，密钥是基于用户的口令的。对于服务器和服务，密钥则是服务密钥。该密钥所服务的目标与私有密钥相同，但是为服务器和服务所用。第三个类型的密钥是一个对话密钥。这是鉴别服务或票券授予服务所生成的密钥。对话密钥的生成目的是为了在一个客户机和一个服务之间提供安全事务。

票券是一种信息包，用于安全地将用户的身份传递到一个服务器或服务。一个票券只在一个具体服务器上对单独一个客户机和一个具体服务有效。它包含服务的授权对象名称，用户的授权对象名称，用户主机的 IP 地址，一个时戳，以及一个用来定义票券期限的值。票券是借助一个随机对话密钥加以创建的，为客户机和服务所用。一旦一个票券得到创建，其就可以得到重新利用，直到该票券到期。

资格是一种信息包，其中包括一个票券和一个相匹配的对话密钥。用于鉴别一个授权对象的身份。资格经常使用一个私有密钥或服务密钥进行加密，而这取决于为该资格解密的主体。

鉴别符是另一类型的信息。当与一个票券一同使用时，鉴别符就可以用来鉴别用户授权对象。一个鉴别符包括用户的授权对象名称，用户主机的 IP 地址，以及一个时戳。不同于一个票券，一个鉴别符只能使用一次，通常是在请求访问一个服务时。鉴别符是借助针对该客户机和该服务器的对话密钥而进行过加密的。

票券的类型

票券拥有对其如何使用进行管辖的属性。这些属性是在创建之初赋予票券的，但日后您可以修改票券的属性。 (例如，可以将一个票券从 可转发 更改为 已转发)。您可以借助 klist 命令来查看票券属性 (请参见"如何查看票券")。

票券可以通过下列术语中的一个或多个加以描述:

可转发/已转发

可转发票券可以被从一个主机发送到另一主机，而客户机不必重新进行自我鉴别。例如，如果用户 david 在 jennifer 的机器上时获得了一个可转发票券，他就可以登录到他自己的机器，而不必获得一个新的票券 (为了再次鉴别其自己)。 (请参见"示例 - 创建一个票券"，了解可转发票券的一个示例。) 下面是对一个可转发票券和一个 可代理 票券进行比较。

初始

初始 票券是直接发放的一种票券，即并非基于一个具有票券授予权的票券。某些服务，诸如更改口令的应用程序，可能会要求票券标记为 初始，以便确信客户机可以证明其知晓其密钥 - 因为一个 初始 票券指示客户机最近业已进行过自身鉴别 (而不是依赖于一个具有票券授予权的票券，而这有可能业已存在很长一段时间了)。

无效

invalid 票券是一个尚未可用的超期票券。 (请参见超期，在下文。) 其将遭到应用程序服务器的拒绝，直到得到证实。如要得到证实，其就必须在其启动时间已过之后，通过一个 TGS 请求，由客户机提交给 KDC, 其中要设定 VALIDATE 标志。

可超期/超期

超期 票券是一种票券，其在创建之后，直到某个指定的时间才变为有效。此类票券很有用，例如，用于打算在深夜运行的批处理任务，因为该票券如果被偷的话，只有批处理任务运行才可以使用。当一个 超期 票券被发放时，其是作为 无效 发放的，且保持该状态，直到其启动时间已过，且客户机请求由 KDC 加以证实。(请参见无效，在上文。) 超期 票券通常保持有效，一直到具有票券授予权的票券的到期时间; 然而，如果其被标记为 可续延，其期限通常设定为等于具有票券授予权的票券的完整期限的时长。请参见可续延，在下文。

可代理/代理

有时可能有必要让一个授权对象允许一个服务来代表其进行一个操作。 (一个示例可能会是，当一个授权对象请求一个服务在某一第三个主机上运行一个打印任务时。) 服务必须能够具有客户机的身份，但只需为该单一操作这样做。在这种情形下，服务器称作作为客户机的代理行事。代理的授权对象名称必须在票券被创建时得到指定。

可代理 票券类似于 可转发 票券，只不过只对单独一个操作有效，而 可转发 票券授予服务对客户机身份的完全使用权。因而可以将 可转发 票券看作是一种超级代理。

可续延

因为拥有带有很长期限的票券是一个安全隐患，票券可以被指定为 可续延。 可续延 票券拥有两个到期时间: 票券的当前实例到期的时间，以及任意票券的最长期限。如果一个客户机想要继续使用一个票券，则要在第一次到期发生之前对其进行续延。例如，一个票券的有效期可以是一小时，而所有票券拥有一个最长为十小时的期限。如果持有票券的客户机想要将其保留，持续一个小时以上，则其必须在这一小时内进行续延。当一个票券到达最长票券期限时 (10 小时)，其就自动到期且无法加以续延。

如要了解有关如何查看票券来查看其属性的信息，请参见"如何查看票券"。

票券期限

每当一个授权对象获得一个票券，其中包括一个具有票券授予权的票券，票券的期限就被设定为下列期限值中的最小者:

• 通过kinit 的 -l 选项指定的期限值，如果是用 kinit 来获得票券的话

• kdc.conf file 中所指定的最长期限值 (max_life)

• 在 Kerberos 数据库中为提供票券的服务授权对象指定的最长期限值。(如果是 kinit 的情形，则其服务授权对象为 krbtgt/realm)

• 在 Kerberos 数据库中为请求票券的用户授权对象指定的最长期限值。

图形 7-1 显示一个 TGT 的期限是如何确定的，且说明四个期限值是从何处来的。尽管 图形 7-1 显示一个 TGT 的期限是如何确定的，任何授权对象获得一个票券时的基本情况都是一样的。唯一的区别就是， kinit 不提供一个期限值，而提供票券的服务授权对象提供一个最长期限值 (而不是 krbtgt/realm 授权对象)。

图形 7-1 TGT 的期限是如何确定的

可续延票券期限也是由四个值中的最小者确定的，但是使用的却是可续延期限值:

• 通过 kinit 的 -r 选项指定的可续延期限值，如果 kinit 被用来获得或续延票券的话

• kdc.conf 文件中所指定的最长可续延期限值 (max_renewable_life)

• Kerberos 数据库中为提供票券的服务授权对象指定的最长期限可续延值 (如果是 kinit 的情形，则服务授权对象为 krbtgt/realm)

• Kerberos 数据库中为请求票券的用户授权对象指定的最长期限可续延值

授权对象名称

每个票券是通过一个授权对象名称加以识别的。授权对象名称可以识别一个用户或一个服务。下面是多个授权对象名称的示例。

鉴别系统如何工作

如果您可以提供一个证明您的身份的票券和一个与之匹配的对话密钥，应用程序就允许您登录到一个远程系统。对话密钥包含针对具体的用户和正要访问的服务的信息。所有用户第一次登录时， KDC 均为其创建一对票券和对话密钥。票券和与之匹配的对话密钥组成一个资格。使用多重网络服务时，一个用户可能会收集许多资格。用户需要为在一个具体服务器上运行的每个服务拥有一个资格。例如，访问一个名为 boston 的服务器上的 ftp 服务，要求有一个资格，而访问另一服务器上的 ftp 服务，又要求有其自己的资格。

创建和存储资格的步骤是透明的。资格是由发送资格到请求方的 KDC 创建的。资格被收到，就被存储在一个资格高速缓存中。

借助 SEAM，获得对一个服务的访问

一个用户为了能够访问一个具体服务器上的一个具体服务，必须获得两个东西。第一个是一个用于票券授予服务的资格 (即 TGT)。一旦票券授予服务业已为该资格解密，服务就为用户请求访问服务器创建第二个资格。这第二个资格就可以用于请求对服务器上的服务进行访问。服务器成功地为第二个资格解密之后，用户就被给予访问。该步骤在下文有更详细的描述。

为票券授予服务获得一个资格

1. 为了启动鉴别步骤，客户机为一个具体的用户授权对象发送一个请求到鉴别服务器。该请求未经加密就被发送。请求中没有包含安全信息，因而没有必要使用加密。

2. 当请求被鉴别服务收到时，就在 KDC 数据库中检索用户的授权对象名称。如果有一个授权对象与之匹配，鉴别服务就为该授权对象获得私有密钥。鉴别服务然后就生成一个对话密钥，为客户机和票券授予服务所用 (称之为对话密钥 1)，以及一个用于票券授予服务的票券 (票券 1)。该票券也称作具有票券授予权的票券 (TGT)。对话密钥和票券两者均使用用户的私有密钥进行过加密，而信息被发回到客户机。

3. 客户机使用该信息来为对话密钥 1 和票券 1 解密，使用的是针对用户授权对象的私有密钥。因为私有密钥应当只为用户和 KDC 数据库所知晓，包中的信息应当是安全的。客户机将信息存储在资格高速缓存中。

通常在这个过程中，用户被提示录入其口令。如果其所录入的口令与用于建立存储在 KDC 数据库中的私有密钥的那个口令相同，则客户机可以成功地为鉴别服务所发送的信息解密。现在客户机拥有一个资格，可以用于票券授予服务。客户机已作好准备，可以为一个服务器请求一个资格了。

图形 7-2 为票券授予服务获得一个资格

为一个服务器获得一个资格

1. 如要请求对一个具体服务器的访问，一个客户机必须首先业已从鉴别服务，为该服务器获得一个资格 (请参见"为票券授予服务获得一个资格")。然后客户机发送一个请求到票券授予服务，其中包括服务授权对象名称，票券 1, 和一个借助对话密钥 1 加密过的鉴别符。票券 1 原来由鉴别服务使用票券授予服务的服务密钥进行过加密。

2. 因为票券授予服务的服务密钥为票券授予服务所知晓，票券 1 可以得到解密。票券 1 中所包含的信息包括对话密钥 1，因而票券授予服务可以为鉴别符解密。此时此刻，用户授权对象得到票券授予服务的鉴别。

3. 一旦鉴别成功，票券授予服务就为用户授权对象和服务器生成一个对话密钥 (对话密钥 2)，为服务器生成一个票券 (票券 2)。然后使用对话密钥 1，对话密钥 2 和票券 2 进行加密。因为对话密钥 1 只为客户机和票券授予服务所知晓，该信息是安全的，可以跨越网络安全地进行设定。

4. 当客户机接收到该信息包时，它就使用对话密钥 1 为信息解密，而该密钥是其业已存储在资格高速缓存中的。客户机业已获得一个可以用于服务器的资格。现在，客户机已作好准备，可以请求到该服务器上的一个具体服务的访问了。

图形 7-3 为一个服务器获得一个资格

获得到一个具体服务的访问

1. 如要请求到一个具体服务的访问，客户机必须首先业已从鉴别服务器为票券授予服务获得了一个资格，并从票券授予服务获得了一个服务器资格 (请参见"为票券授予服务获得一个资格" 和 "为一个服务器获得一个资格")。客户机可以发送一个请求到服务器，其中包括票券 2 和另一鉴别符。鉴别符是借助对话密钥 2 加密过的。

2. 票券 2 是由票券授予服务借助服务的服务密钥加密过的。因为服务密钥为服务授权对象所知晓，服务可以为票券 2 解密并获得对话密钥 2。然后对话密钥 2 可以用于为鉴别符解密。如果鉴别符成功地得到解密，客户机就被给予对服务的访问了。

图形 7-4 获得对一个具体服务的访问

使用gsscred 表

当一个 NFS 服务器试图识别一个 SEAM 用户时，就使用 gsscred 表。 NFS 服务使用 UNIX ID 来识别用户，而这些 ID 并非用户授权对象或资格的一部分。 gsscred 表提供了一个从 UNIX UID (从口令文件) 到授权对象名称的映射。在 KDC 数据库被植入数据之后，必须创建该表并进行管理。

当一个客户机请求来到时， NFS 服务就试图将授权对象名称映射到一个 UNIX ID。如果映射失败，就问询 gsscred 表。借助 Kerberos_v5 机制，一个 root/hostname授权对象会自动被映射到 UID 0, 且并不问询 gsscred 表。这意味着，无法通过 gsscred 表对 root 进行特殊的重新映射。

将何种机制选用于gsscred表

为 gsscred 表选择正确的机制，这取决于多个因素。

• 您对改善检索时间感兴趣吗?

• 您对提高数据访问安全感兴趣吗?

• 您需要快速地建立文件吗?

这是所有可以选择的后端机制的一个列表，以及对机制优势的一个描述。

文件

gsscred 表被存储在一个文件系统上。一个未经共享的本地文件系统提供了最为安全的后端，因为在表得到创建之后，没有跨越网络进行过传输。该版本的文件建立得最快。

xfn_files

gsscred 表被存储在 /var/fn 文件系统内。该文件系统是否共享两可。所有的 xfn 文件建立起来要花费较长的时间。

xfn_nis

gsscred 表被存储在 NIS 名称空间内。在该文件系统中进行检索并不安全。所有的 xfn 文件建立起来要花费较长的时间。

xfn_nisplus

gsscred 表被存储在 NIS+ 名称空间内。在该文件系统中进行检索并不安全。所有的 xfn 文件建立起来要花费较长的时间。

xfn

gsscred 表被存储在为 xfn 默认的系统内。所有的 xfn 文件建立起来要花费较长的时间。

对于 文件 后端机制，初始检索可能会很慢。对于其它的机制，使用一个名称服务时，初始检索可能会较快。对于所有机制，在数据得到高速缓存之后，检索时间应当大致相同。