使用 SERVER 选项进行身份验证
DB2 catalog database db_name at node node_nameauthentication auth_type |
使用 SERVER 选项时，用户 ID 和口令将发送到服务器进行校验。考虑以下示例。
图2
1、用户使用用户名 peter 和口令 peterpwd 登录到工作站。
2、peter 随后使用用户 ID db2user 和口令 db2pwd 连接到 SAMPLE 数据库，这是在远程 DB2 服务器上定义的。
3、db2user 和 db2pwd 通过网络发送到服务器。
4、db2user 和 db2pwd 在 DB2 服务器上校验。
若您想保护用户 ID 和口令免于被窃听，可使用身份验证类型 SERVER_ENCRYPT，这样用户 ID 和口令就都会被加密。
使用 Kerberos 进行身份验证
Kerberos 是一种外部安全性设施，它使用通用密码术创建共享的加密密钥。Kerberos 提供了安全的身份验证机制，这是因为用户 ID 和口令不再需要以明文形式通过网络传输。通过使用加密密钥，它使单点登录到远程 DB2 服务器成为可能。以下示意图展示了 Kerberos 身份验证在 DB2 中的工作原理。
图3
DB2 客户机和服务器均支持 Kerberos 安全协议时，即可使用 KERBEROS 身份验证类型。某些客户机可能并不支持 Kerberos，但依然需要访问 DB2 服务器。为确保所有类型的客户机均能安全地连接，将 DB2 服务器的身份验证类型设置为 KRB_SERVER_ENCRYPT。这将允许所有启用了 Kerberos 的客户机使用 Kerberos 进行身份验证，而其他客户机则使用 SERVER_ENCRYPT 身份验证。下面给出了与 Kerberos 相关的不同的客户机与服务器身份验证设置摘要。
图4
在客户机上进行身份验证
这一选项允许在客户机上进行身份验证。用户成功登录到客户机后，即可轻松连接到数据库，而无需再次提供口令。
图5
这里有一个重要问题需要理解：存在不具有可靠的安全性设施的客户机系统，例如 Windows 9x 和 Classic Mac OS。它们叫做不受信任的客户机。任何人只要可以访问这些系统，就可以不经过身份验证直接连接到 DB2 服务器。谁知道他们会执行怎样的破坏性操作(例如，删除一个数据库)?为提供允许受信任的客户机自行执行身份验证、同时强制不受信任的客户机在服务器处进行身份验证的灵活性，引入了另外两种数据库管理器配置参数：
TRUST_ALLCLNTS TRUST_CLNTAUTH |
这两个参数仅在身份验证设置为 CLIENT 时被评估。DB2
信任客户机
TRUST_ALLCLNTS 确定信任哪种类型的客户机。参数有以下可能值：
◆YES
信任所有客户机。这是默认设置。身份验证将在客户机处执行。但有一个例外，我们将在介绍 TRUST_CLNTAUTH 时更详细地予以讨论。
◆NO
仅信任具备可靠的安全性设施的客户机(受信任的客户机)。若不受信任的客户机连接，则必须提供用户 ID 和口令，以便在服务器进行身份验证。
◆DRDAONLY
仅信任在 iSeries 或 zSeries 平台上运行的客户机(例如，DRDA 客户机)。其他任何客户机都必须提供用户 ID 和口令。
设想一个场景，DB2 服务器将身份验证设置为 CLIENT、TRUST_ALLCLNTS 设置为 YES。您作为 localuser 登录到一台 Windows 2000 计算机，并在未指定用户 ID 和口令的情况下连接到远程数据库。那么 localuser 将成为数据库处的连接授权 ID。而如果您想使用其他用户 ID 连接到数据库(例如，有执行数据库备份权限的 poweruser)，又会怎么样呢?
为允许此类行为，可使用 TRUST_CLNTAUTH 来指定，当在 connect 语句或 attach 命令中提供了用户 ID 和密码时将在何处进行身份验证。允许使用的值有两个：
◆CLIENT
身份验证在客户机处执行，不需要用户 ID 和口令。
◆SERVER
身份验证在服务器处完成，需要提供用户 ID 和口令。
让我们来看一些演示参数用法的示例：
图6