了解用户和组帐户与DB2 UDB的交互

DB2 UDB 安全模型主要包括两部分：身份验证（authentication） 和授权（authorization）。

身份验证

身份验证就是使用安全机制验证所提供用户 ID 和口令的过程。用户和组身份验证由 DB2 UDB 外部的设施管理，比如操作系统、域控制器或者 Kerberos 安全系统。这和其他数据库管理系统（DBMS）是不同的，如 Oracle 和 SQL Server，后者既可以在数据库本身中定义和验证用户帐户，也可在外部设施（如操作系统）中完成。

一旦用户 ID 和口令作为实例附件或数据库连接请求的一部分明确地提供给 DB2 UDB，DB2 UDB 就会尝试使用该外部安全设施验证用户 ID 和口令。如果请求中没有提供用户 ID 和口令，则 DB2 UDB 隐含使用登录到发出请求的工作站时所用的用户 ID 和口令。

实际的验证位置由 DB2 UDB 实例参数 AUTHENTICATION 的值决定。有不同的身份验证方案，包括让用户在 DB2 UDB 服务器上验证（使用服务器的安全设施）、在客户机上验证（允许 “单点登录” 访问）、使用 Kerberos 安全设施验证，或者用户定义的通用安全服务（Generic Security Service，GSS）插件验证。其他身份验证选项包括当用户名和口令以及数据在客户机和服务器之间的网络上传递时进行加密。为 AUTHENTICATION 参数选择的值依赖于具体环境和本地安全策略。关于各种身份验证方案的完整描述，请参阅 DB2 UDB 文档。

比如，图 1 中的连接语句供用户 bob 使用口令 bobpsw 连接到 finance 数据库。身份验证过程包括七个步骤：

CONNECT 语句传递给 DB2 UDB 服务器。

如果没有明确配置安全插件，则使用默认的安全插件。如果包含 finance 数据库的实例的 AUTHENTICATION 参数设为 SERVER（默认设置），连接请求中的用户 ID 和口令则由 DB2 UDB 服务器上的安全设施验证。默认插件将用户 ID 和口令发送给操作系统进行验证。操作系统确认bob/bobpsw 组合是否有效，把该信息返回给安全插件。安全插件激活 DB2 UDB 安全机制，对用户 bob 查询 DB2 UDB 目录表，看看该用户是否被授予了该数据库的 CONNECT 权限。默认情况下，CONNECT 特权被授予 PUBLIC，就是说任何通过身份验证的用户都能连接到数据库。DB2 UDB 安全机制验证用户 bob 或者返回错误。

安全插件把成功或者失败的消息返回给用户。如果用户没有通过身份验证，DB2 UDB 就会拒绝连接请求，并向客户机应用程序返回错误消息，如下所示：

清单 1. 用户身份验证失败时 DB2 UDB 返回应用程序的消息:

