IIFP之牛刀小试（配置上篇）

  在IIFP初识篇中（链接： http://mrfly.blog.51cto.com/151750/341411）我为大家介绍了IIFP的一些基础概念知识和它的安装过程。继而进入配置篇，我将会结合一个实例进一步说明如何使用IIFP在两个不同域之间同步用户对象的属性。

  前文中我提到了在Identity Manager中最主要的配置部分是在 Management Agents （ MAs ）这个页面完成的。毫不夸张的说，MA是MIIS/IIFP的命脉。MA是MIIS/IIFP用来控制data source（数据源）中的数据流是如何导入进Metaverse（SQL数据库）或者从Metaverse中导出至data source的，它是由一些内容属性，Rules（规则）和Rules Extension（规则扩展）等组成的这么一个组件。Rules规则是被定义在MA上的，它可以根据在数据源中被发现的对象来决定是否需要在Metaverse中新建对象。规则还被用来决定新增或者已存在的connector objects（connector objects是存储在connector space中的对象，metadirectory元目录使用connector objects来同步已经连接的数据源和Metaverse之间的属性值）该如何连接到Metaverse中的对象上。

  这样看这些概念可能比较生涩难懂，还是拿本系列文章中的情景举例说明吧。

  (首先需要说明的是，在MIIS/IIFP的帮助文档和其他相关资料中所提供的假设情景都过于复杂和全面，这使得刚接触MIIS/IIFP的朋友们理解起来更为吃力，所以我下面描述的场景将尽可能的简单化一些。)

  当前环境有两个独立的域（/林）：contoso.com（source domain）和northwind.com（target domain），在Contoso域和northwind域中有两个最终意图同步帐号信息的OU，这两个OU中各有一些用户帐号。这两个数据源经过创建以及设定MA（每一个数据源需要建立一个MA）后和MIIS/IIFP连接了起来，那么这两个域即被称为connected data source。

  对应Contoso域的MA会从活动目录数据库中读取指定要同步的对象并且选择要同步的对象属性（这些设置都包含在对MA的配置中，文章后面将会演示），然后会将这些对象和属性信息都导入（也被称为staging）到connector space中。

  再然后，需要定义Rules（规则）来决定如何将connector space和metaverse之间的数据进行同步。在大多数情况下，当每一个MA运行的时候，通过Rules都会为用户帐号的身份实例向Metaverse中导入一个connector object（即建立connector object和metaverse object之间的关联）。这一步分为两种情况，一是由Rules决定是否需要在Metaverse中新建metaverse object以便connector object可以连接到它，这个过程在MIIS/IIFP的概念体系中被称为“project”。另外一种，Rules被定义为在Metaverse中寻找已存在的metaverse object并且将这些与connector object联结起来，这个过程则被成为“join”。例如，在Contoso域中，用户lion的雇员ID号码（例如f6825091）被保存在employeeID属性中。当Contoso域对应的MA运行起来后，首先将会在Metaverse中查询是否有包含相匹配的employeeID（值为f6825091）的已存在对象。如果这样的对象被找到，那么在Contoso域对于用户lion的connector object将会被联结到Metaverse中的这个已存在对象上（即执行join rules）。否则，如果join失败（未能在Metaverse中寻找到对应的对象）或者并未被配置，MA会继而应用projection rules新建这个对象。（很明显，当IIFP服务才运行起来，metaverse为空的时候，第一次总会发生project的动作。）

  你还可以创建Rules extension（规则扩展）来自定义更多更复杂的连接方式。Rules extension需要使用诸如VB或者C#等汇编语言来开发，做为.net framework类库或者动态链接库（DLL）的形式被生效。

  同时，MA也控制（对象的）哪些属性将被流动（flow）和属性值流动的方向。有些属性可以被定义为只导入进metaverse中。

  为了控制哪些对象会被MA处理，MIIS/IIFP中一样设计有Filter（筛选器）。filters可以建立在connected data source中的任何对象属性之上。例如，可以将某个filter设置为MA只处理其telephonenumber属性值是以数字“021”开始的对象。

  这里补充一副很经典的MIIS/IIFP中的同步规则示意图：

