DB2身份验证
DB2身份验证控制数据库安全计划的以下方面：
谁有权访问实例和/或数据库
在哪里以及如何检验用户的密码
在发出attach或connect命令时，它在底层操作系统安全特性的帮助下完成这个任务。attach命令用来连接DB2实例，connect命令用来连接DB2实例中的数据库。下面的示例展示了DB2对发出这些命令的用户进行身份验证的不同方式。这些示例在数据库管理程序配置文件中使用默认的身份验证类型SERVER。下面的例3说明了如何使用DB2修改服务器操作系统上的密码。
用创建DB2实例时使用的用户ID登录到安装DB2的机器上。发出以下命令：
db2 attach to DB2 |
在这里，隐式地执行身份验证。使用登录机器的用户ID，并假设这个ID已经经过了操作系统的检验。
db2 connect to sample user test1 using password
Database Connection Information
Database server = DB2/NT 9.1.0
SQL authorization ID = TEST1
Local database alias = SAMPLE
|
在这里，显式地执行身份验证。用户test1和密码password由操作系统进行检验。用户test1成功地连接到示例数据库。
db2 connect to sample user test1 using password new chgpass confirm chgpass |
与例2中一样，用户IDtest1和密码password由操作系统进行检验。然后，操作系统将test1的密码从password改为chgpass。因此，如果再次发出例2中的命令，它就会失败。
DB2使用身份验证类型决定在什么地方进行身份验证。例如，在客户机-服务器环境中，是客户机还是服务器检验用户的ID和密码？在客户机-网关-主机环境中，是客户机还是主机检验用户的ID和密码？
DB29能够根据用户是试图连接数据库，还是执行实例连接和实例级操作，指定不同的身份验证机制。在默认情况下，实例对于所有实例级和连接级请求使用一种身份验证类型。这由数据库管理程序配置参数AUTHENTICATION来指定。V9.1中引入了数据库管理程序配置参数SRVCON_AUTH。这个参数专门处理对数据库的连接。例如，如果在DBMCFG中进行以下设置：
DB2 GET DBM CFG Server Connection Authentication (SRVCON_AUTH) = KERBEROS Database manager authentication (AUTHENTICATION) = SERVER_ENCRYPT |
那么在连接实例时会使用SERVER_ENCRYPT。但是在连接数据库时会使用KERBEROS身份验证。如果在服务器上没有正确地初始化KERBEROS，但是提供了有效的用户ID/密码，那么允许这个用户连接实例，但是不允许他连接数据库。
下表总结了可用的DB2身份验证类型。在客户机-网关-主机环境中，这些身份验证选项在客户机和网关上设置，而不是在主机上。本节将详细讨论如何设置这些选项。请回顾客户机、服务器、网关和主机小节。
| 类型 | 描述 |
| SERVER | 身份验证在服务器上进行。 |
| SERVER_ENCRYPT | 身份验证在服务器上进行。密码在客户机上进行加密，然后再发送到服务器。 |
| CLIENT | 身份验证在客户机上进行（例外情况见处理不可信的客户机）。 |
| *KERBEROS | 由Kerberos安全软件执行身份验证。 |
| *KRB_SERVER_ENCRYPT | 如果客户机设置是KERBEROS，那么由Kerberos安全软件执行身份验证。否则使用SERVER_ENCRYPT。 |
| DATA_ENCRYPT | 身份验证在服务器上进行。服务器接受加密的用户ID和密码，并对数据进行加密。这个选项的操作方式与SERVER_ENCRYPT相同，但是数据也要加密。 |
| DATA_ENCRYPT_CMP | 身份验证方式与DATA_ENCRYPT相同，但是允许不支持DATA_ENCRYPT的老式客户机使用SERVER_ENCRYPT身份验证进行连接。在这种情况下，数据不进行加密。如果进行连接的客户机支持DATA_ENCRYPT，就会进行数据加密，而不能降级到SERVER_ENCRYPT身份验证。这个身份验证类型只在服务器的数据库管理程序配置文件中是有效的，而且在客户机或网关实例上使用CATALOGDATABASE时是无效的。 |
| GSSPLUGIN | 身份验证方式由一个外部GSS-API插件决定。 |
| GSS_SERVER_ENCRYPT | 身份验证方式由一个外部GSS-API插件决定。在客户机不支持服务器的GSS-API插件之一的情况下，使用SERVER_ENCRYPT身份验证。 |
*这些设置只对Windows2000、AIX、Solaris和Linux操作系统有效。
在数据库服务器上，在数据库管理程序配置（DBMCFG）文件中使用AUTHENTICATION参数设置身份验证。请记住，DBMCFG文件是一个实例级配置文件。因此，AUTHENTICATION参数影响这个实例中的所有数据库。以下命令演示如何修改这个参数。
要查看配置文件中的身份验证参数：
db2 get dbm cfg |
要将身份验证参数修改为server_encrypt：
C:\PROGRA~1\SQLLIB\BIN> db2 update dbm cfg using authentication server_encrypt
C:\PROGRA~1\SQLLIB\BIN> db2stop
C:\PROGRA~1\SQLLIB\BIN> db2start
|
某些身份验证类型（比如GSSPLUGIN、KERBEROS和CLIENT）要求设置其他数据库管理程序配置参数，比如TRUST_ALLCLNTS、SRV_PLUGIN_MODE和SRVCON_PW_PLUGIN。关于这些设置的更多细节见下文。
使用catalogdatabase命令在网关上设置身份验证。在这里的示例中，我们将使用名为myhostdb的主机数据库。
要将网关身份验证类型设置为SERVER，应该在网关机器上发出以下命令：
db2 catalog database myhostdb at node nd1 authentication SERVER db2 terminate |
注意，身份验证不会在网关本身执行。在DB2Version8中，身份验证必须在客户机或主机数据库服务器上执行。
我们来考虑两台单独的客户机上的两种情况。我们将一个客户机配置为连接服务器机器上的数据库（DB2UDBLUW分布式平台），另一个客户机连接主机上的数据库（例如DB2forzSeries）。
连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是KRB_SERVER_ENCRYPT、DATA_ENCRYPT_CMP和GSS_SERVER_ENCRYPT例外）。
我们假设服务器身份验证类型设置为SERVER。在客户机上发出以下命令对名为sample的服务器数据库进行编目：
db2 catalog database sample at node nd1 authentication SERVER
如果没有指定身份验证类型，客户机将默认使用SERVER_ENCRYPT。
连接主机数据库的客户机：我们假设网关上的身份验证类型设置为SERVER。如果没有指定身份验证类型，那么在通过DB2Connect访问数据库时假设采用SERVER_ENCRYPT身份验证。身份验证在主机数据库服务器上进行。从客户机发出以下命令会导致客户机向网关发送未加密的用户ID和密码：
db2 catalog database myhostdb at node nd1 authentication SERVER
现在假设网关上的身份验证类型设置为SERVER_ENCRYPT。身份验证同样在主机数据库服务器上进行。用户ID和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。
如果服务器或网关将身份验证类型设置为CLIENT，那么这意味着期望客户机对用户的ID和密码进行身份验证。但是，一些客户机的操作系统没有本机安全特性。这种不可信的客户机包括在Windows98和WindowsME上运行的DB2。DB2V9.1不支持Windows98或WindowsME，但是它支持低版本的客户机，所以仍然可能必须处理不可信的V8客户机。
在DBMCFG文件中有两个额外参数，用于在服务器或网关身份验证方法设置为CLIENT，而不可信的客户机试图连接数据库或DB2实例时，决定应该在哪里进行身份验证。这些参数是TRUST_ALLCLNTS和TRUST_CLNTAUTH参数。
当服务器或网关身份验证类型为CLIENT时，除了TRUST_ALLCLNTS和TRUST_CLNTAUTH参数之外，还有两个因素会起作用。第一个因素是用户ID和密码是否是显式提供的，第二个因素是进行连接的客户机的类型。有三种DB2客户机：
不可信的客户机：如上所述
主机客户机：运行在zSeries这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如WindowsNT、2000、2003、XP以及所有形式的Unix/Linux）上的客户机
下表总结了如果服务器的身份验证类型设置为CLIENT，那么在每种类型的客户机向服务器发出连接命令时将在哪里进行身份验证。
| 是否提供了ID/密码？ | TRUST_ALLCLNTS | TRUST_CLNTAUTH | 不可信的客户机 | 可信的客户机 | 主机客户机 |
| No | Yes | CLIENT | CLIENT | CLIENT | CLIENT |
| No | Yes | SERVER | CLIENT | CLIENT | CLIENT |
| No | No | CLIENT | SERVER | CLIENT | CLIENT |
| No | No | SERVER | SERVER | CLIENT | CLIENT |
| No | DRDAONLY | CLIENT | SERVER | SERVER | CLIENT |
| No | DRDAONLY | SERVER | SERVER | SERVER | CLIENT |
| Yes | Yes | CLIENT | CLIENT | CLIENT | CLIENT |
| Yes | Yes | SERVER | SERVER | SERVER | SERVER |
| Yes | No | CLIENT | SERVER | CLIENT | CLIENT |
| Yes | No | SERVER | SERVER | SERVER | SERVER |
| Yes | DRDAONLY | CLIENT | SERVER | SERVER | CLIENT |
| Yes | DRDAONLY | SERVER | SERVER | SERVER | SERVER |
DRDAONLY意味着只信任主机客户机，而不管使用DRDA进行连接的DB2Version8客户机。
下面的示例说明如何在服务器和客户机上设置身份验证类型和参数：
在服务器上设置身份验证：
db2 update dbm cfg using authentication client db2 update dbm cfg using trust_allclnts yes db2 update dbm cfg using trust_clntauth server db2stop db2start |
在客户机上设置身份验证：
db2 catalog database sample at node nd1 authentication client |
在上面的示例中，如果从任何客户机发出命令
db2 connect to sample |
那么身份验证在客户机上进行。如果从任何客户机发出命令
db2 connect to sample user test1 using password |
那么身份验证在服务器上进行。
DB2V8.2引入了安全插件的概念。这个概念在DB2V9.1中得到了进一步增强。通过使用标准的GSS-API调用，用户可以编写一个安全插件并将对用户ID进行身份验证的工作交给一个外部安全程序。这种方式的一个示例是DB2本身的KERBEROS身份验证。在一台机器上安装DB2ESE或应用程序开发客户机时，安装过程中将有一些示例应用程序代码放入实例目录，如果查看samples\security\plugins目录，就会看到如何编写安全插件的示例。本节将概述如何在DB2安全架构中使用插件，但是不讨论如何编写或编译插件本身。关于这个主题的详细描述，请参考DB2UDB安全性:理解DB2UniversalDatabase安全性插件。
Kerberos身份验证为DB2提供了一种无需通过网络发送用户ID和密码的用户身份验证方法。Kerberos安全协议作为第三方身份验证服务执行身份验证，它使用传统的密码术创建一个共享的密钥。这个密钥成为用户的凭证，在请求本地或网络服务时在所有情况下都使用它检验用户的身份。通过使用Kerberos安全协议，可以实现对远程DB2数据库服务器的单点登录。
首先，讨论如何设置DB2来使用Kerberos身份验证。如上所述，Kerberos身份验证在DB2中是使用插件架构实现的。默认的kerberos插件的源代码在samples/security/plugins目录中，称为IBMkrb5.c。在DB2中使用Kerberos之前，必须在客户机和服务器上启用和支持Kerberos。为此，必须满足以下条件：
客户机和服务器必须属于同一个域（用Windows术语来说，是可信域）。
必须设置适当的主体（Kerberos中的用户ID）。
必须创建服务器的keytab文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。
可以在Kerberos产品附带的文档中找到关于设置Kerberos的更多信息。
为了在DB2中启用Kerberos身份验证，必须先告诉客户机在哪里寻找将使用的Kerberos插件。在客户机上，运行以下命令：
DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE
|
在这个示例中，使用默认的KERBEROS插件。如果使用的Kerberos实现需要特殊功能的话，DBA可以修改这个插件来执行特殊功能。
还可以告诉客户机它正在针对哪个服务器主体进行身份验证。这个选项可以避免Kerberos身份验证的第一步，即客户机寻找它要连接的实例的服务器主体。在客户机上对数据库进行编目时可以指定AUTHENTICATION参数。它的格式是：
DB2 CATALOG DB dbname AT NODE node name AUTHENTICATION KERBEROS TARGET PRINCIPAL service/host@REALM |
这一步是可选的。
DB2 CATALOG DB sample AT NODE testnd AUTHENTICATION KERBEROS TARGET PRINCIPAL
gmilne/gmilne02.torolab.ibm.com@TOROLAB.IBM.COM
|
设置Kerberos身份验证的下一步是设置服务器。srvcon_gssplugin_list参数可以设置为支持的GSS-API插件的列表，但是只允许有一个Kerberos插件。如果这个列表中没有Kerberos插件，那么自动地使用默认的IBMkrb5插件。如果希望允许所有身份验证（实例连接和数据库连接）使用Kerberos，那么执行以下命令：
DB2 UPDATE DBM CFG USING AUTHENTICATION KERBEROS
or
DB2 UPDATE DBM CFG USING AUTHENTICATION KRB_SERVER_ENCRYPT
|
如果只希望DB2使用Kerberos对数据库连接进行身份验证（对实例连接使用SERVER），那么执行以下命令：
DB2 UPDATE DBM CFG USING SVRCON_AUTH KERBEROS
or
DB2 UPDATE DBM CFG USING SVRCON_AUTH KRB_SERVER_ENCRYPT
|
根据实例的位长度（32或64位），DB2将在实例启动时自动地装载IBMkrb5插件。
如果查看V9.1实例中的DBMCFG，会看到影响DB2对用户ID进行身份验证的方式的各种设置。正如前面提到的，有针对标准操作系统用户ID身份验证的设置（CLIENT、SERVER、SERVER_ENCRYPT、DATA_ENCRYPT、DATA_ENCRYPT_CMP），还有将身份验证工作交给外部程序的插件（KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN、GSS_SERVER_ENCRYPT）。本节专门介绍其他一些配置变量如何影响对用户的身份验证。
Client Userid-Password Plugin (CLNT_PW_PLUGIN) = Group Plugin (GROUP_PLUGIN) = GSS Plugin for Local Authorization (LOCAL_GSSPLUGIN) = Server Plugin Mode (SRV_PLUGIN_MODE) = UNFENCED Server List of GSS Plugins (SRVCON_GSSPLUGIN_LIST) = Server Userid-Password Plugin (SRVCON_PW_PLUGIN) = Cataloging allowed without authority (CATALOG_NOAUTH) = NO Bypass federated authentication (FED_NOAUTH) = NO |
在上面的列表中，去掉了已经讨论过的参数。
| CLNT_PW_PLUGIN | 这个参数在客户端的DBMCFG中指定。它指定用来进行客户机和本地身份验证的客户机插件的名称。 |
| GROUP_PLUGIN | 默认值是空（NULL）。将它设置为用户定义的插件就会调用这个插件进行所有组枚举，而不依赖于操作系统的组查找。这与后面讨论的授权部分相关。 |
| LOCAL_GSSPLUGIN | 这个参数指定默认的GSS-API插件库的名称，当数据库管理程序配置的身份验证参数值设置为GSSPLUGIN或GSS_SERVER_ENCRYPT时，这个库用来进行实例级的本地授权。 |
| SRV_PLUGIN_MODE | （YES/NO）这个参数的默认设置是NO。当改为YES时，以FENCED模式启动GSS-API插件，其工作方式类似于FENCED存储过程。FENCED插件的崩溃不会导致DB2实例崩溃。在插件还处于开发阶段时，建议以fenced模式运行它们，这样的话插件中的逻辑问题和内存泄漏就不会导致实例崩溃。在确定插件是可靠的之后，应该以unfenced模式运行以提高性能。 |
| SRVCON_GSSPLUGIN_LIST | 一个插件列表，当使用KERBEROS、KRB_SERVER_ENCRYPT、GSSPLUGIN或GSS_SERVER_ENCRYPT时，服务器上的数据库管理程序在身份验证期间将使用这些插件。列表中的每个插件应该用逗号（‘,’）分隔，它们之间没有空格。插件按照优先次序列出，首先使用列表中的第一个插件对发送的用户ID/密码进行身份验证。只有当列出的所有插件都返回了错误时，DB2才会向用户返回身份验证错误。 |
| SRVCON_PW_PLUGIN | 在指定CLIENT、SERVER或SERVER_ENCRYPT身份验证时，这个参数允许用户修改DB2用来检验用户ID和密码的默认身份验证方法。在默认情况下，它的值是NULL，因此使用默认的DB2方法。 |
| CATALOG_NOAUTH | （YES/NO）默认值是NO。将这个参数修改为YES就允许不属于SYSADM、SYSCTRL或SYSMAINT组成员的用户修改机器上的Database、Node、Admin和DCS编目。如果登录的用户使用不可信客户机（定义见上文），或者登录所用的用户ID不允许连接数据库或实例，但是用户又必须在客户机上进行编目，只有在这种情况下这个参数才是有用的。 |
| FED_NOAUTH | 如果fed_noauth设置为yes，身份验证设置为server或server_encrypt，联邦设置为yes，那么在实例上避免进行身份验证。它假设身份验证在数据源上进行。当fed_noauth设置为yes时系统会发出警告。在客户机和DB2服务器上都不进行身份验证。知道SYSADM身份验证名称的任何用户都拥有联邦服务器的SYSADM权限。 |