SQL30082N  Attempt to establish connection failed with security 
reason "24" ("USERNAME AND/OR PASSWord 
INVALID").  SQLSTATE=08001

DB2 UDB 服务器上的 DB2 UDB 诊断日志（db2diag.log）中也会出现类似于下面这样的记录：

清单 2. 用户身份验证失败时 DB2 诊断日志中的消息:

2005-07-09-16.18.33.546000-240 I729347H256        
LEVEL: Severe
PID     : 3888                 
TID : 604
FUNCTION: DB2 Common, Security, 
Users and Groups, secLogMessage, probe:20
DATA #1 : String, 44 bytes
check password failed with rc = -2146500502

在 Windows 上，诊断日志可以在数据库实例主目录中找到，默认为 C:\Program Files\IBM\SQLLIB\DB2。在 Unix 上默认位置是 /DB2/db2dump，其中 是实例所有者的路径。

如果遇到这样的消息，一定要确认连接到数据库的用户或应用程序是否提供了合法的用户 ID 和口令。该用户 ID 和口令必须存在于执行用户身份验证的设施中（由目标 DB2 UDB 实例的 AUTHENTICATION 参数决定）。

授权

授权是决定指定用户 ID 对特定数据库对象和动作的访问和特权信息的过程。DB2 UDB 在内部存储和维护用户/组的授权信息。每当提交一个命令时，DB2 UDB 执行授权检查以保证您有执行该动作的正确特权。

特权可以授予特定的用户或者用户组。用户和组的定义本身同样在 DB2 UDB 外部定义。作为组成员的用户自动继承该组的特权。授予用户的特定权限优先于和该用户参与的任何组关联的特权，并且一直有效，即使后来从组中删除了用户。就是说，明确授予用户的特权必须明确收回。

多数数据库对象都由一组相关的权限，可使用 SQL 语句 GRANT 和 REVOKE 分配给用户和组。比如，下面的 SQL 语句将 ADM.ACCTABC 表的 SELECT 权限授予用户 bob：GRANT SELECT ON TABLE ADM.ACCTABC TO USER BOB。

一旦发出该语句，用户 bob 就可以提交引用该表的 SELECT 语句。类似的，下面的 SQL 语句从 clerks 组收回 ADM.LEGERS 视图的 INSERT 权限：REVOKE INSERT ON VIEW ADM.LEGERS FROM GROUP CLERKS。

只能收回以前授予的权限。关于能够授予用户和组的各种数据库对象特权的详细信息，请参阅 DB2 UDB 文当。

必须指出，特别是对 DB2 UDB 新用户，GRANT 语句不会检验用户和组帐户是否存在于外部设施中。这意味着，可以把权限和数据库中存储的信息授予不存在的用户和组帐户。这就造成了一种错误的印象，即可以在 DB2 UDB 中定义用户和组。比方说，连接到 finance 数据库时可以发出下面的语句：

GRANT SELECT ON TABLE ADM.TAXCODE TO USER XYZ。

其中的 xyz 是一个任意的字符串，没有映射为外部安全设施中的已有用户，然后 DB2 UDB 就会在其 GUI 工具或者某些目录表中显示 xyz，如图 2 所示。但这并不意味着存在或创建了名为 xyz 的用户。

图 1 下方显示了一个授权场景的例子。这个用户叫 bob，已经成功连接到数据库，现在尝试对表 ADM.TAXCODES 执行 SELECT 语句。DB2 UDB 查看其目录表，看看该用户是否被授予了这个表的 SELECT 权限。因为此权限已经授予 bob，DB2 UDB 允许执行 SELECT 语句。

如果用户未经授权而对某个对象执行一种操作，DB2 UDB 就会拒绝操作并向客户机应用程序返回错误信息。比方说，如果用户 bob 尝试向 ADM.TAXCODES 表中插入一行，但是没有足够的权限，就会返回下面的错误消息：

清单 3. 用户授权失败时 DB2 UDB 返回的消息:

DB21034E  The command was processed 
as an SQL statement because it 
was not a valid Command Line 
Processor command.  During SQL 
processing it returned:
SQL0551N  "BOB" does not 
have the privilege to perform 
operation "INSERT" on object "ADM.TAXCODES".  
SQLSTATE=42501

如果遇到类似的消息，一定要确认连接到数据库所提供的用户 ID 是否具有执行目标操作的适当权限。必须明确授予该用户此特权，或者该用户属于拥有该特权的组，或者该用户是超级用户。

超级用户

可以为某些用户组分配特定的实例和数据库权限。DB2 UDB 定义了超级用户授权的层次结构（SYSADM、SYSCTRL、SYSMAINT、SYSMON），每一种都具有执行管理操作子集的能力，比如创建数据库、迫使用户离开系统和对数据库进行备份。关于授权级别的详细讨论请参阅 DB2 UDB 文当（参见 参考资料）。

可以使用相关的实例级参数配置实例的授权（SYSADM_GRP、SYSCTRL_GRP、SYSMAIN_GRP、SYSMON_GRP）。每个参数可以设置为具有该授权的用户组名（在 DB2 UDB 外部定义）。

比如，如果定义组 snrdba 包含所有高级 DBA 用户帐户，就可使用下面的命令将 SYSADM_GRP 实例参数值设为 snrdba，从而使所有这些用户成为 SYSADM 超级用户:

清单 4. 更新 SYSADM_GRP 实例参数

UPDATE DBM CFG USING SYSADM_GRP snrdba
	db2stop
	db2start

snrdba 组中的所有用户都将拥有和 SYSADM 授权级别关联的全部特权，从而能够执行授权级别所需要的全部管理任务。

以这种方式定义授权就可以区分 DB2 UDB 管理员和系统/网络管理员。比如，DBA 可能要求拥有 DB2 UDB 实例的全部管理授权，但不需要本地机器或网络的管理授权。在这种情况下，可以将该 DBA 的用户帐户添加到对系统/网络没有完全访问权限、但是对 DB2 UDB 实例有完全访问权限的组，只要在 SYSADM_GRP 实例参数中指定该组名即可。

在 Windows 上的 DB2 UDB 默认安装中，这些实例级超级用户授权参数（SYSADM_GRP、SYSCTRL_GRP、SYSMAIN_GRP、SYSMON_GRP)）的值默认设为 NULL。这意味着超级用户权限被授予属于本地 Administrators 组的所有合法帐户。我们强烈建议明确将这些参数值改为合法的组名，以便防止未授权的访问。在 Linux 和 UNIX 安装中，这不是一个大问题，因为 NULL 值默认为实例所有者的基本组，而基本组在安装后只包含实例所有者的用户 ID。

