FIM2010-Equal Precedence and Its Use

The addition of Equal Precedence into the FIM2010 feature set was both a blessing and a curse. A blessing in that we have a tool that now auto-magically merges to multi-valued objects into a superset of unique items when coming from two different sources but a curse in that single valued attributes may or may not operate as anticipated in some situations.

Look at the following scenario. Two MA’s connected to different data sources are flowing data into the single-valued “title” attribute in the Metaverse, lets use “Active Directory” and “PeopleSoft” as examples. Equal Precedence is selected for the attribute in the Metaverse Designer.

During the normal execution of a synchronization run script, the system runs in the following sequence:

  1. PeopleSoft – Sets the title to “Consultant”
  2. Active Directory – Sets the title to “Really Good Consultant”
  3. PeopleSoft – Sets the title back to “Consultant”

(Granted, this would never occur in real life but… it helps clarify the situation a bit. Smile)

Now what if, for some reason to do some troubleshooting, an administrator runs the full synchronization of Active Directory out of band from the normal run scripts. The users title is now set to “Really Good Consultant”. Is this a desired behaviour?

Look it it now from the perspective of “important” data like whether or not an account is active or inactive. If someone runs MA’s out of sequence in a scenario where one MA, that should otherwise have precedence, is now overridden by “Active” data from a second MA with equal precedence, the issue is a lot more severe. Accounts may be reactivated and improper access granted.

Long story short, equal precedence is a good option when working with multi-valued attributes because of the merging capabilities and “looks” good when dealing with single valued attributes because the last value wins (how easy is that!?!).

However,  my personal best practice is that single valued attributes should have appropriate precedence and attribute recall setup to that the data source is always “known” regardless of the sequence the management agents are operated as processes, no matter how well defined may be ignored or, should I say overlooked, during troubleshooting or other similar FIM management activities.

This entry was posted in Best Practices, Forefront Identity Manager 2010. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s