（要想完全理解这些内容，请详细阅读 http://technet.microsoft.com/en-us/library/cc720559(WS.10).aspx ）

  从图上可以大概看出，其实前面所描述的，都可以看做是各种各样的规则，也正是这些规则起主要作用决定了哪些数据要怎样从一个数据源同步到另外一个或者几个数据源中的。除了上面提到的这几种规则，还有其他很多类型规则，这里暂且不多做讨论了，后面如果涉及到的话再详细讲解。

  回到讨论的场景中，在选定的对象数据信息经过了若干步处理被Contoso域对应的MA同步到metaverse中以后，为northwind.com创建的MA又在经过若干过程后（其中重要的一步是通过规则再定位metaverse中哪些对象和属性信息需要被同步到northwind域）将其导出到northwind.com域活动目录数据库中。最终实现了选定的用户在这两个域中身份信息的统一化。

[

NOTES：

这里可能很多朋友想问，到底什么是connector space，它的作用又有哪些，为什么从connected data source中导出的数据不直接导入metaverse或者从metaverse中导出呢？
我这里简要地回答一下，

其实Connector space 相当于一个暂存空间，它对于MIIS/IIFP的意义主要有：

1.通过这么一个暂存空间，MIIS/IIFP可以摆脱对connected data source的依赖性，当某个数据源不可用或者不可访问时MIIS/IIFP仍可以随时使用Connector space中的数据进行处理。

2.MIIS/IIFP通过connector space来确定connected data source中哪些数据发生了变化并且只是传输这些发生了变化的数据，从而大大减少了connected data source和MIIS/IIFP之间的网络传输开销，提高了工作效率。
]

  总的来说，MIIS/IIFP在本系列文章所举示例中的整个工作流程如下图所展示，

……

  在大概了解了上面这些MA的相关知识后，让我们尝试一下在IIFP中为Contoso域建立一个MA。

1. 在安装了IIFP的服务器上找到如下位置，打开“Identity Manager”；

2. 点击“Management Agents”按钮，来到MA的配置界面；

3. 点击界面右侧位于Actions下的Create；

4. 弹出的新窗口中会让我们选择为什么样的data source建立MA。
可以看到，使用IIFP只能为AD，ADAM及exchange GAL三种数据源服务，这也正是它被称之为“MIIS精简版”的原因。

这里选择“Active Directory”并为此MA填写一个名称（我这里起名为Domain C）

5. 然后会要求填写做为source domain（相对于要把用户信息同步到northwind域）的Contoso域的一些信息，包括了域林名、连接此域的域帐号以及域名。

填写完成后点击next；

6. 在配置目录分区的界面中，我们需要做的是，
a）勾选确认过的目录分区；

b）在“Options”按钮中取消对“Sign and Encrypt LDAP Traffic”的勾选，因为如果勾选此项会需要额外进行配置从而提高IIFP服务器和域控之间使用LDAP协议通讯的安全性；

由于时间关系和实验环境，所以我这里将其取消掉。
c）点击“Container”按钮，可以将根节点反选掉，然后只选择想要同步信息到目标域上的的容器（OU）；

其他地方保持默认即可（本篇暂不讨论密码同步等，后续文章将深入探讨），下一步。

7. 选择要同步的对象类型，我们目的是将Contoso域中的finance这个OU中的用户帐号及属性同步到northwind域，所以自然是需要勾选user这个类型。

同时你可能会发现，其他三个已经选择好的对象类型是无法被反选掉的，如果你想要取消它们会被提示它们已经被指定为了强制发现对象。
选择完毕后next；

8. 在属性选择的界面中，你可以指定关于对象的哪些属性可以被同步到目标域中。管理活动目录的朋友相信对这些属性也是比较熟悉的了。这里我勾选了一些对于用户帐号必然需要包含或者比较关键的属性。（需要特别提醒的是，对于构成一个指定对象类型的基本属性，必须选择上，例如活动目录中的用户帐号的 sAMAccountName 属性）
c

cn

co

department

description

displayName

givenName

homePhone

info

initials

l

mail

mobile

postalCode

sAMAccountName

sn

st

streetAddress

telephoneNumber

title

对这些属性都代表什么还存在疑问的朋友可以在msdn上找到详细的答案。或者对照 http://www.kouti.com/tables/userattributes.htm查看。

需要特别说明的是，这些属性都是可以被前面提到的规则（Rules）和筛选器（Filters）所调用的。