还可以为用户分配一组数据库级的授权。数据库授权使用标准的 SQL GRANT 和 REVOKE 语句。关于这些数据库授权级别的更多信息，请参阅 DB2 UDB 文档（参见 参考资料）。

DB2 UDB 系统命令，如 db2、db2ilist、db2start、db2stop、db2iupdt 等，都是操作系统可执行文件。因此，运行这些命令的安全机制以文件的操作系统权限为基础。这些文件的权限在 DB2 UDB 安装时设置。

DB2 UDB 用户和组帐户命名规则

在 DB2 UDB 中，用户和组帐户必须遵守表 1 和 2 中所述的命名规则。这些限制是在定义帐户的外部设施中起作用的限制之外增加的。

(1) Windows NT®、Windows 2000®、Windows XP® 和 Windows Server® 2003 现在实际上限制为 20 个字符。

(2) 如果不使用 Client 身份验证，对于连接到 Windows NT、Windows 2000、Windows XP 和 Windows Server 2003 的非 Windows 32 位客户机，在明确指定用户名和口令时支持使用超过 8 个字符的用户名。

(3) DB2 UDB 内部使用名为 PUBLIC 的伪组，可以为其授权或者收回特权。PUBLIC 不是外部安全设施中定义的真正的组。它是把特权授予通过身份验证的任何用户的一种方式。

(4) 还有其他一些特殊字符也能使用，这取决于操作系统和在哪里使用 DB2 UDB。但是为了避免不一致性和潜在的问题，在数据库中命名对象时不要使用其他特殊字符。

用默认用户 ID（如 db2admin）安装 DB2 UDB 并使用弱口令（或者根本没有）可能将系统置于风险中。很多计算机病毒、蠕虫和特洛伊木马的设计都利用了弱口令。比方说，很多这类程序都尝试使用常见口令如 “password”、“123456”、“111111”、“db2admin” 等获得对系统的访问。因此不要使用简单的口令很重要。

在验证用户时口令也很重要。比如，在 Linux 和 UNIX 操作系统上，未定义口令被作为 NULL 处理。没有定义口令的任何用户都被视作使用 NULL 口令。从操作系统的角度来看，这是一种匹配，用户经过验证后就能连接到数据库。

DB2 UDB 安装需要和创建的用户/组帐户

DB2 UDB 需要一个具有管理权的用户帐户来执行安装。该用户所需要的具体权限依赖于安装 DB2 UDB 的平台。默认情况下，DB2 UDB 在安装过程中要创建多个用户和组帐户。这些帐户用于 “拥有” 和启动在服务器上运行的各种 DB2 UDB 服务和进程。

