DB2 9 基础（730 考试）认证指南，第 2 部分: 安全性(3)-sdccf-ChinaUnix博客

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102143) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102142) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102141) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102140) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102139) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102138) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102137) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102136) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102135) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102134) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102133) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102132) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102131) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102130) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102129) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102128) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102127) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102126) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102125) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102124) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102123) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102122) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102121) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102120) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102119) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102118) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102117) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102116) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102115) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102114) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102113) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102112) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102111) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102110) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102109) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102108) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102107) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102106) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们

DB2 身份验证

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

DB2 GET DBM CFG
Server Connection Authentication          (SRVCON_AUTH) = KERBEROS
Database manager authentication        (AUTHENTICATION) = SERVER_ENCRYPT

类型	描述
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® 操作系统有效。

要查看配置文件中的身份验证参数：

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

使用 catalog database 命令在网关上设置身份验证。在这里的示例中，我们将使用名为 myhostdb 的主机数据库。

要将网关身份验证类型设置为 SERVER，应该在网关机器上发出以下命令：

db2 catalog database myhostdb at node nd1 authentication SERVER
db2 terminate

注意，身份验证不会在网关本身执行。在 DB2 Version 8 中，身份验证必须在客户机或主机数据库服务器上执行。

连接服务器数据库的客户机：在针对要连接的数据库的数据库目录项中，客户机身份验证设置必须匹配数据库服务器上的设置（但是 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 和密码在客户机上进行加密，然后再发送到网关，并在网关上进行加密，然后再发送到主机。这是默认的做法。

不可信的客户机：如上所述
主机客户机：运行在 zSeries 这样的主机操作系统上的客户机
可信客户机：运行在具有本机安全特性的非主机操作系统（比如 Windows NT、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 进行连接的 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

那么身份验证在服务器上进行。

客户机和服务器必须属于同一个域（用 Windows 术语来说，是可信域）。
必须设置适当的主体（Kerberos 中的用户 ID）。
必须创建服务器的 keytab 文件，实例所有者必须能够读这个文件。
所有机器必须有同步的时钟。

可以在 Kerberos 产品附带的文档中找到关于设置 Kerberos 的更多信息。

为了在 DB2 中启用 Kerberos 身份验证，必须先告诉客户机在哪里寻找将使用的 Kerberos 插件。在客户机上，运行以下命令：

DB2 UPDATE DBM CFG USING CLNT_KRB_PLUGIN IBMkrb5
DB2 TERMINATE

在这个示例中，使用默认的 KERBEROS 插件。如果使用的 Kerberos 实现需要特殊功能的话，DBA 可以修改这个插件来执行特殊功能。

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

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 插件。

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 权限。

阅读(102105) | 评论(0) | 转发(0) |

给主人留下些什么吧！~~

感谢所有关心和支持过ChinaUnix的朋友们