9. 在完成了上一步的属性选择后，即可配置connector filter。正如前面提到的那样，你可以设置一些筛选条件，比如telephonenumber是以数字021开头的等等。

实验中我并没有定义任何筛选器，上图只是演示效果，保持默认空白，点击next

10. 接下来进入了配置join and projection Rules的环节。
建立Join Rules的目的是我们希望能够通过查找特定、具体的条件在metaverse中定位对象，当匹配的对象被找到后，将会拿它与connector space中的connector object连接起来继而进行后面的流程。而配置projection Rules的作用则是在未找到匹配对象后在metaverse中将对象建立出来。
问题来了。
规则是依靠什么去定位这些对象的呢？
其实对于connector space中的每个对象一般都拥有两个属性：GUID（globally unique identifier）全局唯一标识符和DN（distinguished name）可分辨名。除此之外，如果connected data source为对象分配过一个独一无二的属性，那么这个属性也会继续被带进connector space中，被称为anchor attribute ---锚定属性。锚定属性唯一标识一个在connected data source中的对象。所以锚定属性都会选择在一个对象的生命周期内（即帐号对象被创建出来然后使用直至弃用删除的过程）都不会被改变的属性值，例如一个用户帐号属性中的objectGUID，employee number等。MIIS/IIFP就是通过这些锚定属性来在connected data source中定位对象的。
打个很形象的比方，如果说metaverse是元数据库（SQL Server）中的一张表（table），那么每个对象（object）信息就是表中的一条记录（record），对象的多种属性（attribute）就是字段（field），而锚定属性（anchor attribute）就等同于主键（keyfield）了。

回到IIFP操作界面，让我们来看看如何利用锚定属性将数据源和metaverse中的对象建立对应关系。
首先为user来新建Join Rules，

在点击New Join Rule后即弹出下面的窗口，

可以看到，我们需要将data source attribute和metaverse attribute映射（mapping）起来。为什么要这么做呢？就是上面所说的，在connected dada source中的每一个对象都可以选择一个锚定属性来标记自己的唯一性，而这个属性映射进metaverse中以后也会在metaverse中标记自己的唯一性。如此一来，MA在运行后便能通过这个独一无二的属性值精准查找到metaverse中的对象并将其与connector object连接起来。
这里为了更加直观一些，我先选择了sAMAccountName属性做为data source中对象的锚定属性。再次强调，锚定属性要求具有唯一性和不变性。

（当然你也可以选择employeeID等做为锚定属性，只不过employeeID等默认并没有直接显示在“Active Directory用户和计算机”中的用户属性里，你可能需要使用adsiedit.msc来查看这个属性…）
然后选择要映射到metaverse哪种对象的哪个属性上。
在Metaverse object type下拉框中可以看到在metaverse中已经定义好的一些对象类型，这里选择person。

可能有的人会问，为什么没有user而是选择person？
这个其实只是不同类型目录对“用户”这种对象不同的称呼而已，微软Active Directory中将用户称为user，metadirectory中将用户默认称为person。

对object type选择完毕后则要选择对应属性。

经过上下滚动侧边条，并没有能在metaverse attribute选择框中发现sAMAccountName属性。
这并不奇怪，虽然默认的metaverse中涵盖了多种目录中的基本对象类型及属性，但也没有百分之百的包括，像sAMAccountName这样的属于微软的活动目录对象的专有属性就没有被默认添加到选择列表中。但这并没有什么真正影响，如果你非得想要data source中的对象的sAMAccountName属性映射到metaverse对象上的也叫sAMAccountName这个名称的属性上，完全可以在 Metaverse Designer界面中将其新建出来并定义它的赋值类型等等（还记得Metaverse Designer界面下我们都能做哪些工作吗？如果不记得请重新阅读初识篇后半部分。）。当然，如果你对上面的“person”也耿耿于怀，也可以通过 Metaverse Designer将你“钟意”的“user”对象类型建立出来并定义它都包含哪些属性。
（顺序是先建立object type再增加attribute，这里我就不做演示了。）
经过两边窗口的比较，并遵循唯一性和不混淆的原则，我选择将sAMAccountName属性映射到metaverse attribute列表中的uid属性。

两边要映射的锚定属性选择完成后还需要设定如何映射，是直接（Direct）映射还是通过规则扩展（Rules extension）映射，

