访问实例或数据库首先要求认证用户。每个实例的认证类型确定对用户进行验证的方式和位置。
认证类型存储在服务器上的配置文件中。它是在创建实例时进行的初始设置。每个实例都有一个认证类型，该类型控制对数据库服务器和该服务器控制下的所有数据库的访问。
如果打算从联合数据库访问数据源，必须考虑数据源认证处理和联合认证类型的定义。
在显式可信连接上切换用户
对于 CLI/ODBC 和 XA CLI/ODBC 应用程序，在处理需要认证的切换用户请求时使用的认证机制与最初建立可信连接本身时使用的机制相同。因此，对于显式可信连接上的切换用户请求所需的任何认证来说，在建立该可信连接时使用的任何其他协商安全属性（例如，加密算法、加密密钥和插件名称）都相同。通过使用数据源属性，JAVA 应用程序允许对切换用户请求更改认证方法。
因为可以定义可信上下文对象以便在可信连接上切换用户
不需要认证，所以为了充分利用显式可信连接上的切换用户功能，用户编写的安全插件必须能够：
- 接受仅用户标识标记
- 对该用户标识返回有效的 DB2 授权标识
注： 如果 CLIENT 类型的认证有效，那么不能建立显式可信连接。
提供的认证类型
提供了下列认证类型：
- SERVER
- 指定在服务器上通过对于该配置有效的安全性机制（例如，通过安全插件模块）进行认证。缺省安全性机制是：如果在尝试连接期间指定了用户标识和密码，那么会将它们发送至服务器并在服务器上将它们与有效用户标识和密码组合比较，以确定是否允许该用户访问实例。
注： 服务器代码检测一个连接是本地连接还是远程连接。对于本地连接，当认证类型是 SERVER 时，不需用户标识和密码就可认证成功。
- SERVER_ENCRYPT
- 指定服务器接受加密的 SERVER 认证方案。如果未指定客户机认证，使用在服务器中选择的方法认证客户机。当用户标识和密码通过网络从客户机发送至服务器时，它们处于已加密状态。
当客户机与服务器之间协商产生的认证方法为
SERVER_ENCRYPT 时，可以选择通过使用 AES（高级加密标准）256 位算法来对用户标识和密码进行加密。为此，请设置数据库管理器配置参数
alternate_auth_enc。此配置参数具有以下三项设置：
- NOT_SPECIFIED（缺省值）表示服务器接受客户机建议的加密算法，其中包括 AES 256 位算法。
- AES_CMP 表示当连接的客户机建议使用 DES 但支持
AES 加密时，服务器会重新协商以便使用 AES 加密。
- AES_ONLY 表示服务器仅接受 AES 加密。如果客户机不支持 AES 加密，那么连接会被拒绝。
仅当客户机与服务器之间协商的认证方法为
SERVER_ENCRYPT 时，才能使用 AES 加密。
- CLIENT
- 指定使用操作系统安全性在调用应用程序所在的数据库分区上执行认证。在客户机节点上，将在尝试连接期间指定的用户标识和密码与有效的用户标识和密码的组合比较，以确定是否允许此用户标识访问该实例。不在数据库服务器上执行其他认证。这有时称为单点登录。
如果用户执行本地登录或客户机登录，那么只有该本地客户机工作站识别该用户。
如果远程实例具有 CLIENT 认证，那么另两个参数确定最终的认证类型：trust_allclnts 和 trust_clntauth。
仅用于可信客户机的 CLIENT 级别安全性：
可信的客户机是具有可靠的、本地安全性系统的客户机。
当已选择认证类型 CLIENT 时，可选择一个附加选项来保护其操作环境没有固有安全性的客户机。
要阻止不安全的客户机访问系统，管理员可将
trust_allclnts 参数设置为 NO 来选择“可信客户机认证”。这意味着所有可信平台都可以代表服务器认证用户。不可信的客户机是在服务器上进行认证，并且认证时必须提供用户标识和密码。使用 trust_allclnts 配置参数来指示您是否信赖客户机。此参数的缺省值是 YES。
注： 可以信赖所有客户机（trust_allclnts 为 YES），但其中的某些客户机可以没有用于认证的本机保密安全性系统。
甚至对于可信的客户机，您也可能希望在服务器上完成认证。使用 trust_clntauth 配置参数来指示对可信客户机进行验证的位置。此参数的缺省值是
CLIENT。
注： 仅对于可信的客户机，如果在试图 CONNECT 或 ATTACH 时没有显式提供用户标识或密码，那么对用户的验证在客户机上进行。trust_clntauth
参数仅用于确定对 USER 或 USING 子句上提供的信息进行验证的位置。
为了防止所有客户机（其中包括 z/OS® 和 System i® 上的 JCC 4 类客户机，但不包括 z/OS、OS/390®、VM、VSE 和 System i 上的本机 DB2 客户机）进行未授权的访问，请将 trust_allclnts 参数设置为 DRDAONLY。只有这些客户机可信赖，才能执行客户端认证。所有其他客户机必须提供用户标识和密码，以供服务器认证。
trust_clntauth
参数用于确定认证以上客户机的位置：如果
trust_clntauth 是“client”，那么在客户机上进行认证。如果 trust_clntauth
是“server”，那么未提供用户标识和密码时在客户机上进行认证，提供了用户标识和密码时在服务器上进行认证。
表 1. 使用 TRUST_ALLCLNTS 和 TRUST_CLNTAUTH 参数组合的认证方式。| TRUST_ ALLCLNTS |
TRUST_ CLNTAUTH |
不可信非 DRDA® 客户机认证（没有用户标识和密码） |
不可信非 DRDA 客户机认证（具有用户标识和密码） |
可信非 DRDA 客户机认证（没有用户标识和密码） |
可信非 DRDA 客户机认证（具有用户标识和密码） |
DRDA 客户机认证（没有用户标识和密码） |
DRDA 客户机认证（有用户标识和密码） |
|---|
| YES |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
| YES |
SERVER |
CLIENT |
SERVER |
CLIENT |
SERVER |
CLIENT |
SERVER |
| NO |
CLIENT |
SERVER |
SERVER |
CLIENT |
CLIENT |
CLIENT |
CLIENT |
| NO |
SERVER |
SERVER |
SERVER |
CLIENT |
SERVER |
CLIENT |
SERVER |
| DRDAONLY |
CLIENT |
SERVER |
SERVER |
SERVER |
SERVER |
CLIENT |
CLIENT |
| DRDAONLY |
SERVER |
SERVER |
SERVER |
SERVER |
SERVER |
CLIENT |
SERVER |
- DATA_ENCRYPT
- 服务器接受加密的 SERVER 认证方案和用户数据的加密。该认证与 SERVER_ENCRYPT 所说明的功能方式相同。当用户标识和密码通过网络从客户机发送至服务器时，它们处于已加密状态。
使用此认证类型时，加密以下用户数据：
- SQL 和 XQuery 语句。
- SQL 程序变量数据。
- 从处理 SQL 或 XQuery 语句和包括数据描述的服务器中输出的数据。
- 从查询获得的某些或所有答案集数据。
- 大对象 (LOB) 数据流动。
- SQLDA 描述符。
- DATA_ENCRYPT_CMP
- 服务器接受加密的 SERVER 认证方案和用户数据的加密。另外，此认证类型允许与不支持 DATA_ENCRYPT 认证类型的下层产品兼容。这些产品允许使用
SERVER_ENCRYPT 认证类型来进行连接，并且不对用户数据进行加密。支持新认证类型的产品必须使用该认证类型。此认证类型仅在服务器的数据库管理器配置文件中有效，而在 CATALOG DATABASE 命令上使用该认证类型无效。
- KERBEROS
- 当 DB2 客户机和服务器均位于支持 Kerberos 安全协议的操作系统上时，使用此项。通过使用传统密码术来创建共享密钥，Kerberos 安全性协议作为第三方认证服务执行认证。此密钥成为用户的凭证，在所有请求本地或网络服务的场合中，都使用它来验证用户的身份。此密钥消除了将用户名和密码以明文的方式通过网络传送这一需要。通过使用 Kerberos 安全协议，您能够对远程
DB2 数据库服务器使用单点登录功能。KERBEROS 认证类型在各种操作系统上受支持，请参阅相关信息部分以了解更多信息。
Kerberos 认证工作原理如下所示：
- 用户对域控制器上的 Kerberos 密钥分发中心（KDC）使用域帐户认证登录客户机。密钥分发中心将授予凭单的凭单（TGT）发送至客户机。
- 在连接的第一阶段，服务器将目标主体名称发送至客户机，该主体名称是 DB2 数据库服务器服务的服务帐户名。通过使用服务器的目标主体名称和授予目标的凭证，客户机向授予凭证的服务（TGS）请求服务凭单，该凭证也在域控制器中。如果客户机的授予凭单的凭单和服务器的目标主体名称都有效，那么 TGS 向客户机发出服务凭单。记录在数据库目录中的主体名称可能被指定为 name/instance@REALM。（除了 DOMAIN\userID 和 userID@xxx.xxx.xxx.com 格式以外，Windows 还支持此格式。）
- 客户机使用通信信道（例如，它可能是 TCP/IP）将此服务凭单发送至服务器。
- 服务器验证客户机的服务凭单。如果客户机的服务凭单有效，那么认证完成。
可能会对客户机上的数据库进行编目，并对服务器的目标主体名称显式指定 Kerberos 认证类型。使用此方法，可忽略连接的第一个阶段。
如果指定了用户标识和密码，那么客户机将请求该用户帐户的授予凭单的凭单并将其用于认证。
- KRB_SERVER_ENCRYPT
- 指定服务器接受 KERBEROS 认证或加密的 SERVER 认证方案。如果客户机认证类型
是 KERBEROS，那么使用 Kerberos 安全性系统认证客户机。如果客户机认证类型是 SERVER_ENCRYPT，那么使用用户标识和加密密码认证客户机。如果未指定客户机认证类型，如有可能，客户机将使用 Kerberos，否则它将使用密码加密。对于其他客户机认证类型，将返回一个认证错误。不能将客户机的认证类型指定为 KRB_SERVER_ENCRYPT。
注： Kerberos 认证类型在特定操作系统上运行的客户机和服务器上受支持，请参阅相关信息部分以了解更多信息。对于 Windows 操作系统，客户机和服务器都必须属于同一个
Windows 域或属于可信域。在服务器支持
Kerberos 且某些（但并非全部）客户机支持 Kerberos 认证的情况下，应使用此认证类型。
- GSSPLUGIN
- 指定服务器使用 GSS-API 插件来执行认证。如果未指定客户机认证，服务器将服务器支持的插件列表，包括在数据库管理器配置参数 srvcon_gssplugin_list 中列示的任何 Kerberos 插件返回至客户机。客户机从列表中选择在客户机插件目录中找到的第一个插件。如果客户机不支持列表中的任何插件，那么使用 Kerberos 认证方案（如果返回）认证客户机。如果客户机认证是 GSSPLUGIN 认证方案，那么使用列表中第一个支持的插件来认证客户机。
- GSS_SERVER_ENCRYPT
- 指定服务器接受插件认证或加密的服务器认证方案。如果通过插件执行客户机认证，那么使用服务器支持的插件列表中第一个客户机支持的插件来认证客户机。
如果未指定客户机认证且在执行隐式连接（即，生成连接时，客户机不提供用户标识和密码），那么服务器返回服务器支持的插件列表、Kerberos 认证方案（如果列表中的某个插件是基于 Kerberos 的）和加密的服务器认证方案。使用客户机插件目录中找到的第一个支持的插件来认证客户机。如果客户机不支持列表中的任何插件，那么使用 Kerberos 认证方案认证客户机。如果客户机不支持 Kerberos 认证方案，使用加密的服务器认证方案来认证客户机，且连接将因为丢失密码而失败。如果 DB2 提供的 Kerberos 插件适用于操作系统或者为数据库管理器配置参数 srvcon_gssplugin_list 指定基于 Kerberos 的插件，那么客户机支持 Kerberos 认证方案。
如果未指定客户机认证且在执行显式连接（即，同时提供用户标识和密码），那么认证类型等价于 SERVER_ENCRYPT。在此情况下，选择使用哪种加密算法来加密用户标识和密码取决于数据库管理器配置参数 alternate_auth_enc 的设置。
注： - 因为对配置文件本身的访问受到配置文件中信息的保护，所以在更改认证信息时，不要无意中将自己锁定在实例之外。下列数据库管理器配置文件参数控制对实例的访问：
- AUTHENTICATION *
- SYSADM_GROUP *
- TRUST_ALLCLNTS
- TRUST_CLNTAUTH
- SYSCTRL_GROUP
- SYSMAINT_GROUP
* 指示两个最重要的参数。
可以采取一些措施来确保这种情况不会发生：如果意外将自己锁定在 DB2 数据库系统之外，所有平台上都提供了一个故障保险选项，它将允许您使用具有较高特权的本地操作系统安全性用户，重设通常的 DB2 数据库安全性检查来更新数据库管理器配置文件。此
用户
始终具有更新数据库管理器配置文件并校正该问题的
特权。但是，这种绕过安全性检查的做法只限于对数据库管理器配置文件进行本地更新。不能以远程方式或对任何其他 DB2 数据库命令使用故障保险用户。此特殊用户被标识为：
- UNIX 平台：实例所有者
- Windows 平台：属于本地 “Administrators” 组的人员
- 其他平台：由于在其他平台上没有本地安全性，因此所有用户无论如何都要通过本地安全性检查
DB2 V9.7 for Linux, UNIX, and Windows