Keeping Track of Attribute History in the Forefront Identity Manager (FIM) Sync Engine

Posted by: Michael Baker

Recently, one of our clients had a scenario that required them to keep track of the proxyAddresses attribute history between two Microsoft Active Directory (AD) domains.  Since FIM Sync Service doesn’t retain any history of attribute values (as simply a state-based synchronization engine),  this required a bit of thought and planning.

Examining the need to keep track of the history and exploring options, we came down to the solution through a simple one-revision history mechanism with FIM Sync.

Without getting into too much history, let’s start with a brief overview of the scenario.  There are two Active Directory (AD) domains (let’s refer to them as DomA and DomB) and users are being synchronized from DomA to DomB.  Where it gets a little complicated is that each domain has its own Exchange environment, and each adds unique values to the proxyAddresses attribute of mail-enabled user objects.  With this setup – the Sync engine would normally overwrite the values in the proxyAddresses attribute in DomB, in essence deleting any values added by the DomB Exchange environment (see Figure 1).

Figure 1 - Existing Sync Environment

Figure 2 - Adding a SQL Database to Hold proxyAddresses History

With the DomA values in the database, we could refer to them if the values in DomA changed.  The changes would flow in from DomA, we would apply the logic we needed in the out-bound sync to DomB by referring to the new values from DomA and the previous DomA values (now stored in both the SQL database and a new attribute in the Metaverse).  This would give us a one-revision history, which is all we needed.

To set this up; we needed to add the following items to our FIM Sync infrastructure:

• Two new tables to hold the proxyAddresses values (if this were a single-value attribute, we would only need one table, but because it is multi-valued we need two – one to hold the record, and one to hold the record’s multi-values).
• A new attribute in the FIM Metaverse to hold the one-revision history of the proxyAddresses values from DomA (we will call proxyAddressHistory) .
• A new SQL MA to interface with the new table(s).
• A new bit of provisioning logic to create the new entries in the SQL table.
• New export logic in the DomB MA for the proxyAddresses attribute

Figure 3 - Create New Metaverse Attribute

Creating the New SQL MA

 On the “Configure Columns” section, make sure that the P_ID column is set as the Anchor.  Click the Multi-value button and select “attributeName” from the drop-down for the “attribute column name”, click “String attribute column” and choose “attributeValue” from the drop-down, and click the New button and add “ProxyAddresses” as a new multi-value attribute as Type “String” (see Figure 5 below).

Figure 5 - SQL MA Multi-value Settings

There is no need to worry about Connector Filters or Join and Projection Rules.

In the “Configure Attribute Flow” section, setup a direct export flow from the Metaverse attribute proxyAddressCollection (this is where we are storing values from DomA) to the SQL MA attribute ProxyAddresses, and a direct import flow from the SQL MA attribute ProxyAddresses to the Metaverse proxyAddressHistory attribute (that we previously created) (see Figure 6 below).

Figure 6 - SQL MA Attribute Flow

To use the new history when exporting to the DomB domain, we need to do two things.  First, we need to modify the Export flow from the Metaverse to DomB and change it from a direct flow to an advanced flow (rules extension) with both the proxyAddressCollection and proxyAddressHistory selected as Metaverse attributes to the DomB proxyAddresses attribute (I specified the flow rule name of “proxyAddressCollection_proxyAddressHistory_to_proxyAddresses”).

Next, we need to add that flow rule name to our Case statement in the DomB MAExtension.dll’s MapAttributesForExport() subroutine as below.

The last thing we need to address is the MA run sequence.  Obviously, we don’t want to update the SQL tables before we export to DomB or we would be overwriting theproxyAddresses history with new DomA values – therefore losing the history.  So make sure that you Import and Sync from DomA, Export to DomB (followed by a Delta Import), then Export to the Proxy History MA, and then finally Import and Sync the Proxy History MA to get the history values back into the Metaverse. One thing to note here is that I only got reliable results from the Proxy History MA when I ran a FULL sync after importing.

(ignore)

The need to keep track of attribute history shouldn’t be very common, and we complicated this one with the fact that the attribute was multi-valued, but hopefully the example will help anyone that finds themself in a similar situation.

Tweet