FIM Synchronization Service (FIM Sync)_Microsoft Forefront Identity Manager 2010 R2 Handbook-QQ阅读男生历史网

书名：Microsoft Forefront Identity Manager 2010 R2 Handbook
作者名：Kent Nordstr?m
本章字数：1651字
更新时间：2021-08-13 18:09:03

FIM Synchronization Service (FIM Sync)

FIM Synchronization Service is the oldest member of the FIM family. Anyone who has worked with MIIS back in 2003 will feel quite at home with it. Visually, the management tools look the same.

FIM Synchronization Service can actually work by itself, without any other component of FIM 2010 R2 being present. You will then basically get the same functionality as MIIS had, back in 2003.

FIM Synchronization Service is the heart of FIM, which pumps the data around, causing information about identities to flow from one system to another.

Let's look at the pieces that make up the FIM Synchronization Service:

As you can see, there are lots of acronyms and concepts that need a little explaining.

On the right-hand side of FIM Synchronization Service, we have Metaverse (MV). Metaverse is used to collect all the information about all the identities managed by FIM.

On the other side, we have Connected Data Source (CDS). Connected Data Source is the database, directory, and file, among others, that the synchronization service imports information regarding the managed identities from, and/or exports this information to.

To talk to different kinds of Connected Data Sources, FIM Synchronization Service uses adapters that are called Management Agents (MA). In FIM 2010 R2, we will start to use the term Connectors, instead. But, as the user interface in FIM Synchronization Manager still uses the term Management Agent, I will use that term throughout this book.

The Management Agent stores a representation of the objects in the CDS, in its Connector Space (CS). When stored in the Connector Space, we refer to the objects as holograms. If we were to look into this a little deeper, we would find that the holograms (objects) are actually stored in multiple instances so that the Management Agent can keep a track of the changes to the objects in the Connector Space.

In order to synchronize information from/to different Connected Data Sources, we connect the objects in the Connector Space with the corresponding object in the Metaverse. By collecting information from all Connected Data Sources, the synchronization engine aggregates the information about the object from all the Connected Data Sources into the Metaverse object. This way, the Metaverse will only contain one representation of the object (for example, a user).

To describe the data flow within the synchronization service, let's look at the previous diagram and follow a typical scenario.

The scenario is this—we want information in our Human Resource (HR) system to govern how users appear in Active Directory (AD) and in our e-mail system.

Import users from HR: The bottom CDS could be our HR system. We configure a Management Agent to import users from HR to the corresponding CS.
Projection to Metaverse: As there is no corresponding user in the MV that we can connect to, we tell the MA to create a new object in the MV. The process of creating new objects in the MV is called Projection. To transfer information from the HR CS to the MV, we configure Inbound Synchronization Rules.
Import and join users from AD: The middle CDS could be Active Directory (AD). We configure a Management Agent to import users from AD. Because there are objects in the MV, we can now tell the Management Agent to try to match the user objects from AD to the objects in the MV. Connecting existing objects in a Connector Space, to an existing object in the Metaverse, is called Joining. In order for the synchronization service to know which objects to connect, some kind of unique information must be present, to get a one-to-one mapping between the object in the CS and the object in the Metaverse.
Synchronize information from HR to AD: Once the Metaverse object has a connector to both the HR CS and the AD CS, we can move information from the HR CS to the AD CS. We can, for example, use the employee status information in the HR system to modify the userAccountControl attribute of the AD account. In order to modify the AD CS object, we configure an Outbound Synchronization rule that will tell the synchronization service how to update the CS object based on the information in the MV object. Synchronizing, however, does not modify the user object in AD; it only modifies the hologram representation of the user in the AD Connector Space.
Export information to AD: In order to actually change any information in a Connected Data Source, we need to tell the MA to export the changes. During export, the MA updates the objects in the CDS with the changes it has made to the hologram in the Connector Space.
Provision users to the e-mail system: The top CDS could be our e-mail system. As users are not present in this system, we would like the synchronization service to create new objects in the CS for the e-mail system. The process of creating new objects in a Connector Space is called Provisioning.

