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