Active Directory 驱动程序附带了一个称为 ActiveDirectory.xml 的默认配置文件。 使用 Designer 或 iManager 导入该配置文件时,会创建一个驱动程序,带有适用于与 Active Directory 同步的一组规则和策略。 如果您对驱动程序的要求不同于默认策略,则需要更改这些策略,以便达到所需策略的效果。 请特别注意默认的匹配策略。 您相信可用于匹配用户的数据通常不同于默认值。 策略本身带有注释,导入测试驱动程序后,在 Designer 或 iManager 上检查这些策略可以更好地了解它们的功能。
通常,Identity Vault 的管理实用程序(例如 iManager 和 ConsoleOne)对用户对象的命名方式,不同于 Microsoft* 管理控制台 (MMC) 的《用户》和《计算机》咬接模块对用户对象的命名方式。 请确保您了解这些差别,以便能够正确实现所拥有的匹配策略和任何转换策略。
数据可以在 Active Directory 和 Identity Vault 之间流动。 数据流受到为 Active Directory 驱动程序部署的策略的控制。
策略可以控制 Active Directory 和 Identity Vault 之间的数据同步。
在配置驱动程序过程中,可以使用 Active Directory 配置文件选择用于影响默认策略以及为您创建的过滤器的多个选项。 Table 1-1 列出了这些选项,同时说明了它们如何影响策略和所创建的过滤器:
Table 1-1 数据流选项
Table 1-2 列出了默认的策略,并说明了在配置过程中,选项如何影响这些策略:
下列 Identity Vault 用户特性、组特性和组织单元特性将映射到 Active Directory 用户特性和组特性。
表中列出的映射为默认映射。 可以重映射相同类型的特性。
Table 1-3 为所有类映射的特性
eDirectory 中的 L 特性将映射到 Active Directory 中的 physicalDeliveryOfficeName 特性,eDirectory 中的 Physical Delivery Office Name 特性将映射到 Active Directory 中的 L 特性。 由于名称相似的字段具有相同的值,因此以这种方式映射特性能使特性良好地配合 ConsoleOne 和 Microsoft 管理控制台。
默认的配置包括两个名称映射策略,将它们一起使用有助于调解 Identity Vault 和 Active Directory 之间不同的命名策略。 如果使用 Active Directory 的《用户》和《计算机》工具(Microsoft 管理控制台(本文档中简写为 MMC)的一个咬接模块)创建一个用户,则可以看到该用户的全名被用作其对象名。 用户对象的特性定义 Windows 2000 以前版本的登录名(又称《NT 登录名》或《sAMAccountName》)以及 Windows 2000 登录名(又称《userPrincipalName》)。 如果在 Identity Vault 中使用 iManager 或 ConsoleOne 创建用户,则对象名与用户登录名相同。
如果在 Active Directory 中使用 MMC 创建一些用户,以及在 Identity Vault 中或者在与 Identity Vault 同步的另一个已连接系统中创建其它对象,则对象可能在相对的控制台中不成对,因此可能根本无法在相对的系统中创建。
在使用 MMC 约定的 Active Directory 中,可以通过全名映射策略来管理对象。 如果启用了该策略,则 Identity Vault 中的 Full Name 特性将与 Active Directory 中的对象名同步。
在使用 Identity Vault 约定的 Active Directory 中,可以通过 NT 登录名映射策略来管理对象。 如果启用了该策略,则 Identity Vault 对象名可用于同步 Active Directory 中的对象名和 NT 登录名。 Active Directory 与 Identity Vault 中的对象名相同,NT 登录名与 Identity Vault 登录名匹配。
如果同时启用了这两个策略,则 Active Directory 对象名就是 Identity Vault Full Name,但是 NT 登录名与 Identity Vault 登录名匹配。
如果同时禁用了这两个策略,则不执行特殊的映射。 将会同步对象名,并且不提供用于创建 NT 登录名的特殊规则。 由于 NT 登录名是 Active Directory 中的必备特性,因此在添加操作过程中,需要某种方法来生成一个此特性。 NT 登录名 (sAMAccountName) 将映射到 Identity Vault 中的 DirMXL-ADAliassName,因此,既可以使用该特性来控制 Active Directory 中的 NT 登录名,也可以在订购者创建策略中构建自己的策略,以生成一个这样的特性。 如果选择此策略,使用 MMC 创建的用户会将 MMC 生成的对象名用作 Identity Vault 中的对象名。 登录 Vault 时,使用该名称可能会不方便。
Windows 2000 登录名(又称 userPrincipalName 或 UPN)在 Identity Vault 中没有直接的对等特性。 UPN 看上去像电子邮件地址 (user@mycompany.com),而事实上可能是用户的电子邮件名。 在处理 UPN 时,务必记住的一点是该特性必须使用已针对域进行配置的域名(@ 符号后面的部分),这样才能成功使用该特性。 可以找出允许哪些域名,方法是使用 MMC 创建用户,然后在添加 UPN 时查看域名下拉框。
默认的配置提供了用于管理 userPrincipalName 的多个选项。 如果设置了域,以便能够将用户的电子邮件地址用作 userPrincipalName,则可以使用用于跟踪用户的电子邮件地址的选项之一。 可以将 userPrincipalName 接在 Identity Vault 或 Active Directory 的电子邮件地址之后,具体取决于哪一端为电子邮件授权。 如果用户电子邮件地址不合适,则可以选择使用由用户登录名加上固定域名构建的 userPrincipalName。 如果可以使用多个名称,请在导入以进行选择之后更新策略。 如果这些选项都不合适,则可以禁用默认的策略,并写入自己的策略。
使用权利可以更方便地将 Identity Manager 与 eDirectory 中的 Identity Manager 用户应用程序和基于职能的服务集成。 如果使用用户应用程序,操作(例如在 Active Directory 中供应帐户)将会延迟,直到完成了适当的批准。 如果使用基于职能的服务,则会基于用户对象的特性(而不是按常规的组成员资格)完成权限指派。 这两个服务给 Identity Manager 带来了难题,因为从对象的特性来看,到底是已经予以批准还是用户与职能匹配,这一点并不明显。
权利是对 Identity Vault 中的对象记录此信息的标准化方法。 从驱动程序的角度看,权利可以对 Active Directory 中的某个项目授权或取消授权。 可以使用权利授予对 Active Directory 中某个帐户的权限、控制组成员资格,以及供应 Exchange 邮箱。 驱动程序并不知道用户应用程序或基于职能的权利。 它依赖用户应用程序服务器或权利驱动程序根据自己的规则对用户授予或取消权利。
仅当计划将用户应用程序或基于职能的权利与驱动程序一起使用时,才应该为驱动程序启用权利。