Projection, Joining, and Provisioning all create a connector between the Metaverse object and the Connector Space object, making it possible to synchronize identity information between different Connected Data Sources.

A key concept to understand here, is that you do not configure synchronization between Connected Data Sources or between Connector Spaces. You synchronize between each Connector Space and Metaverse. Looking at the previous example, you can see that when information flows from HR to AD, you configure the following:

HR MA to Import data to the HR CS
Inbound synchronization from the HR CS to the MV
Outbound synchronization from the MV to the AD CS
AD MA to Export the data to AD

Management Agents

Management Agents , or Connectors as some people call them, are the entities that enable FIM to talk to different kinds of data sources. Basically, you can say that FIM can talk to any type of data source, but it only has built-in Management Agents for some. If the data source is really old, you might even have to use the extensibility platform and write your own Management Agent or buy a Management Agent from a third-party supplier. At http://aka.ms/FIMPartnerMA, you can find a list of Management Agents supplied by Microsoft Partners.

For a complete list of Management Agents built in and available from Microsoft, please look at http://aka.ms/FIMMA.

With R2, a new Management Agent for Extensible Connectivity 2.0 (ECMA 2.0) is released, introducing new ways of making custom Management Agents. I suppose that we will see updated versions of most third party Management Agents as soon as they are migrated to the new ECMA 2.0 platform. Microsoft will also ship new Management Agents using the new ECMA 2.0 platform.

Writing your own MA is one way of solving problems communicating with odd data sources. But, as I will discuss further in Chapter 11, Customizing Data Transformation, there might be other solutions to the problem that will require less coding.

Non-declarative vs. declarative synchronization

If you are using FIM Synchronization Service the old way, like we did in MIIS or ILM 2007, it is called non-declarative synchronization. I usually call that classic synchronization and will also use that term in this book. If we use the FIM Service logic to control it all, it is called declarative synchronization.

As classic synchronization usually involves writing code, and declarative does not; you will also find references calling declarative synchronization codeless.

In fact, it was quite possible, in some scenarios, to have codeless synchronization—even in the old MIIS or ILM 2007—using classic synchronization. The fact also remains that there are very few FIM 2010 R2 implementations that are indeed code free. In some cases you might even mix the two. This could be due either to migration from MIIS/ILM 2007 to FIM 2010 R2 or to the decision that it is cheaper/quicker/easier to solve a particular problem using classic synchronization.

The solutions I will describe in this book will be based on declarative synchronization, rather than the old-fashioned, classic ones. In Chapter 11, Customizing Data Transformations, I will show some examples in which classic synchronization is the best way to solve some problems.

Password synchronization

Let me first state that I am not a fan of using password synchronization. I believe that this should be the last resort to achieve some kind of Single Sign On (SSO). Instead of implementing password synchronization, I try to make my customers look at other ways, such as Kerberos or Federation, to get SSO.

There are, however, many cases where password synchronization is the best option to maintain passwords in different systems. Not all environments can utilize Kerberos or Federation and therefore need the FIM password synchronization feature to maintain passwords in different Connected Data Sources.

The use of this feature is to have Active Directory by either installing and configuring Password Change Notification Service (PCNS) on Domain Controllers or using FIM Service as a source for the password change. FIM Synchronization Service then updates the password on the connected object in Connected Data Sources, which are configured as password synchronization targets. In order for FIM to set the password in a target system, the Management Agent used to connect to that specific CDS needs to support this. Most Management Agents available today support password management or can be configured to do so.

FIM Service Management Agent

A very special Management Agent is the one connecting FIM Synchronization Service to FIM Service. Many of the rules we apply to other types of Management Agents do not apply to this one. If you have experience working with classic synchronization in MIIS or ILM 2007, you will find that this Management Agent does not work as the others.

This Management Agent will be fully explained in Chapter 4, Basic Configuration. For now, let's just leave it at the fact that this is a special Management Agent.