这一节介绍在 Windows、Linux 和 UNIX 环境中安装 DB2 UDB 所需要的用户特权。还说明在 DB2 UDB 默认安装过程中创建的各种用户和组。

Microsoft Windows 操作系统上需要的用户和组帐户：

如果在 Windows 操作系统上安装 DB2 UDB，将需要下列用户帐户：

1、Installation 用户帐户。

2、DB2 Administration Server（DAS）用户帐户 。

3、DB2 UDB 实例所有者用户帐户。

Installation 用户帐户：

在运行 DB2 安装向导之前，需要定义一个安装用户帐户。该帐户可以是一个本地或域用户帐户。该帐户必须属于要进行安装的机器上的 Administrators 组。如果使用域帐户，安装帐户必须属于将要创建其他安装用户帐户的域的 Domain Administrators 组。也可使用内置的 LocalSystem 帐户进行 DB2 UDB EntERPrise Server Edition 之外的其他所有产品的安装。

可以在安装之前定义其他用户帐户，也可以让 DB2 安装向导为您创建。所有用户帐户名必须遵守系统的命名规则和 DB2 UDB 命名规则。

DB2 Administration Server 用户帐户：

DB2 Administration Server（DAS）需要使用本地或域帐户。DAS 是一种特殊的服务，支持 GUI 工具并帮助完成管理任务。DAS 有一个分配的用户帐户，在 DB2 UDB 加载时用于启动该服务。在 DB2 安装向导中，其中有一个屏幕（如图 3 所示）提示选择用于启动 DAS 服务的用户帐户。

可以在安装 DB2 UDB 之前创建该用户帐户，然后在这里指定，也可以让 DB2 安装向导为您创建该帐户。默认情况下，向导将创建一个名为 db2admin 的新帐户（但是可以随意命名）。DAS 用户帐户也必须属于执行安装的机器上的 Administrators 组。如果让 DB2 安装向导创建新的域用户帐户，用于执行安装的用户帐户必须有创建域用户帐户的权限。

安装向导创建该帐户时自动授予下列用户权限:

1、作为操作系统的一部分。

2、调试程序。

3、创建 token 对象。

4、增加配额。

5、锁定内存页。

6、作为服务登录。

7、代替进程级的 token。

如果创建或指定了不同的帐户，一定要保证该帐户具有上述用户权限。为了保证正确设置了这些权限，打开 Windows 控制面板（Start > Settings > Control Panel）并双击 Administrative Tools 图标。双击 Local Security Policy 图标。对于上面列出的每种策略，保证该用户包含在授权的用户和组列表中。提供的口令不正确可能造成 DB2 UDB 启动过程中不能加载某些服务，有可能禁止执行特定的操作。

在安装过程中，还要告诉 DB2 安装向导使用同一个帐户（及指定给 DAS 的帐户）拥有和启动其他所有 DB2 UDB 服务。为此，一定要选中 “Use the same user name and password for the remaining DB2 UDB services（其他 DB2 UDB 服务使用同一用户名和口令）” 复选框（参见 图 3）。如果没有选中该复选框，向导就会提示选择拥有和启动创建的默认实例的用户帐户。其他所有 DB2 UDB 服务将使用内置的 Windows LocalSystem 帐户启动。

还要保证 DAS 用户帐户对环境中每个 DB2 UDB 系统具有 SYSADM 权限，这样在需要的时候可以启动或停止其他实例。默认情况下，在 Windows 环境中安装 DB2 UDB 后，属于 Administrators 组的任何用户都具有 SYSADM 权限。DAS 服务名称为 DB2DAS - DB2DAS00。

DB2 UDB 实例所有者用户帐户：