这里我们选择直接映射，即直接将data source用户对象的sAMAccountName属性值和metaverse用户对象的uid属性值一对一的等于起来。定义及使用Rules extension则一般是在多于一个metaverse对象被接受的情况，此内容已经超出了本文的讨论范围，不再多提。
完成上面三块设置后，点击Add Condition ，确认添加条件，
此时会弹出如下信息窗口：

大意为映射到了一个没有进行索引的属性，而没有索引可能会造成一些性能上的问题。
不用担心，后面我们可以为这个属性（uid）建立索引。

点击确定后，我们应该看到的完整画面是这样的，

至此，Join rule就设定好了。
紧接着便是设定Projection rule，

点击New Projection Rule后，会弹出一个体积较小的对话框，

可以看到Projection rule的设定貌似并不复杂，这可以理解，因为Projection rule的任务就是把上步Join rule没有找到的对象建立出来而已。

Declare，宣告的过程就是建立的过程。建立什么类型的对象也已经根据上步内容选择好了，就是person。点击OK。

结束了配置Join Rule和Projection Rule后，我们应该看到的正确示图如下，

通过对Join Rule和Projection Rule的设定，实现了这么一个情景：
如果在connector space中导入了一个sAMAccountName属性是lion的对象，那么MA会直接在metaverse中寻找uid是lion的对象。找到了，就将这两个对象关联起来；若没找到，则执行后面的Projection Rule，将用户对象建立出来。
但是，Projection rule也仅仅是决定了要在metaverse中新建一个什么类型的对象而已，而至于这个对象到底又需要具有哪些属性，这却并不是由它来配置和掌控的了。

11. 进入配置MA的第八步，configure attribute flow，配置属性流。
其实这个步骤严格意义上应被称为建立Import Attribute Flow Rule，它的目的就是解决刚才上面提到的问题：决定哪些属性需要从Contoso域（connected data source）中映射进metaverse中。
在这一步的配置中，主要工作是在下图红色边框中的部分完成的，

很好理解，从data source attribute中选择要导入metaverse中的属性，然后与右侧metaverse attribute中对应的属性形成映射关系即可。当然，对于Contoso域来说是将属性流导入进metaverse，所以Flow Direction要选择Import。
所以整个过程更像是纯体力劳动，左侧下拉列表中选择c属性，然后右侧下拉列表中同样也选择c属性，确保流的方向是Import，然后点击New。以此类推，将两边属性都联结起来。
需要特别注意的是，我的实验过程中sAMAccountName属性对应的是uid属性。

全部完成后看到的画面应该类似于下图，

确认无误后点击Next。

12. 在Configure Deprovisioning中配置的是当connector space object和metaverse object断开连接后如何发生行为。我们知道，当connector space object和metaverse object连接起来的时候即被称为connector object，而断开连接或未发生连接时，则成为disconnector object。Disconnector object存在的好处显而易见，因为MIIS/IIFP系统已经暂存了这种对象的相关必要信息，所以在下次从数据源导入信息的时候就没有必要再重新建立这个对象，disconnector object可以很方便的通过规则转换为connector object。
通过定义Deprovisioning Rule，你可以决定disconnector object是被删除还是被保留，而且又是以怎样的方式被删除或者保留的。
因为这部分内容已经超出本篇讨论的范畴，所以暂不多说。
所有选项保持默认，Next。

13. 最后一步Configure Extensions，用于对前面Rules extension和Password management等设置的确认，由于本篇还未涉及此部分知识（后续系列文章将深入讨论Rules extension），所以也保持默认设置，不做改动。
点击Finish,完成。 
  到这里，我已经为Contoso域建立好了一个关于将数据导入metaverse的MA，基本上算是完成了本系列文章所举示例的流程示意图的左半部分，

  需要郑重说明的是，MA不是配置好了就能立刻运行的，它还需要配置相关的运行环境（Run Profiles）后才能work起来。

  考虑到本篇已经相当冗长并且包涵了很多知识点，出于对读者们的负责，特将IIFP配置篇也一分为二。我将会在配置下篇中继续说明metaverse中的数据又要如何导出到northwind域（主要是为northwind域创建及配置MA），MA的Run Profiles又该如何配置，等等等等，直至展示那激动人心的一刻---用户对象的属性值完全被同步。所以下篇文章您不能错过，敬请期待吧！