Share via

FIM 2010 / MIM 2016: About Attribute Flow Precedence

  • Article

Credits

THis article is a backup from a TechNet Forum post originally authored by Paul Loonen.

Due to issues with dead image links, this article has been recover

About the author

Paul is an Architect for Avanade working on all things directory (whether Active or not), identity management and security on the Microsoft platform.

Paul is also a founding member of the winsec.be Microsoft community group that focuses on evangelizing Microsoft IAM solutions, and on security solutions for the Windows platform.

Prior to joining Avanade, Paul was a consultant with HP/Compaq and was showing his directory roots at Banyan.

Introduction

Very often we think of precedence in terms of authoritative sources: the repository where the lifecycle of an object begins and from where the major changes are triggered.

However, this is not the only source of authority: also for individual attributes authority can be defined, or, as it is called in ILM speak, “attribute precedence”.

On the way from the connector space of a connected system to the metaverse, there are two gates that must be passed.

The first gate is implemented in the form of an import attribute flow rule.

However, when an attribute has passed this gate, it also needs to pass the next gate – the attribute flow precedence, as illustrated in the following picture:

The fact that there are actually two gates that govern on the import flow side and on the export flow side how and whether attributes flow to and out of the metaverse, is a fact people tend to forget when working with ILM.

This is why I’m writing this article.

Precedence defined

When multiple management agents (MAs) define an import attribute flow (IAF) for the same metaverse (MV) attribute of a single object, ILM needs a way to decide which of these IAFs wins.

By default, the flow that is defined first is the one that wins.

Obviously, this default flow may not be the one that you would want to win.

Therefore, for this kind of flow, attribute precedence, or precedence needs to be defined.

Precedence is defined on a per attribute basis for each of the objects for which the attribute is available and is configured in the MV designer tool.

Precedence is applied both for import and export attribute flows.

The reason for precedence on IAF has been indicated above.

For export attributes flows (EAFs), precedence rules are needed in order to avoid that values of attributes coming from connected data sources with lower precedence flow to connected data sources with higher precedence, possibly leading to unwanted data loss.

Logically, ILM stores a value in the MV like this: Attribute Name, Attribute Value, Precedence of contributor

So, let’s imagine that for a given attribute X, we have 3 possible contributing MA’s, in order of precedence:

  1. HR MA
  2. AD MA
  3. File MA

Practically, File MA can contribute a value to the MV as long as the attribute has not been populated yet.

If ADMA has a value, it can contribute the value at which point values from File MA are blocked.

In the same way, as soon as HR MA contributes a value, the AD MA (and File MA) is blocked from contributing.

So, there is a little “game” (show me your precedence and I tell you whether you can contribute) going on and we don’t think that many folks are aware of how this works.

One last thing to remember is that precedence rules for attributes are defined on an object by object basis.

So, if given an attribute x that is available for object types y and z, then precedence for that attribute needs to be defined for both object types (of course when multiple flows are defined for that particular object-attribute pair).

Implementing precedence

As it turns out, precedence comes in two shapes: in many cases you can define a fixed order of precedence.

This fixed order can easily be implemented using the MV Designer tool in Identity Manager.

You can use the following procedure to configure attribute flow precedence:

  1. In ILM, open Identity Manager.
  2. Switch to the Metaverse Designer view.
  3. In the Object types list, select the object type for which attribute(s) you need to change the attribute precedence (e.g. person)
  4. For each attribute that has multiple IAFs, complete the following steps:
    1. Select the attribute from the Attributes list.
    2. To open the Configure Attribute Flow Precedence dialog box, click Configure Attribute Flow Precedence on the Actions menu.
    3. In the Management Agents list, use the up and down arrows to change the precedence order of the MAs in the list. Higher up the list means precedent over lower down the list.
    4. To close the Configure Attribute Flow Precedence dialog box, click OK.

When the previous method is not sufficient and you need more flexibility, e.g. because your rule needs to depend on the value of an attribute, you can implement what is called manual precedence.

When you define manual precedence for an attribute, the default precedence evaluation is switched off.

Since the default precedence evaluation rules are switched off, the implementer will need to supply his own (in code).

Therefore, ILM will only allow you to switch on manual precedence when all IAFs for a given attribute are defined as advanced flows.

In Figure 1 above, the check box “Use manual precedence” is disabled (and unchecked) as two of the four mapping types are of type Direct.

As soon as these two mappings are implemented in code, precedence could be switched to manual (if required by the scenario implemented of course).

