DB2 9 基础（730 考试）认证指南，第 2 部门: 平安性(3)

DB2 身份验证

什么时辰截至 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 中一样，用户 ID test1 和密码 password 由利用体系截至考验。然后，利用体系将 test1 的密码从 password 改为 chgpass。因此，如果再次收回例 2 中的敕令，它就会失败。

DB2 身份验证类型

DB2 利用身份验证类型 决议在什么处所截至身份验证。比方，在客户机 - 效劳器情况中，是客户机还是效劳器考验用户的 ID 和密码？在客户机 - 网关 - 主机情况中，是客户机还是主机考验用户的 ID 和密码？

DB2 9 可以遵照用户是试图跟尾数据库，还是执行实例跟尾和实例级利用，指定差其它身份验证机制。在默许情况下，实例凑合一确切例级和跟尾级乞求利用一种身份验证类型。这由数据库解决法式设置配备放置参数 AUTHENTICATION 来指定。V9.1 中引入了数据库解决法式设置配备放置参数 SRVCON_AUTH。这个参数专门处置责罚对数据库的跟尾。比方，如果在 DBM CFG 中截至以下设置：

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 身份验证。这个身份验证类型只在效劳器的数据库解决法式设置配备放置文件中是有效的，并且在客户机或网关实例上利用 CATALOG DATABASE 时是无效的。
GSSPLUGIN 身份验证方法由一个内部 GSS-API 插件决议。
GSS_SERVER_ENCRYPT 身份验证方法由一个内部 GSS-API 插件决议。在客户机不撑持效劳器的 GSS-API 插件之一的情况下，利用 SERVER_ENCRYPT 身份验证。

*这些设置只对 Windows 2000、AIX、Solaris 和 Linux® 利用体系有效。

在效劳器上设置身份验证

在数据库效劳器上，在数据库解决法式设置配备放置（DBM CFG）文件中利用 AUTHENTICATION 参数设置身份验证。请记住，DBM CFG 文件是一个实例级设置配备放置文件。因此，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。关于这些设置的更多细节见下文。

在网打开设置身份验证

利用 catalog database 敕令在网打开设置身份验证。在这里的示例中，我们将利用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关呆板上收回以下敕令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate
			

仔细，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库效劳器上执行。

在客户机上设置身份验证

我们来思索两台单独的客户机上的两种情况。我们将一个客户机设置配备放置为跟尾效劳器呆板上的数据库（DB2 UDB LUW 分布式平台），另一个客户机跟尾主机上的数据库（比方 DB2 for zSeries）。

• 跟尾效劳器数据库的客户机：在针对要跟尾的数据库的数据库目次项中，客户机身份验证设置必须婚配数据库效劳器上的设置（然则 KRB_SERVER_ENCRYPT、DATA_ENCRYPT_CMP 和 GSS_SERVER_ENCRYPT 例外）。

  我们假定效劳器身份验证类型设置为 SERVER。在客户机上收回以下敕令对名为 sample 的效劳器数据库截至编目：

  db2 catalog database sample at node nd1 authentication SERVER
  

  
  
  如果没有指定身份验证类型，客户机将默许利用 SERVER_ENCRYPT。
  
• 跟尾主机数据库的客户机：我们假定网打开的身份验证类型设置为 SERVER。如果没有指定身份验证类型，那么在经由 DB2 Connect 访问数据库时假定采用 SERVER_ENCRYPT 身份验证。身份验证在主机数据库效劳器上截至。从客户机收回以下敕令会招致客户机向网关发送未加密的用户 ID 和密码：

   
  db2 catalog database myhostdb at node nd1 authentication SERVER
  

  
  
  现在假定网打开的身份验证类型设置为 SERVER_ENCRYPT。身份验证异样在主机数据库效劳器上截至。用户 ID 和密码在客户机上截至加密，然后再发送到网关，并在网打开截至加密，然后再发送到主机。这是默许的做法。

处置责罚不可托的客户机

