DB2---服务器的认证方法[摘抄]

服务器的认证方法
存取实例或数据库首先要求 认证 用户。每个实例的 认证类型 确定如何以及在何处验证用户。认证类型存储在服务器上的数据库管理器配置文件中。它是在创建实例时进行的初始设置。每个实例都有一个认证类型，该类型控制对数据库服务器和该服务器控制下的所有数据库的存取。
若打算从联合数据库存取数据源，必须考虑数据源认证处理和联合认证类型的定义。
提供了下列认证类型：

===SERVER===
指定使用本地操作系统安全性在服务器上进行认证。若在连接尝试期间指定了用户标识和密码，则在服务器上将它们与有效的用户标识和密码比较，以确定是否允许该用户存取这个实例。这是缺省的安全性机制。
注:
1.服务器代码检测一个连接是本地的还是远程的。对于本地连接，当认证是 SERVER 时，要使认证成功，不需要用户标识和密码。
2. 如果安装 DB2(R) 通用数据库（DB2 UDB）来设置 Common Criteria 认证配置，则必须指定 SERVER。

===SERVER_ENCRYPT===
指定服务器接受加密的 SERVER 认证方案。若未指定客户机认证，使用在服务器中选择的方法认证客户机。
如果客户机认证为 SERVER，则可通过将用户标识和密码传送至该服务器来认证客户机。如果客户机认证为 SERVER_ENCRYPT，可通过传送加密的用户标识和加密的密码来认证客户机。
若在客户机中指定 SERVER_ENCRYPT，在服务器中指定 SERVER，由于认证级别不匹配会返回一个错误。

===CLIENT===
指定使用操作系统安全性在调用应用程序所在的数据库分区上执行认证。在客户机节点上，将在一个连接尝试期间指定的用户标识和密码与有效的用户标识和密码的组合比较，以确定是否允许此用户标识 存取这个实例。不在数据库服务器上执行其它认证。这有时称为单点登录。
若用户执行本地登录或客户机登录，则只有该本地客户机工作站识别该用户。
若远程实例有 CLIENT 认证，则另两个参数确定最终的认证类型： trust_allclnts 和 trust_clntauth 。
只用于 TRUSTED 客户机的 CLIENT 级安全性：
可信的客户机是具有可靠的、本地安全性系统的客户机。具体地说，除 Windows(R) 9x 操作系统外，所有客户机都是可信客户机。
当已选择认证类型 CLIENT 时，可选择一个附加选项来保护其操作环境没有固有安全性的客户机。
要阻止不安全的客户机存取系统，管理员可将 trust_allclnts 参数设置为 NO 来选择“可信客户机认证”。这意味着所有可信平台都可以代表服务器认证用户。在服务器上认证不可信的客户机，必须提供一个用户标识和密码。使用 trust_allclnts 配置参数来指示您是否信赖客户机。此参数的缺省值是 YES。
注:
可以信赖所有客户机（ trust_allclnts 为 YES），而让一些客户机作为没有本机保密安全性系统来认证的那些客户机。
甚至对于可信的客户机，您也可能希望在服务器上完成认证。要指示在哪里验证可信的客户机，使用 trust_clntauth 配置参数。此参数的缺省值是 CLIENT。
注:
仅对于可信的客户机，若在试图 CONNECT 或 ATTACH 时没有显式提供用户标识或密码，则对用户的验证在客户机上进行。 trust_clntauth 参数仅用于确定在什么位置验证 USER 或 USING 子句上提供的信息。
要阻止所有客户机（来自 DB2 OS/390(R) 和 z/OS(TM) 版、DB2 VM 和 VSE 版以及 DB2 iSeries(TM) 版的 DRDA(R) 客户机除外）存取系统，将 trust_allclnts 参数设置为 DRDAONLY。只有这些客户机受信赖，因此才可执行客户机端的认证。所有其它客户机必须提供用户标识和密码，以供服务器认证。
trust_clntauth 参数用于确定在何处认证以上客户机：若 trust_clntauth 是“client”，则在客户机处进行认证。若 trust_clntauth 是“server”，没有提供密码时在客户机处认证，而提供密码时则在服务器处认证。

[attach]20441[/attach]
  
KERBEROS  
当 DB2 UDB 客户机和服务器均位于支持 Kerberos 安全协议的操作系统上时，使用此项。通过使用传统密码术来创建共享密钥，Kerberos 安全性协议作为第三方认证服务执行认证。此密钥成为用户的凭证，在所有请求本地或网络服务的场合中，都使用它来验证用户的身份。此密钥消除了将用户名和密码以明文的方式通过网络传送这一需要。使用 Kerberos 安全协议，您能够对远程 DB2 UDB 服务器使用单点登录。在运行 Windows 2000、AIX(R) 和  Solaris Operating Environment 的客户机和服务器上支持 KERBEROS 认证类型。  
Kerberos 认证工作原理如下所示：

1.用户对域控制器上的 Kerberos 密钥分发中心（KDC）使用域帐户认证登录客户机。密钥分发中心将授予凭单的凭单（TGT）发送至客户机。  
2.在连接的第一阶段，服务器将目标主体名称发送至客户机，该主体名称是 DB2 UDB 服务器服务的服务帐户名。通过使用服务器的目标主体名称和授予目标的凭证，  客户机向授予凭证的服务（TGS）请求服务凭单，该凭证也驻留在域控制器中。如果客户机的授予凭单的凭单和服务器的目标主体名称都有效，则 TGS 向客户机发出服务凭单。记录在数据库目录中的主体名称现在可能被指定为 name/instance@REALM。（此外，这是使用  DB2 UDB 版本 .1 及其后续版本的 Windows 2000 接受的当前 DOMAIN\userID 和 [email]userID@xxx.xxx.xxx.com[/email] 格式。）  
3.客户机通过通信信道（例如，它可能是 TCP/IP）将此服务凭单发送至服务器。  
4.服务器验证客户机的服务凭单。如果客户机的服务凭单有效，则认证完成。
  