要拥有和启动 DB2 UDB 实例，需要一个本地或域帐户。可以在安装 DB2 UDB 之前创建 DB2 UDB 实例所有者用户帐户，也可以让 DB2 安装向导来创建。如果让 DB2 安装向导创建新的域用户帐户，执行安装使用的用户帐户必须具有创建域用户帐户的权限。该用户帐户也必须是执行安装的机器上 Administrators 组的成员。DB2 安装向导创建该帐户时自动授予下列用户权限：

作为操作系统的一部分： 调试程序、创建 token 对象、增加配额、锁定内存页、作为服务登录、代替进程级的 token。

如果创建或指定了不同的帐户，一定要赋予该帐户上述用户权限。为了保证正确设置了这些权限，打开 Windows 控制面板（Start > Settings > Control Panel）并双击 Administrative Tools 图标。双击 Local Security Policy 图标。对于上面列出的每种策略，保证该用户包含在授权的用户和组列表中。提供的口令不正确会造成 DB2 UDB 启动过程中无法加载服务，有可能禁止执行特定的动作。

在默认 Windows 安装中将自动创建一个名为 DB2 的实例。可以分别使用 db2icrt 和 db2idrop 工具程序创建其他实例或删除已有的实例。这些工具放在 DB2PATH\sqllib\bin 目录中，其中 DB2PATH 是安装 DB2 UDB 的位置。运行这些工具程序必须使用具有本地 Administrator 权限的用户帐户。如果创建实例时通过参数提供用户帐户和口令，那么将使用该帐户拥有和启动该服务。如果没有提供用户帐户和口令，则使用 LocalSystem 帐户。比如，下面的命令将创建一个新实例 devinst，并赋予 LocalSystem 帐户拥有和启动该实例进程的权限：

清单 5. 在 Windows 中创建新的 DB2 UDB 实例db2icrt devinst。

修改帐户信息：

安装后可以修改与每个 DB2 UDB 服务关联的用户帐户。此外，从 DB2 UDB Version 8.2 开始，可以使用内置的 LocalSystem Account（LSA）帐户启动 DB2 UDB 服务。在使用严格口令策略的系统上，使用 LSA 可能比较有利，因为 LSA 没有关联的口令。比如在有些环境中，要求用户每两个月换一次口令，否则其帐户就会被暂时锁住。这一策略要求修改指定用户帐户的口令来启动 DB2 UDB 服务。如果配置成启动某些服务的用户帐户被锁住，或者用户帐户的口令被修改了，但是没有在服务启动属性配置中更新，这些服务将无法启动。

在将任何 DB2 UDB 服务从专门的用户帐户移交给 LocalSystem 帐户之前，必须考虑到 LocalSystem 帐户不能访问 LAN 共享，因为不能在其他计算机上验证身份。因此必须保证 DB2 UDB 系统不使用其他机器上的任何文件资源。

在 LocalSystem Account（LSA）上下文中运行的应用程序使用本地的 DB2 UDB 隐式连接。如果开发在该帐户下运行的应用程序，必须知道 DB2 UDB 关于对象模式名以 “SYS” 开头的限制。如果应用程序包含创建 DB2 UDB 对象的语句，应该这样写：

对于静态 SQL，必须为 QUALIFIER 选项绑定一个值而不能使用默认值。

对于动态 SQL，要创建的对象必须显式地用 DB2 UDB 支持的模式名限制，否则必须将 CURRENT SCHEMA 注册表变量设置为某个模式。

图 4 列出了一些在活动 DB2 UDB 系统上运行的 DB2 UDB 进程。可以看到，每个进程都有一个相关的所有者（用户名）。关于与 DB2 UDB 有关的所有进程的说明，请参阅 “Everything You Wanted to Know About DB2 Universal Database Processes”（developerWorks，2003 年 4 月）。

要改变用于启动 DB2 UDB 服务的用户帐户，打开 Services 面板（Start > Settings > Control Panel > Administrative Tools > Services）。右击 DB2 UDB 服务查看其属性。单击服务属性窗口（图 5）上方的 Log On 选项卡。在该选项卡中，可以指定服务启动时使用的用户帐户，或者指定为 LSA。单击 OK 保存修改，关闭该服务的属性窗口。

