Understanding the FIM Service Management Agent (FIM MA)

[AMARSIGLIA]

First published on MSDN on Dec 30, 2014

The FIM MA is just another Management Agent

The FIM Service Management Agent (FIM MA) is a call-based MA used to communicate with the FIM Web service.  This management agent extends the functionality of Forefront Identity Manager to leverage codeless provisioning, management policy application, reporting, and self-service by connecting aggregated identity data in the Metaverse with a separate data source, the FIMService database.  Think of the FIM MA as just another Management Agent, and the FIMService database as just another data source.  From a synchronization perspective that's ALL it is, albeit with some configuration set by design.

Some FIM MA properties are set by design

Identity data managed by the FIM MA has a direct relationship to the Metaverse. This information is important, and helps iron out some of the weirdness in the FIM MA.  Technically, this is not the whole story as there are separate schemas for the Metaverse and FIM Service, and there is no requirement to configure additional attribute flows at all (perhaps there should be).  In any event it is true for understanding synchronization with the FIM MA and there are 4 effects imposed by this design choice:

1. All Flows between the FIM MA and Metaverse are direct
   All attribute flows between the FIM Service and Metaverse are direct and must be configured in the Management Agent properties.  This means neither Synchronization Rules nor MA Rules Extensions are used for complex data flow between the FIM MA Connector Space and the Metaverse.

1. The FIM MA always projects new objects to the Metaverse*
   For any resource type that has an Object Type Mapping with a metaverse resource type, the projection rule is declared (true).

1. Objects always provision to the FIM MA*
   For any resource type that has an Object Type Mapping with a metaverse resource type, any object projected to the metaverse will provision to the FIM MA connector space.  Synchronization Rule Provisioning (tools->options) has no affect on this behavior, nor does the "create in FIM" checkbox for inbound sync rules.  The latter checkbox is a projection rule for the management agent and object type specified in the sync rule.   The wording is deliberate and "FIM" simultaneously means the metaverse and FIM Service because of the Object Type Mapping.  Furthermore, it is important to note this type mapping is 1:1.  You cannot map multiple metaverse object types to a single object type in the FIM Service.

1. Join Rules are pre-configured
   While the User Interface for MA Properties does not have a section to configure join rules, it is important to know what the join rules are, and why certain attribute flows come configured out of the box.  The premise is that even if the FIM MA connector space is deleted, and attributes are recalled from the metaverse, the out of box join rules will still allow us to join the data back.  Of course, it can be a little challenging if the FIM MA CS deletion satisfies the Metaverse Object Deletion Rule, but that situation is a topic for another blog.  If you run into this and are trying to clean up, remember that the FIM MA projects if the join rule is not satisfied, so therefore we must turn off sync rule provisioning and synchronize the FIM MA to project before joining with syncs on other MAs.  I've elaborated too much.  The two join rules for an object type mapped with the FIM MA are depicted in the table and screenshots below:

FIM Connector Space	|  Metaverse
<dn>	|  csObjectID
MVObjectID	|  <objectGUID>

* Object Type Mappings must be set for 2. and 3. to be true.  Without an Object type Mapping there are no rules for projection or provisioning.

Best Practice: Configure the Connector Filter

Ok, this is not technically a requirement for understanding but is highly suggested as best practice to filter out the Built-in Synchronization Account (ILMSync) and the Install Account.  These GUIDs are well known and I would be interested to hear an argument as to why these identities should be synchronized in any scenario.

• 7fb2b853-24f0-4498-9534-4e10589723c4 (Install account)

• fb89aefa-5ea1-47f1-8890-abe7797d6497 (Built-In Synchronization Account)

Configure the filter on the <dn> as shown below:

Conclusion

And that's it!  The FIM MA is just another MA with pre-configured (and obscured) rules.  Please leave comments or questions below and I will answer them below and update the post.

Resources

Understanding Data Synchronization with External Systems
Understanding Management Agent Rules
FIM 2010 Technical Overview