For completeness, ILM’s successor, Forefront Identity Manager 2010 (FIM), defines a third kind of precedence called equal precedence.

You configure equal precedence when you want to remove attribute precedence for a certain MV attribute.

As a net effect, when the MV attribute is multi-valued, all values contributed by the different MAs are accumulated in the MV attribute.

When the MV attribute is single-valued, the value that is last contributed is stored in the MV attribute, or, “the last writer wins”.

For some scenarios it is possible to also implement equal precedence in an ILM 2007 system – a notoriously impossible scenario however is an equal precedence scenario involving multi-valued reference attributes (such as e.g. members of groups – a scenario where FIM shines). For the scenarios where implementing equal precedence in ILM is possible, precedence will need to be done completely in code. However, your flow code would not have anything that is precedence related.

Common Problems

In this section, we will outline some common problems in conjunction with attribute flow precedence.

Missing or wrong data on export

A common attribute flow precedence issue is a result of adding a new management agent. When adding a new management agent, ILM administrators often only focus on the attribute flow rules.

What they often forget to verify is whether the newly added flow rules have the required attribute flow precedence to produce the desired results.

Good to know is that existing flows have higher precedence than the new flows defined.

This same error will of course also occur when you simply forget about defining precedence.

When defining IAFs, you always need to keep in mind that after the synchronization engine looks at your IAF and determines that work needs to be done (because of a pending import), it will also look at the defined precedence (whether forgotten or not).

When implementing a new MA, we recommend checking your attribute flow precedence configuration.

Verify in the MV designer for each object, whether a newly added flow has the required precedence.

The easiest way to do this is to simply sort the attributes on the number of import flows defined to get those attributes to the top of the list that have multiple IAFs, as shown in the following screenshot:

 

Export Precedence

More complex is a second common problem, related to the dreaded “Skipped: Not Precedent” message on Export Attribute Flows (EAFs).

The following screenshot shows an example for this.

As already stated in the introduction, it is a little known fact that precedence rules also have their impact on EAFs.

The synchronization engine applies an attribute flow precedence check also for EAFs.

This is necessary to avoid that attribute values coming from a data source with a lower precedence flow to a target with a higher precedence.

Without this check, unwanted data loss is possible.

As a consequence, these rules do not apply when defining manual precedence, or when there is no source attribute (e.g. when flowing a constant value into the MV).

In general, you will get into this situation when for a given MA you define both an IAF and an EAF for an attribute, so flowing a value from the CS into the MV and flowing it back into the same CS.

A simple case is illustrated in the following picture.

In this case, when B contributes to the MV, the value won’t flow to A as the precedence of A is higher.

This rule also applies when an advanced flow, possibly combining multiple attributes, contributes the value in the MV, as illustrated in the following picture (A and C are different attributes of the same object):

 

Ambiguous Import Flows

Another problem that you may encounter when implementing attribute flows is the “ambiguous-import-flow-from-multiple-connectors” error problem.

This error is a result of having multiple connectors coming from the same CS for the same object in the MV.

The error is illustrated in the following screenshot.

Clicking on the “AVA012345” hyperlink in the previous screenshot and clicking on the “preview” button in the dialog box that appears reveals the following after clicking on “Generate Preview”:

Clicking the “…” button in the previous screenshot will lead you to the MV object that your object would like to be joined to.

On the MV object you can then examine the list of connectors, where you will find that there already is a connector for your CS:

Which now leads to the question, how do we solve this problem and allow the CS object to join to the MV object in question.

In the example above, having multiple connectors from the same CS, was probably not intended.

The issue is a result of the configured join rule, which links objects with matching first name and last name attribute values.

With this configuration, all objects with the same first name and last name attribute values will join to a single metaverse object. However, you should only join objects that are a representation of the same physical identity to a metaverse object.

To identify an identity, a first name last name combination is inefficient.

You can address this issue by adding additional join criteria such as a birth date. However, this is also just a quick fix.

The ideal join criterion consists of a Correlation ID. You can find more details on this in the Design Concepts for Correlating Digital Identities.

There are cases, where you actually do have multiple representations of the same physical identity in a connector space.

For example, a common best practice for system administrators is to use the administrative account only to perform administrative tasks.

All system administrator should also have a regular user account to perform non administrative tasks in a network.

If the best practice is implemented, you have a scenario where a physical identity can have multiple accounts in an environment that need to be aggregated to one metaverse object.

In this scenario, you need to convert all offending import attribute flows as advanced flows in a related rules extension.

Additional Information

For more information, please see