一般来说，应该使用单独的、可标识的用户帐户来启动 DB2 UDB 服务。但是，环境中对用户帐户的控制越紧，就越有可能使用已有的用户帐户或者 LocalSystem 帐户启动这些服务。一旦设置一个帐户来运行某项服务，就不能删除该帐户，否则与该帐户相关的服务就无法启动。即便使用相同的名称重新创建该帐户也不能解决。在这种情况下，必须像前面所述的那样手工进入服务面板，重新配置启动该服务使用的用户帐户。

DB2USERS 和 DB2ADMNS 组:

从 DB2 UDB Version 8.2 开始，为 Windows 环境下的 DB2 UDB 增加了一些安全特性。作为 DB2 UDB 安装的一部分出现了一个新的选项，即在操作系统中创建两个新的组：DB2USERS 和 DB2ADMNS。一旦创建了这两个组，只有是这些组的成员的用户帐户才能访问系统上的 DB2 UDB 文件（包括命令和 DB2 UDB 创建的用户数据文件）。

可以改变这些组的名称，但应该尽量使用默认的名称。如果和已有的组名冲突，就会提示修改组名。如果在初始 DB2 UDB 安装中没有选择该选项，以后可以运行 db2secv82.exe 程序来启用。该程序在 DB2PATH\SQLLIB\BIN\ 目录中，其中的 DB2PATH 是安装 DB2 UDB 的位置。为了最大程度地保护服务器，应该启用该选项。

图 6 显示了启用该安全特性的情况。服务器文件系统中所有的 DB2 UDB 文件夹都要求用户必须是这两个组之一的成员，才能访问 DB2 UDB 文件夹和文件。

一旦使用 db2secv82.exe 命令启用了这种额外的安全特性，有两种办法可以取消：

立即再次运行 db2secv82.exe 命令，不对系统做任何改变。如果已经对系统做了任何改变，只能使用下面的方法。

将 EVERYONE 组添加到 DB2ADMNS 和 DB2USERS 组:

如果启用扩展安全特性，DB2 UDB 注册表变量 DB2_EXTSECURITY 将设置为 YES。这就告诉 DB2 UDB 需要进行附加的安全检查。如果创建 DB2ADMNS 和 DB2USERS 组后将 DB2_EXTSECURITY 的值改为 NO，文件和文件夹的访问权限仍然属于这两个组，但是 DB2 UDB 将不执行额外的安全检查。

Linux 和 Unix 操作系统上需要的用户和组帐户

NIS/NIS+ 的问题:

如果环境中使用了 NIS/NIS+ 或者类似的安全软件，必须在安装 DB2 UDB 之前 手工创建需要的 DB2 UDB 用户和组帐户。安装之前请参考 DB2 UDB 文档中的 NIS 主题（请参阅 参考资料）。

在 Linux 和 UNIX 操作系统中，安装和操作 DB2 UDB 通常需要几个用户和组帐户：

1、Installation 用户帐户

2、DB2 Administration Server（DAS）用户帐户

3、DB2 UDB 实例所有者用户帐户

4、DB2 UDB fenced 例程用户帐户

默认情况下，DB2 安装向导在 DB2 UDB 服务器安装过程中将自动创建这些用户和组帐户。也可以在安装过程中指定已有的用户帐户。

Installation 用户帐户：

必须使用 “root” 帐户安装 DB2 UDB。这是具有足够权限执行安装的惟一帐户。

实例所有者用户帐户：

在实例所有者的主目录中创建 DB2 UDB 实例。该用户帐户控制所有的 DB2 UDB 进程，拥有该实例所含数据库使用的全部文件系统和设备。在 DB2 UDB 安装过程中，DB2 UDB 实例所有者使用的默认用户 ID 是 db2inst1，默认组是 db2iadm1。如果该用户名已经存在，DB2 安装向导就会在默认的名称后面增加一个 1-99 的数字，直到遇到一个不存在的用户 ID。比方说，如果安装新的 DB2 UDB 时用户 db2inst1 和 db2inst2 已经存在，向导就会创建用户 db2inst3。如果该用户已经存在，向导就会继续搜索（db2inst4、db2inst5 等等），直到发现可用的用户。这种命名算法也适用于 fences 用户帐户和 DB2 管理服务器用户帐户的创建。

