DB2UDB 安全模型主要包括两部分：身份验证(authentication) 和授权(authorization)。
图 1. DB2 UDB 安全模型
身份验证
身份验证就是使用安全机制验证所提供用户 ID 和口令的过程。用户和组身份验证由 DB2 UDB 外部的设施管理，比如操作系统、域控制器或者 Kerberos 安全系统。这和其他数据库管理系统(DBMS)是不同的，如 Oracle和 SQL Server，后者既可以在数据库本身中定义和验证用户帐户，也可在外部设施(如操作系统)中完成。
一旦用户 ID 和口令作为实例附件或数据库连接请求的一部分明确地提供给 DB2 UDB，DB2 UDB 就会尝试使用该外部安全设施验证用户 ID 和口令。如果请求中没有提供用户 ID 和口令，则 DB2 UDB 隐含使用登录到发出请求的工作站时所用的用户 ID 和口令。
实际的验证位置由 DB2 UDB 实例参数 AUTHENTICATION 的值决定。有不同的身份验证方案，包括让用户在 DB2 UDB 服务器上验证(使用服务器的安全设施)、在客户机上验证(允许 “单点登录” 访问)、使用 Kerberos 安全设施验证，或者用户定义的通用安全服务(Generic Security Service，GSS)插件验证。其他身份验证选项包括当用户名和口令以及数据在客户机和服务器之间的网络上传递时进行加密。为 AUTHENTICATION 参数选择的值依赖于具体环境和本地安全策略。关于各种身份验证方案的完整描述，请参阅 DB2 UDB 文档。
比如，图 1 中的连接语句供用户 bob 使用口令 bobpsw 连接到 finance 数据库。身份验证过程包括七个步骤：
CONNECT 语句传递给 DB2 UDB 服务器。
如果没有明确配置安全插件，则使用默认的安全插件。如果包含 finance 数据库的实例的 AUTHENTICATION 参数设为 SERVER(默认设置)，连接请求中的用户 ID 和口令则由 DB2 UDB 服务器上的安全设施验证。默认插件将用户 ID 和口令发送给操作系统进行验证。操作系统确认bob/bobpsw 组合是否有效，把该信息返回给安全插件。安全插件激活 DB2 UDB 安全机制，对用户 bob 查询 DB2 UDB 目录表，看看该用户是否被授予了该数据库的 CONNECT 权限。默认情况下，CONNECT 特权被授予 PUBLIC，就是说任何通过身份验证的用户都能连接到数据库。DB2 UDB 安全机制验证用户 bob 或者返回错误。
安全插件把成功或者失败的消息返回给用户。如果用户没有通过身份验证，DB2 UDB 就会拒绝连接请求，并向客户机应用程序返回错误消息，如下所示：
清单 1. 用户身份验证失败时 DB2 UDB 返回应用程序的消息:
SQL30082N Attempt to establish connection failed with security
reason "24" ("USERNAME AND/OR PASSWord
INVALID"). SQLSTATE=08001
DB2 UDB 服务器上的 DB2 UDB 诊断日志(db2diag.log)中也会出现类似于下面这样的记录：
清单 2. 用户身份验证失败时 DB2 诊断日志中的消息:
2005-07-09-16.18.33.546000-240 I729347H256
LEVEL: Severe
PID : 3888
TID : 604
FUNCTION: DB2 Common, Security,
Users and Groups, secLogMessage, probe:20
DATA #1 : String, 44 bytes
check password failed with rc = -2146500502
在 Windows上，诊断日志可以在数据库实例主目录中找到，默认为 C:Program FilesIBMSQLLIBDB2。在 Unix上默认位置是 /DB2/db2dump，其中 是实例所有者的路径。
如果遇到这样的消息，一定要确认连接到数据库的用户或应用程序是否提供了合法的用户 ID 和口令。该用户 ID 和口令必须存在于执行用户身份验证的设施中(由目标 DB2 UDB 实例的 AUTHENTICATION 参数决定)。
