Domino 域 A 中的用户如何访问 Domino 域 B 中的数据库

2008 年 9 月 08 日

在日常工作或测试中，我们常常需要用某 Domino 域中的一个固定用户 ID（比如收发邮件的 ID）去访问其他 Domino 域中的数据库。用同一个 ID 访问不同域中的数据库有多个优点，一来可以避免在多个 Domino 域中维护和同步多份用户信息，大大减轻了管理员的工作负担；二来终端用户用同一个 ID 就可以访问不同域中的数据库，避免了不同场所的重复切换和密码输入。本文将以一个实际的案例，图文并茂的介绍怎样设置才能使 Domino 域 A 中的用户如何访问 Domino 域 B 中的应用程序数据库。本文面向 Notes/Domino 的所有用户和初级管理员。

案例介绍

张三是公司 COMP 中的一名测试工程师，他所在的部门是位于北京的测试部 DEPTA 。 COMP 的邮件系统和应用程序系统均采用 Notes/Domino，无论是收发邮件还是访问报销系统、休假系统等均需要使用 Notes ID 通过 Notes Client 来进行。 COMP 的 Domain 是 /COMP, 因此张三使用 Notes ID San Zhang/COMP 进行邮件收发。张三的部门 DEPTA 新搭建了一台 Domino 应用程序服务器 APP/DEPTA，该服务器将存放部门专用信息，比如新员工培训程序，部门 BUG 管理系统等等。张三是该服务器的管理员，现在张三的任务是对本部门的 Domino 应用程序服务器 APP/DEPTA 做一些设置，使部门的员工在不切换场所的情况下，用收发邮件的 Notes ID（*/COMP）就可以访问 APP/DEPTA 中的数据库。

在本案例中用到的所有 Notes/Domino 的版本均为 6.52 英文版。

回页首

Domino 服务器的安全机制

在介绍怎样设置的步骤之前，我们最好了解一下 Domino 服务器的安全机制，这将有助于我们更好的理解。 Domino 服务器有多级安全设置，与本文相关的安全设置有：服务器级别的安全设置、ID 级别的安全设置以及应用程序级别的安全设置。

服务器级别的安全

Lotus Domino 服务器是实施安全管理的第一道关卡，管理员可以限制哪些用户或服务器可以访问该服务器，而哪些不可以；管理员同样也可以限制用户或服务器在该服务器上的操作，比如，限制用户或者服务器在该服务器上创建新的数据库副本或者使用路由连接的权限。

同样都是系统管理员，因为职责不同，需要的权限也不同；在服务器级别，你也可以定义拥有不同权限的管理员，比如，系统管理员能通过 Domino 服务器控制台执行操作系统的命令，而数据库管理员则有对数据库进行管理的权限。

ID 级别的安全

Lotus Notes 或者 Lotus Domino ID 能够唯一标识一个用户或服务器。 Domino 服务器使用 ID 中的信息来控制用户或服务器对其他服务器或应用程序的访问权限。管理员的一项职责就是保护 ID，防止未被授权的用户使用这些 ID 来访问 DOMINO 服务器。

在某些组织里，为了安全，要访问服务器 ID（Server ID）或者人 cert id，需要多个管理员输入密码，这可以防止重要的 ID 被某个单独的人控制。

应用程序级别的安全

在用户或者服务器得到了访问该服务器的许可后，要访问某个 Domino 的应用程序，还受到数据库访问控制列表（ACL）的限制。数据库访问控制列表包含了用户、用户组或者服务器的 ID 以及权限和角色信息。

回页首

设置步骤

1. 在 APP/DEPTA 的服务器文档的安全设置中，修改 Access Server 字段，允许 COMP 域的用户访问 APP/DEPTA 。

   步骤 1：打开 Administrator 客户端，以 administrator 的身份登录到 APP/DEPTA 服务器上。切换到 Configuration 页面，选择 Server->All Server Documents，双击打开 APP/DEPTA 的 Server document 。

   步骤 2：进入 APP/DEPTA 的 Server document 的编辑模式，选择 Security 页面，找到字段 Access Server 。该字段控制着哪些用户、用户组或服务器可以访问本服务器。管理员可以在此进行设置。

   在本案例中，输入 */COMP 和 */DEPTA，以逗号分隔，允许 DEPTA 域和 COMP 域的用户访问 APP/DEPTA，如下图所示：

   
   
   图 1
   
   
   

   步骤 3：保存对 Server Document 的修改。

2. 用 APP/DEPTA 的 cert id 对 COMP 域的 ID 进行交叉验证

   步骤 1： 在 Administrator 客户端中，仍然选择 Configuration 页面。在右边的工具栏里，选择 Certification > Cross Certify...

   步骤 2：在弹出的对话框中，选择 APP/DEPTA 做为 Server，选择域 DEPTA 的 cert id，如图 2 所示，点击 OK 按钮。

   
   
   图 2
   
   
   

   步骤 3：输入 cert id 的密码。

   
   
   图 3
   
   
   

   步骤 4：选择 Zhangsan.id 做为被验证的对象。

   
   
   图 4
   
   
   

   步骤 5：缺省情况下，在下图中，Subject name 为 /COMP，另外可选的对象为 San Zhang/COMP 。如果选择 /COMP，那么在做过交叉验证后，服务器 APP/DEPTA 的地址本里就会存储颁发给 /COMP 的交叉认证（cross certificate）；如果选择 San Zhang/COMP, 服务器的地址本里就只存储颁发给 San Zhang/COMP 的交叉认证。在本案例中因为整个部门的人都需要有权限访问 APP/DEPTA，所以我们选择 /COMP 。点击 Cross certify 按钮。如下图所示：

   
   
   图 5
   
   
   

   步骤 6（可选）：在做完交叉验证后，你可以切换到视图 Certificates->Certificates 进行检查，在 Notes Cross Certificates 下找到我们刚刚创建的交叉认证。如下图所示：

   
   
   图 6
   
   
   

3. 修改 APP/DEPTA 上的数据库的 ACL

   在修改了服务器的安全设置和做过交叉验证后，/COMP 的用户就可以访问 APP/DEPTA 了。但是如果要访问某个具体的应用程序，管理员仍然需要设置访问权限控制列表（ACL）。如果用户不在该应用程序的 ACL 中，那么该用户就不能访问此应用程序。

   管理员可以通过 Notes Client 或者 Administrator Client 来设置 ACL 。在本案例中，*/COMP 作为一个混合组被加入到 ACL 中，并且被赋予了 Editor 的权限，如下图所示。

   
   
   图 7
   
   
   

4. 重启服务器 APP/DEPTA 。

回页首

小结

在经过上述的设置后，Zhang San 用自己收发邮件的 ID San Zhang/COMP 就可以轻松的访问位于 APP/DEPTA 上的数据库应用程序，同样，其他的员工如果有 /COMP 的 ID，也可以访问 APP/DEPTA 。需要注意的一点是，由于本文只是一个教程，所以并没有充分的考虑安全设置，在实际的生产环境中，管理员在使用 */COMP 的时候需要特别小心，因为 */COMP 包含所有 COMP 域的用户。