一种好的办法是将实例所有者用户帐户限制在实例所有者组中，不在其他任何组中包含它。这样有助于控制可以修改实例或者实例中任何对象的用户帐户和组的数量。

在默认的 Linux 或 UNIX 安装中，可以选择在安装过程中创建一个实例。也可以在以后使用 db2icrt 和 db2idrop 工具程序创建其他实例或者删除已有的实例。这些工具位于 DB2PATH/instance 目录中，其中 DB2PATH 在 AIX 上代表 /usr/opt/db2_08_01，在其他基于 Linux 和 UNIX 的系统上代表 /opt/IBM/db2/V8.1。运行这些工具程序必须使用 root 用户帐户。在 Linux 和 UNIX 上使用 db2icrt 工具创建新实例时，必须指定与该实例关联的 fenced 用户帐户。选择的实例名必须映射到将成为实例所有者的用户帐户名。比方说，要把已有的用户帐户 prodinst 作为新实例的所有者，应该在 db2icrt 命令中指定 prodinst 作为实例名。该实例将在拥有它的用户的主目录中创建。比如，下面的命令创建了一个新实例 devinst，它属于 devinst 用户帐户，并使用已有的用户帐户 devfenc 作为 fenced 用户帐户：

清单 6. 在 Linux 和 UNIX 上创建新的 DB2 UDB 实例 db2icrt -u devfenc devinst。

DB2 UDB 不支持直接以 root 帐户作为数据库管理员。应该使用 su - 命令切换到数据库管理员（实例所有者）帐户。

DB2 Administration Server 用户帐户：

DB2 Administration Server（DAS）用户帐户用于在系统上运行 DAS 进程。默认安装过程中创建的默认用户 ID 是 dasusr1，默认组是 dasadm1。DB2 UDB GUI 工具还使用 DAS 帐户对本地服务器实例和数据库执行管理任务。每台机器上只需要一个 DAS。它可以管理服务器上定义的所有实例。DAS 用户帐户必须不同于实例所有者用户帐户。

一旦使用该帐户启动 DAS 进程，也必须使用该帐户停止。因此在 Linux 或 UNIX 上，必须使用 su - 命令切换到 DAS 用户帐户以便启动和结束 DAS 进程。

fenced 用户帐户：

fenced 用户帐户用于在 DB2 UDB 引擎使用的地址空间（内存）之外运行用户定义函数（UDF）和存储过程。有时候，如果一个过程或函数不稳定或者在测试中，那么应该将其定义为 FENCED，这样就可以在自己的进程地址空间中运行。这样，如果该函数或过程崩溃或者异常终止，也不会对其他实例进程产生任何影响。为 fenced 用户创建的默认用户帐户是 db2fenc1，默认的组是 db2fadm1。由于安全的原因，我们建议不要使用实例所有者帐户作为 fenced 用户帐户。如果不需要这个层次的安全，比方说是在测试环境中运行，或者不准备使用 fenced UDF 或存储过程，可以直接使用实例所有者帐户而不必创建其他用户帐户。在创建新的实例时，必须在实例创建命令中指定 fenced 用户帐户（db2icrt ... -u ）。

为其他 Linux 和 UNIX 用户建立 DB2 UDB 环境:

