级别： 初级 Sam Yang (sayang@us.ibm.com), 顾问软件工程师, IBM
Edward Whitehead (edward.whitehead@us.ibm.com), 顾问软件工程师, IBM
2004 年 8 月 01 日 本文介绍了使用 IBM Directory Integrator 5.1.2 作为应用程序框架开发的 IBM / Tivoli 安全产品的用户数据导入与同步工具。
简介
现在很多公司希望提高其 IT 基础设施的安全性。公司实现这一目标的方法之一就是使用工具实现和增强他们的 IT 安全策略。IBM Tivoli 部门销售的两种产品可以帮助他们实现这一目标：IBM Tivoli Identity Manager 和 IBM Tivoli Access Manager。
IBM Tivoli Identity Manager 是一种用于管理用户和帐户定义的产品。 通过控制系统上的帐户定义， 它允许公司控制用户能够访问 哪个系统。
IBM Tivoli Access Manager 是一种访问控制产品。它通过强制实施访问控制策略防止对受保护的资源进行未授权的访问。Access Manager 可用于保护多种类型系统资源的访问，从单个文件到 Web 站点。
Identity Manager 和 Access Manager 产品互相补充。Identity Manager 控制系统中可以存在什么样的用户帐户，而 Access Manager 控制授权用户在系统上执行的操作。为了完成这些任务，两种产品都维护用户的注册信息。 这些产品对定义在注册表中的用户强制实施用户访问和授权策略。
安装 Identity Manager 之后必须填充它的用户注册表，使其能够管理这些用户的系统访问。因为 Identity Manager 管理 Access Manager 中的用户定义，Identity Manager 可以填充 Access Manager 用户注册表。Identity Manager 用户注册表的初始填充技术就是本文的主题之一。
Identity Manager 和 Access Manager 都部署完成并且填充各自的用户注册表之后，有可能需要随着 Identity Manager 中对用户属性的修改不断更新 Access Manager 中的用户属性值。本文将描述从 Identity Manager 管理或者同步 Access Manager 用户属性的技术。
用户数据导入与同步工具
本文介绍使用 IBM Directory Integrator 5.1.2 作为应用程序框架开发的 User Data Importing and Synchronization Utility。
Directory Integrator 是一种数据迁移和同步产品，内置支持多种不同平台上的注册表和数据源。对于这类集成方案它是一种理想的工具。
为了理解所描述的解决方案，读者应该熟悉 Access Manager 和 Identity Manager 产品的高层概念。
高层概述
Identity Manger 用户注册表的初始填充可以利用多种来源的用户定义来完成。本文介绍了使用以 Directory Integrator 为基础的工具从公共目录或者 Access Manager 用户注册表填充 Identity Manager 用户定义。如果用户定义不在此范围之内，可以变通本文所述的实现使用其他的用户定义来源。
在 Access Manager 和 Identity Manager 安装、配置并使用用户定义填充之后，一些用户属性的值不可避免要进行修改。Identity Manager 提供了丰富的更新用户属性值的功能。因为 Access Manager 可以配置成在进行授权决策时使用用户属性的值，Identity Manager 用户注册表中修改的值也必须在 Access Manager 用户注册表中相应更新。通过更新可以保证 Access Manager 的授权决策依据的是正确的值。Access Manager 用户注册表可以通过使用基于 Directory Integrator 的同步工具保证是最新的数据，后者使用 Identity Manager 用户注册表的值更新 Access Manager 用户注册表。
客户场景
下面描述了同时使用 Identity Manager 和 Access Manager 的客户可能使用的三种不同部署场景。每种场景都描述了帮助部署的可用工具。这些工具在本文后面还将进一步介绍。
1. 已经部署了 Access Manager
Access Manager 已经部署，并且在 Access Manager 用户注册表中创建了所有客户的用户定义，现在又安装了 Identity Manager。这种情况，Identity Manager 管理员将把 Access Manager 用户注册表中已经定义的用户数据导入到 Identity Manager 用户注册表中，因此 Identity Manager 处于用户管理的核心。
要把 Access Manager 用户注册表中的用户导入到 Identity Manager，管理员可以使用
TAMtoTIMImport或
MDTAMtoTIMImport任务。使用
TAMtoTIMImport访问只有单个域的 Access Manager 部署，而
MDTAMtoTIMImport 则用于部署有多个域的 Access Manager。
创建 Identity Manager 用户之后，Identity Manager 管理员可以在 Identity Manager 中与 Access Manager 服务进行调解，以便在 Identity Manager 中创建与 Access Manager 相匹配的帐户。Identity Manager 调解（reconciliation）特性把帐户从代理导入到服务器。帐户根据别名（alias）用户属性的值分配给 Identity Manager 用户。别名的值必须与导入的帐户名匹配。因为
TAMtoTIMImport和
MDTAMtoTIMImport 任务将设置 Identity Manager 用户的别名属性，可以自动确定调解的 Access Manager 帐户的所有者。
2. 用户定义存在于公共资料库中
没有安装 Access Manager 和 Identity Manger。公司所有的用户定义都放在其他应用程序使用的公共目录中。现在已经安装了 Identity Manager 和 Access Manager。这种情况下，Identity Manager 管理员将把用户定义从公共目录导入到 Identity Manager 中。
管理员可以使用
DirectorytoTIMImport任务从目录中把已有的用户定义导入到 Identity Manager 中。可以配置 Identity Manager，为导入的每个用户都规定一个 Access Manager 帐户。这样规定之后，就可以同时填充 Identity Manager 和 Access Manager 用户注册表。
3. 同步 Access Manager 用户定义
Access Manager 和 Identity Manager 都已经部署并使用。Access Manager 中已经使用 Access Manager 用户属性定义了一些授权策略。使用 Identity Manager 界面管理 Identity Manager 用户的属性。因为用户属性在 Identity Manager 用户注册表中更新，而不是在 Access Manager 用户注册表中更新，进行授权决策时 Access Manager 中不一定有正确的用户属性值。
这种情况下可以使用
TIMtoTAMSync 任务用 Identity Manager 用户注册表中的变动来更新 Access Manager 用户注册表。
设计上的考虑
Identity Manager 4.5 和 Directory Integrator 5.1.2 中 DSMLv2 的增强
Identity Manager Release 4.5 中支持一种称为“IDI Data Feed”的配置服务类型，用于在 Directory Integrator 和 Identity Manager 服务器之间交换用户数据。“IDI Data Feed”服务使用 Directory Services Markup Language version 2（目录服务标记语言版本2，DSMLv2）格式和 Directory Integrator 通信。在 Directory Integrator version 5.1.2 中增加了 DSMLv2 EventHandler 和 JNDI 连接器中的 DSMLv2 支持。这种增加极大改进了 Directory Integrator 和 Identity Manager 的集成能力。本文所述的解决方案使用带有 DSML2InitialContextFactory 驱动程序支持的 Directory Integrator JNDI 连接器来将用户条目导入到 Identity Manager。
配置文件、AssemblyLines、连接器和工作模式
这一工具的开发涉及到 Directory Integrator 配置文件的设计。Directory Integrator 配置文件包括一个客户设置的属性文件和几个 AssemblyLines (ALs)。AssemblyLine 用于一项特定的处理任务，由许多在不同数据源上以不同模式操作的连接器组成。
该工具中使用的连接器类型包括：
- LDAP 连接器
- Lotus Notes 连接器
- LDAP changelog 连接器
- JNDI 连接器
- 文件系统连接器
该工具中连接器的工作模式包括：
- Iterator（迭代）：该连接器处理定义目录（称为搜索库）中的所有数据记录，后者传递一组检索条件。
- Lookup（查找）：连接器查找符合定义条件（称为链接条件）的数据记录并检索其属性。
- AddOnly（只增）：这种模式下连接器在数据源中创建数据记录。通过映射在以前的连接器中传递的工作属性定义记录。
- Update（更新）：这种模式下连接器搜索和更新符合链接条件的数据记录。
通过这个工具，Identity Manager 或者 Access Manager 管理员可以加载一个配置文件并为集成任务选择特定的 AssemblyLine。
客户环境设置
运行这些方案的管理员应该能够为 Identity Manager 和 Access Manager 提供身份验证凭证，以便在 AssemblyLines 中使用。环境参数包括主机名、用户 ID、口令，等等。所有环境参数均存储在属性文件中。在本工具中，属性文件使用相同的名称作为配置文件，但使用 .properties 作为后缀。属性文件内容在载入时被导入到配置文件中。第一次使用之后，如果管理员请求加密的话，属性文件可以被加密。
支持的注册表
为了从 Access Manager 将用户定义导入到 Identity Manager，该工具支持 Access Manager 所使用的三种类型的注册表：LDAP Directory、Active Directory 和 Domino Directory。Identity
Manager to Access Manager Synchronization 解决方案只支持 LDAP 作为 Access Manager 注册表。同时，必须启用 LDAP 更改日志。
这些工具已经尽可能设计得自动化。例如，当从 Access Manager 检索用户数据时，首先使用额外的连接器来发现 Access Manager 用户索引，然后第二个连接器检索属性。这种方式的话，用户不必输入搜索基准。在同步的情况下，监视更改日志可以确保连接器自动地检测所有 Identity Manager 用户属性更改。
性能
该工具的性能主要取决于 Directory Integrator。然而，工具的算法和错误处理也影响了性能。错误转储只应该在调试时才打开，因为它会对性能造成较大影响。
安全关注
1. 保护配置文件和客户设置的安全。
管理员可以设置配置文件的密码，并为属性文件选择加密选项。
2. 在目录和 Directory Integrator 之间启用 SSL。
目录和 Directory Integrator 之间的通信可以启用 SSL。要获得更多信息，请参考 IBM Directory Integrator 5.1.2 Reference 手册。
3. 在 Directory Integrator 和 Identity Manager 之间启用 SSL。
Directory Integrator 和 Identity Manager 之间的通信可以启用 SSL。要获得更多信息，请参考 Identity Manager 4.5 Server Configuration 手册。
配置文件例子
TAMtoTIMImport.xml
这一配置文件的任务是在单一域中搜索 Access Manager 用户，导入 Access Manager 用户数据到 Identity Manager，以及创建 Identity Manager 用户。三个 AssemblyLines 内置在这一配置文件中。
AssemblyLine: LDAPImport
这一 AssemblyLine 从 LDAP 注册表中检索 Access Manager 用户数据，比如 IBM Directory、Sun ONE (以前称为 iPlanet) Directory，等等。
第一个连接器工作在 Iterator 模式下。它搜索
secAuthority=Default下的
cn=users 条目。搜索过滤器定义为 objectClass=secMap。每条返回的记录都包含了 secdn 属性，这是 Access Manager 可识别的用户 dn。
有了从第一个连接器获得的 secdn 属性，
第二个连接器工作在 lookup 模式下，并搜索匹配 secdn 的 dn。如果找到的话，它检索 cn、sn、uid 和其他属性。在这个过程中，它使用 Directory Integrator 的 “After Lookup”用户退出特性，运行一个 JavaScript 脚本，从而排除
Security Master 用户：
代码示例：从 TAM 用户中排除 Security Master 用户
var tdn=conn.getString("$dn");
if (tdn.indexOf("SecurityMaster",0) > 0)
system.skipEntry();
else
task.logmsg("---> Access Manager user data is read." + tdn);
|
可以修改这一 JavaScript 脚本以排除更多的特定用户，这样就可以修改任何 Access Manager 超级用户。
第三个连接器在其他 AssemblyLines 中更加常见，它用于 Identity Manager 导入。这个连接器是一个 JNDI 连接器，工作在 AddOnly 模式下。要了解 Identity Manager 4.5 中支持 DSMLv2 的更多信息，包括 JNDI 连接器的设置，请参阅
Identity Manager 4.5 Policy and Organization Administration Guide。
该连接器从前一连接器取得工作属性，并将它们映射到以下 Identity Manager 属性：
cn、sn、objectClass、displayName、givenName、uid、erAliases。
前三个是 Identity Manager 必需的属性。如果缺失其中任何一个，将无法创建 Identity Manager 用户。Identity Manager 或 Access Manager 管理员也可以提供一种定制属性映射模式或者管理员可以修改当前映射，这可以通过 Directory Integrator 管理工具来完成。
erAliases 是一种多值变量，它从 Access Manager uid 和 cn 映射而来。该属性在 Identity Manager 用户创建之后，用于 Access Manager 帐户调解。
AssemblyLine: ADImport
该 AssemblyLine 从 Active Directory 注册表检索 Access Manager 用户数据。当前，Access Manager 还只支持 Windows 2000 server 中的 Active Directory。
类似于前一个 AssemblyLine，第一个连接器 FindADTAMUsers 工作在 Iterator 模式，并在客户域从 Active Directory 搜索所有 Access Manager 用户。管理员需要提供搜索基准的活动目录域名。用域名作为“domain_name”，搜索基准是：
cn=Users,cn=default,cn=tivoli pd domains,dc=domain_name,dc=com
搜索过滤器是：
objectCategory=cn=urafuser,cn=schema,cn=configuration,dc=domain_name,dc=com
每一返回的记录包含 urafregistryUID 属性，它是用户在 Access Manager 中的 dn。
接着
第二个连接器GetADTAMUsers 查找目录，以发现等于 urafregistryUID 的 dn，并检索用户属性，将其导入到 Identity Manager。同时，如果正在搜索的 dn 是“sec_master”或“ivmgrd-master”，条目将被跳过。
该 AssemblyLine 中的
第三个连接器用于 Identity Manager 导入，它与前一 AssemblyLine 中的相同。
AssemblyLine: DominoImport
该 AssemblyLine 从 Domino 目录中检索 Access Manager 用户数据。
该 AssemblyLine 中的第一个和第二个连接器是 Lotus Notes 连接器，它通过本地 Notes 客户机与 Domino 目录进行交互。
第一个连接器搜索 Domino 服务器上的 PDMdata.nsf 数据库，数据库视图设置为 URAF User Objects。每一个返回的记录都包含了 UserID 属性，它表示一个 Access Manager 用户。
第二个连接器 查看 Domino 目录中的 names.nsf 数据库，以发现从前一连接器获得的匹配 UserID 的 ShortName。如果发现的话，连接器检索 First name、Last name，等等，用于作为 AssemblyLine 的输入工作属性。为了避免修改 Access Manager 管理员帐户，使用 JavaScript 过滤器来排除 Access
Manager 管理员。
第三个连接器用于 Identity Manager 导入，它与前一 AssemblyLine 中的相同。
MDTAMtoTIMImport.xml
由于 Access Manager 只在 LDAP Directory 中支持多域用户，这一配置文件只包括一个 AssemblyLine，用于检索来自 LDAP 注册表的多域中的 Access Manager 用户，并将它们导入到 Identity Manager。
第一个连接器搜索 secauthority=default 下的 cn=Subdomains。搜索过滤器是 secmap。从每一返回的对象 dn 中进一步检查 cn=Users。如果未找到“cn=Users”，将跳过该条目。同样，如果 dn 是 Master，该记录也将被跳过。从该连接器返回的最终记录包括来自所有域的 Access Manager 用户。如果不想从所有域导入的话，可以修改 hooks 下的 Java Script 脚本，以排除那些不想包括的域。
在多域中搜索之后，第二和第三个连接器的工作方式与单域 AssemblyLine 中相同。
DirectorytoTIMImport.xml
该配置文件包含两个 AssemblyLines：
LDAPUserstoTIM和
ADUserstoTIM。第一个检索公共 LDAP 目录中的用户数据，而第二个检索活动目录中的用户数据。
因为每一公共注册表中的用户属性可能十分不同，该工具示例是非常基本的。它只检索 cn、sn 和 uid 属性，将它们映射到相应的 Identity Manager 用户创建的 Identity Manager 用户属性。通过修改 AssemblyLine 中连接器的 Input Map 和 Output Map，可以很容易地添加更多属性。
每一 AssemblyLine 中的连接器十分类似于 TAMtoTIMImport.xml。然而，搜索基准必须手工定义。
TIMtoTAMSync.xml
该配置文件用于同步 Identity Manager 用户属性与 Access Manager 用户属性。该同步设计用于那些 Access Manager 用户，他们拥有 Identity Manager 帐户。两个 AssemblyLines 内置在这一配置文件中。第一个 AssemblyLine 用于无条件同步，而第二个 AssemblyLine 用于监视 LDAP 更改日志并启动动态同步功能。第二个 AssemblyLine 在这里被引入。
有关这一任务值得注意的一件事情是，它假定其用户理解如何组织 Identity Manager 和 Access
Manager 用户注册表。这一任务已经开发出来，使用的是 Identity Manager 4.5 和 Access
Manager 4.1 或 5.1。这些产品的未来版本可能会修改它们组织用户注册表的方式，因此需要修改这一任务，以便它能继续工作。
AssemblyLine: synctambychangelog
该 AssemblyLine 监视来自 LDAP 更改日志的 Identity Manager 用户属性变动。要使用这一 AssemblyLine，必须启用 LDAP 更改日志。如果 Identity Manager 用户属性更改的话，该 AssemblyLine 更新与之匹配的 Access Manager 用户数据。该 AssemblyLine 可在任何时侯手工启动，或者在预定的时间通过 ScheduleSync 事件处理程序启动。
从 TIMtoTAMSyncExit 文件中定义的最后一次更改号开始，
第一个连接器读取更改日志。最后一次更改号在每次 AssemblyLine 运行时被更新。
该连接器的第一项任务是过滤掉非 Identity Manager 用户更改。每一 LDAP 更改日志包含一个 targetdn，这是已更改条目的 dn。如果这一 dn 以“ERGLOBALID”或者“ergloblid”打头，它就是 Identity Manager 用户更改。如果不是的话，更改日志将被跳过。
第二连接器工作在 Lookup 模式下，它搜索 Identity Manager 目录后缀下的 Access Manager 帐户。每一 Access Manager 帐户都有一个所有者，它是一个 Identity Manager 用户。该 AssemblyLine 的任务是发现这些在前一连接器中已经找到的 Access Manager 帐户所有者。该连接器通过比较每一 Access Manager 帐户来找到等于前一连接器中发现的“targetdn”属性，从而完成这一任务。如果匹配的话，Access Manager 帐户及其所有者如果是 Identity Manager 用户并且其用户属性经过更改，将都会被定位。同时，将重新获得 Access Manager 帐户的属性 ertamdn，该属性是相关的 Access Manager 用户 dn。现在我们就有了 Identity Manager 用户的 dn 和 Access Manager 用户的 dn。该连接器一个关键连接器。
第三个连接器现在查找 Identity Manager 的 dn，它等于“erparent”工作属性，然后检索用户属性，并添加到工作属性。该经过检索的属性是那些业务和个人属性，用于定义诸如通讯地址、电话号码等。
完成这些之后，
最后一个连接器工作在 Update 模式下。它查找匹配第二个连接器中发现的 “ertamdn” 的 Access Manager dn。该连接器定义 Identity Manager 个人和业务属性与 Access Manager 个人和业务属性之间的映射。它修改所有在 Access Manager 注册表中已定义的属性。
定时器事件处理程序（EH）：ScheduleSync
该事件处理程序用于控制 synctambychangelog AssemblyLine 的启动时间。构建这一定时器的原因在于，为管理员提供工具，以便定期启动 AssemblyLine 而不是连续运行。该事件处理程序只不过是一个定时器，这样管理员可以定义任何形式的 AssemblyLine 启动时间，比如每小时、每天、每周，等等。同样，更改日志连接器的选项也定义了睡眠时间和等待时间。选择不同的组合为管理员提供了随业务需要而不同的灵活性。启动时间、睡眠时间、等待时间可以在属性文件中定义。
退出文件：TIMtoTAMsyncexit
退出文件包含了更改日志起始号。更改日志起始号告诉 AssemblyLine 从更改日志的哪里开始查找 Identity 用户修改。提供起始号阻止了 AssemblyLine 连续同步老的用户属性更改，因为老的用户属性已经在以前同步完成了。
默认起始号可以在文件中进行设置。第一次执行以后，AssemblyLine 每次动态更新更改日志处理的起始号。
运行工具
安装在哪？
这些解决方案可以安装在公司内部网的任何服务器或工作站上。唯一的先决条件是需要安装 Directory Integrator 5.1.2。Directory Integrator 可以远程与不同的数据资源进行交互。如果 Lotus Notes 连接器用于访问 Domino 服务器中的用户数据，Directory Integrator 及其工具文件应该与 Notes 客户机安装在一起。
在运行工具之前需要做哪些工作？
- 定义属性文件的环境设置。
- 在 Identity Manager 4.5 服务器中创建一个 IDI Data Feed 服务。用户 ID、口令和 NamingCon 文本 必须在 Identity Manager 服务器中定义，并放入 Directory Integrator
JNDI 连接器的属性文件中，以供使用。
- 运行在生产服务器上之前，首先在模拟环境中运行一次“Proof of Concept”测试，以检查属性文件设置、输出结果等。测试应该使用 Directory Integrator
Administration Tool 运行。在管理工具中，您可以尝试连接到数据资源，检查连接是否可以建立。在执行期间，检查任何错误。如果发生错误，打开错误转储。 然后您可以查看管理工具中的详细错误日志。
如何执行 Directory Integrator 工具？
如何检查执行结果？
-
消息
查看 Directory Integrator Admin Tool UI 中的执行消息，并打开错误转储。
默认情况下（出于提高性能的目的），挂靠在工具中的错误定义为：
"system.skipEntry();"
为了进行错误分析，应该改为
"system.dumpEntry(error);"
-
输出文件—— 在每一 AssemblyLine 中启用 FileOutput 连接器，以检查输出文件的最终属性值。
-
直接检查用户数据通过 LDAP、Active Directory 和 Domino Server，检查用户数据以便查看导入或同步结果。
-
从 Identity Manager 服务器检查结果—— 检查用户输入过程是否成功。
参考资料
快速了解并启动 Directory Integrator：
IBM Directory Integrator 5.1.2: Getting Started manual
获取安装和配置 Directory Integrator 的详细信息：
IBM Directory Integrator 5.1.2: Reference manual
获取有关在 IBM Tivoli Identity Manager 中配置 IDI Data Feed 的详细信息：
IBM Tivoli Identity Manager 4.5: Policy and Organization Administration Guide
作者简介  | | | Sam Yang 博士是 Tivoli Security Business Unit（IBM Software Group 的一部分）的 Common Component Team 的成员。他关注的领域是为客户提供 Tivoli 安全产品的集成解决方案。Sam 从新泽西州技术学院获得了工程科学博士学位，已经在 IBM 工作了十年。 |
| | | Edward Whitehead 是 Tivoli Security Business Unit（IBM Software Group 的一部分）的 Common Component Team 的技术主管。 |
对本文的评价
| 