如果效劳器或网关将身份验证类型设置为 CLIENT，那么这意味着期望客户机对用户的 ID 和密码截至身份验证。然则，一些客户机的利用体系没有本机平安特性。这种不可托的 客户机包括在 Windows 98 和 Windows ME 上运转的 DB2。DB2 V9.1 不撑持 Windows 98 或 Windows ME，然则它撑持低版本的客户机，以是仍旧能够必须处置责罚不可托的 V8 客户机。

在 DBM CFG 文件中有两个非凡参数，用于在效劳器或网关身份验证方法设置为 CLIENT，而不可托的客户机试图跟尾数据库或 DB2 实例时，决议应该在那里截至身份验证。这些参数是 TRUST_ALLCLNTS 和 TRUST_CLNTAUTH 参数。

当效劳器或网关身份验证类型为 CLIENT 时，除了 TRUST_ALLCLNTS 和 TRUST_CLNTAUTH 参数之外，还有两个要素会起传染打动。第一个要素是用户 ID 和密码可否是显式供应的，第二个要素是截至跟尾的客户机的类型。有三种 DB2 客户机：

• 不可托的客户机：如上所述
• 主机客户机：运转在 zSeries 如许的主机利用体系上的客户机
• 可托客户机：运转在具有本机平安特性的非主机利用体系（好比 Windows NT、2000、2003、XP 以及一切方法的 Unix / Linux）上的客户机

当身份验证设置为 CLIENT 时

下表总结了如果效劳器的身份验证类型设置为 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 截至跟尾的 DB2 Version 8 客户机。

下面的示例说明如安在效劳器和客户机上设置身份验证类型和参数：

在效劳器上设置身份验证：

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

那么身份验证在效劳器上截至。

DB2 的平部署件架构

DB2 V8.2 引入了平部署件的概念。这个概念在 DB2 V9.1 中得到了进一步加强。经由利用标准的 GSS-API 挪用，用户可以编写一个平部署件并将对用户 ID 截至身份验证的任务交给一个内部平安法式。这种方法的一个示例是 DB2 本身的 KERBEROS 身份验证。在一台呆板上安置 DB2 ESE 或利用法式开拓客户机时，安置过程中将有一些示例利用法式代码放入实例目次，如果搜检 samples\security\plugins 目次，就会看到如何编写平部署件的示例。本节将概述如安在 DB2 平安架构中利用插件，然则不讨论如何编写或编译插件本身。关于这个主题的仔细描画，请参考 DB2 UDB 平安性: 清楚了然 DB2 Universal Database 平安性插件。

Kerberos 身份验证

Kerberos 身份验证为 DB2 供应了一种无需经由搜集发送用户 ID 和密码的用户身份验证方法。Kerberos 平安协议作为第三方身份验证效劳执行身份验证，它利用传统的密码术创建一个共享的密钥。这个密钥成为用户的凭证，在乞求当地或搜集效劳时在一切情况下都利用它考验用户的身份。经由利用 Kerberos 平安协议，可以完成对远程 DB2 数据库效劳器的单点登录。

首先，讨论如何设置 DB2 来利用 Kerberos 身份验证。如上所述，Kerberos 身份验证在 DB2 中是利用插件架构完成的。默许的 kerberos 插件的源代码在 samples/security/plugins 目次中，称为 IBMkrb5.c。在 DB2 中利用 Kerberos 之前，必须在客户机和效劳器上启用和撑持 Kerberos。为此，必须满意以下条件：

1. 客户机和效劳器必须属于一致个域（用 Windows 术语来说，是可托域）。
2. 必须设置相宜的主体（Kerberos 中的用户 ID）。
3. 必须创建效劳器的 keytab 文件，实例一切者必须可以读这个文件。
4. 一切呆板必须有同步的时钟。

可以在 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 实例中的 DBM CFG，会看到影响 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 这个参数在客户真个 DBM CFG 中指定。它指定用来截至客户机和当地身份验证的客户机插件的称号。
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 权限。





版权声明： 原创作品，容许转载，转载时请务必以超链接方法标明文章 原始原由 、作者信息和本声明。不然将追查法律责任。