Linux 和 UNIX 环境在用户级上强制实施高安全策略，与一个用户帐户关联的文件和进程不能被其他用户直接访问。默认情况下，创建新的 DB2 UDB 实例时，一个特殊的 DB2 UDB 环境脚本 db2profile 也被添加到实例所有者的系统配置文件中，每次实例所有者登录到系统时都要使用该文件。这些脚本设置对数据库环境的访问，允许实例所有者执行 DB2 UDB 命令。为了让系统上的其他用户访问实例和 DB2 UDB 环境，他们也必须运行同样的脚本。一种办法是 “提供” DB2 UDB 实例所有者的 .profile 文件（或者该 .profile 文件引用的 db2profile 文件）。如果使用 Bourne 或 Korn shell ，那么可以编辑目标用户帐户的 .profile 文件，使该用户登录到系统时自动运行 db2profile 脚本。对于 C shell 用户，可以编辑 .login 文件让它运行 db2shrc 脚本文件。为了选择要使用的实例，请在 .profile 或 .login 脚本文件中添加下面的语句，或者在用户需要访问 DB2 UDB 的终端窗口中发出该语句（注意需要句点（.）和空格）：

Bourne 或 Korn shell： . INSTHOME/sqllib/db2profile

C shell： source INSTHOME/sqllib/db2cshrc 其中 INSTHOME 是要使用的实例的主目录。

对于主目录中有自定义脚本版本的用户：

Bourne 或 Korn shell： . USERHOME/db2profile

C shell： source USERHOME/db2cshrc，其中 USERHOME 是用户的主目录。

如果需要同时使用多个实例，那么对使用的每个实例在单独的 终端窗口中运行该脚本。

调度程序用户帐户

如果要启用 DB2 UDB 中的调度设施，需要一个调度程序用户帐户。如果工具目录数据库位于远程服务器上，DB2 UDB 调度程序将使用该帐户连接。工具目录数据库包含在 DB2 UDB 服务器上调度运行的所有任务的元数据（比如计划在每个周日早上一点钟运行的备份任务）。调度设施的设计不要求存放工具目录数据库和计划运行任务的 DB2 UDB 服务器是同一个服务器。在这种情况下，DB2 UDB 服务器上的调度程序需要连接到工具目录数据库，以便检索运行任务需要的信息。

调度程序帐户由 DAS 配置参数 SCHED_USERID 控制。只有当工具目录数据库和 DB2 管理服务器不在同一台机器上时该参数才有用。可以使用 db2 get admin cfg 命令查看该参数的值。

要修改该参数的值，可使用 db2admin setschedid Word> 命令，其中 和 是调度程序用于连接到远程工具目录数据库的用户 ID 和口令。

清单 7 显示了将调度程序 ID 设为 xtradba 的情况。

清单 7. 可配置 DAS 参数及其值的清单

C:\>db2 get admin cfg

Admin Server Configuration

Authentication Type DAS                (AUTHENTICATION) = SERVER_ENCRYPT

DAS Administration Authority Group Name  (DASADM_GROUP) =

DAS Discovery Mode                           (DISCOVER) = DISABLE
Name of the DB2 Server System               (DB2SYSTEM) = TEDWAS
Java Development Kit Installation Path DAS   (JDK_PATH) =
C:\Program Files\IBM\SQLLIB\java\jdk\
Java Development Kit Installation Path DAS   (JDK_64_PATH) =

 DAS Code Page                            (DAS_CODEPAGE) = 0
 DAS Territory                           (DAS_TERRITORY) = 0

 Location of Contact List                 (CONTACT_HOST) =
 Execute Expired Tasks                   (EXEC_EXP_TASK) = NO
 Scheduler Mode                           (SCHED_ENABLE) = ON
 SMTP Server                               (SMTP_SERVER) =
 Tools Catalog Database                    (TOOLSCAT_DB) = TOOLSDB
 Tools Catalog Database Instance         (TOOLSCAT_INST) = DB2
 Tools Catalog Database Schema         (TOOLSCAT_SCHEMA) = TOOLSDB
 Scheduler User ID                                = xtradba

结束语

本文考察了 DB2 UDB 和用户/组帐户的基本交互。总结了 DB2 UDB 如何执行用户身份验证和用户/组授权，以及如何为 DB2 UDB 实例定义超级用户。还介绍了 DB2 UDB 安装需要和/或创建的默认用户和组帐户，以及如何配置它们。更好地理解用户/组帐户与 DB2 UDB 的交互，可以为您的环境计划和实现最优化的用户/组帐户设置。