可能会对客户机上的数据库进行编目，并对服务器的目标主体名称显式指定 Kerberos 认证类型。使用此方法，可忽略连接的第一个阶段。
  
如果指定了用户标识和密码，则客户机将请求该用户帐户的授予凭单的凭单并将其用于认证。
   
KRB_SERVER_ENCRYPT  
指定服务器接受 KERBEROS 认证或加密的 SERVER 认证方案。若客户机认证  是 KERBEROS，则使用 Kerberos 安全性系统认证客户机。如果客户机认证是 SERVER_ENCRYPT，则使用用户标识和加密密码认证客户机。如果未指定客户机认证，如有可能，客户机将使用 Kerberos，否则它将使用密码加密。对于其它客户机认证类型，返回一个认证错误。不能将客户机的认证类型指定为 KRB_SERVER_ENCRYPT   
注:

Kerberos 认证类型只有在运行 Windows 2000、Windows XP、Windows Windows Server 2003 和 AIX 操作系统以及 Solaris Operating Environment 的客户机和服务器上才受支持。另外，  客户机和服务器都必须属于同一个 Windows 域或属于可信域。在服务器支持  Kerberos 且某些（但并非全部）客户机支持 Kerberos 认证的情况下，应使用此认证类型。
   
DATA_ENCRYPT  
服务器接受加密的 SERVER 认证方案和用户数据的加密。认证显式地以与使用 SERVER_ENCRYPT 显示的相同方式工作。有关更多信息，请参阅认证类型。  
使用此认证类型时，加密以下用户数据：
  

•SQL 语句。  
•SQL 程序变量数据。  
•从处理 SQL 语句和包括数据描述的服务器中输出的数据。  
•查询输出的某些或所有答案集合数据。  
•大对象（LOB）数据流动。  
•SQLDA 描述符。
   
DATA_ENCRYPT_CMP  
服务器接受加密的 SERVER 认证方案和用户数据的加密。另外，此认证类型允许与不支持 DATA_ENCRYPT 认证类型的下层产品兼容。允许这些产品与 SERVER_ENCRYPT 认证类型连接，且无需加密用户数据。支持新认证类型的产品必须使用它。此认证类型仅在服务器的数据库管理器配置文件中才有效，用于 CATALOG DATABASE 命令时无效。   

GSSPLUGIN  
指定服务器使用 GSS-API 插件来执行认证。如果未指定客户机认证，服务器将服务器支持的插件列表，包括在 srvcon_gssplugin_list 数据库管理器配置参数中列示的任何 Kerberos 插件返回至客户机。客户机从列表中选择在客户机插件目录中找到的第一个插件。如果客户机不支持列表中的任何插件，则使用 Kerberos 认证方案（如果返回的话）认证客户机。如果客户机认证是 GSSPLUGIN 认证方案，则使用列表中第一个支持的插件来认证客户机。
   
GSS_SERVER_ENCRYPT  
指定服务器接受插件认证或加密的服务器认证方案。如果通过插件执行客户机认证，则使用服务器支持的插件列表中第一个客户机支持的插件来认证客户机。  
如果未指定客户机认证且在执行隐式连接（即，生成连接时，客户机不提供用户标识和密码），则服务器返回服务器支持的插件列表、Kerberos 认证方案（如果列表中的某个插件是基于 Kerberos 的）和加密的服务器认证方案。使用客户机插件目录中找到的第一个支持的插件来认证客户机。如果客户机不支持列表中的任何插件，则使用 Kerberos 认证方案认证客户机。如果客户机不支持 Kerberos 认证方案，使用加密的服务器认证方案来认证客户机，且连接将因为丢失密码而失败。如果 DB2 UDB 提供的 Kerberos 插件适用于操作系统或者为 srvcon_gssplugin_list 数据库管理器配置参数指定基于 Kerberos 的插件，则客户机支持 Kerberos 认证方案。
  
如果未指定客户机认证且在执行显式连接（即，同时提供用户标识和密码），则认证类型等价于 SERVER_ENCRYPT。

注:
1.        因为对配置文件本身的存取受到配置文件中信息的保护，所以在更改认证信息时，不要无意中将自己锁定在实例之外。下列数据库管理器配置文件参数控制对实例的存取：
        AUTHENTICATION *
        SYSADM_GROUP *
        TRUST_ALLCLNTS
        TRUST_CLNTAUTH
        SYSCTRL_GROUP
        SYSMAINT_GROUP
* 指示两个最重要的参数以及最可能引起问题的那些参数。
可以采取一些措施来确保这种情况不会发生：如果意外将自己锁在 DB2 UDB 系统之外，所有平台上都提供了一个故障保险选项，它将允许您使用具有较高特权的本地操作系统安全性用户，重设通常的 DB2 UDB 安全性检查来更新数据库管理器配置文件。此用户 始终 具有更新数据库管理器配置文件并校正该问题的特权。但是，这种绕过安全性检查的做法只限于对数据库管理器配置文件进行本地更新。不能以远程方式或对任何其它 DB2 UDB 命令使用故障保险用户。此特殊用户被标识为：
        UNIX(R) 平台：实例所有者
        NT 平台：本地“管理员”组的成员
        其它平台：由于在其它平台上没有本地安全性，因此所有用户无论如何都要通过本地安全性检查



以上文字可从《管理指南-实现》中找到。

[[i] 本帖最后由 wildhorse 于 2006-4-7 23:05 编辑 [/i]]