Intro
Precedence can be tricky in certain scenarios. Imagine you want to make FIM master for a given attribute, but you need an initial flow from another data source. A good example is the LDAP distinguished name. If you have a rule that builds the DN automatically based on a base DN and one or more attribute values, the object is provisioned with the correct DN on export. But when you want to visualize this DN in the FIM portal, you need to be able to flow it back. If FIM is master over the distinguished name attribute, this flow will be skipped "Not precedent".
So you have to consider the option of using equal precedence, since manual precedence is not possible in combination with the FIM MA. But equal precedence is dependent on the synchronization cycle order: "the last one to write the attribute wins". Therefore it is not an option if FIM needs to be the absolute master of the DN attribute and you want to make sure that it always has the value you expect it to have.
Single valued attribute
The solution I came up with to work around this issue involves using two separate metaverse attributes. The flow is illustrated by following table.
| Datasource | Metaverse | FIM Portal | ||
|---|---|---|---|---|
| ds_attr | → | mv_attr1 | → | fim_attr |
| ← | mv_attr2 | ← |
By using two metaverse attributes, both requirements are satisfied:
- FIM is master over the value flowed to the data source
- The actual value from the data source is flowed back to FIM
Multi valued attribute
We tried to apply this solution for multi valued attributes as well. A well known attribute that fits this use case is proxyAddresses. Initially, some exchange attributes are set in AD, such as mailNickName and homeMdb. Exchange generates some proxyAddresses based on defined rules. These aliases need to be available in FIM if FIM is used to manage this information.
To our surprise, the solution did not work in this case. After some investigation, the explanation was simple. The two metaverse attributes were not equal, which resulted in unexpected values after two or more synchronization cycles.
- Delta import delta sync FIM MA: fim_attr flows to mv_attr2
- Export AD MA: mv_attr2 flows to ds_attr
- Delta import delta sync AD MA: ds_attr flows to mv_attr1
The third step is expected, but does not update the entire value of mv_attr1 (key here is "entire"). The delta import delta sync step checks only changed attributes (and for multi valued attributes only changed entries). The value of ds_attr was just exported, so FIM compares its value with the originating metaverse attribute, which is mv_attr2. Since the values of mv_attr2 and ds_attr match, the export is successfully confirmed. But the value of mv_attr1 remains unchanged and is different from mv_attr2. In the next synchronization cycle, the value of mv_attr1 will be synchronized to the value of fim_attr, which results in an unwanted value.
If full synchronizations are used, everything works as expected because all entries in the multi valued attribute are taken into consideration. On a delta sync, only the changed fields are evaluated. We applied an advanced import flow to allow the flow of addresses generated by Exchange for newly create mailboxes.
if (csentry["ProxyAddresses"].IsPresent
&& mventry["ProxyAddresses"].Values.Count == 0)
{
mventry["ProxyAddresses"].Values =
csentry["ProxyAddresses"].Values;
}
Summary
The proposed configuration allows two-way updates while enforcing precedence for one data source. However, it does not work for multi valued attributes using delta synchronizations.
