Changing A Value Used By Join Logic
Today I’d like to take a few moments and discuss something that I think is a common misconception around join logic. Let’s say we have a simple environment with a FIM portal and Active Directory. For user objects, let’s say we’re joining on AcountName->sAMAccountName. The question I get asked quite frequently is, “What happens if I change sAMAccountName in AD? Will that break my join?”. While this would seem logical (after all, if that value changes, how will FIM know to associate those people?), the answer may surprise you. As it turns out, changing the join attribute on the ADMA will not break joins. Don’t believe me? Let’s step through the process…
First, let’s take a look at the configured join logic on our ADMA:
Here we see two configured rules. First, attempt a join on “employeeNumber->PoliticianID”. If that fails, attempt a join on “sAMAccountName->accountName”.
Likewise, if we look at our inbound user synchronization rule, we see the following relationship mapping:
Again, “sAMAccountName->accountName”, as well as a static attribute flow of the same:
If we pick a random pre-existing user in the FIM portal to look at, we can see both the Account Name (sAMAccountName)
As well as the PoliticianID (employeeNumber).
So, we now know that we are joining (or at least attempting to join) on “sAMAccountName -> accountName” or “employeeNumber -> PoliticianID”. We have also now confirmed both of those attributes on our target side (in this case, the FIM portal). Knowing this, let’s go change one (or both) of those values in Active Directory.
Here, we have added a “b” to the sAMAccountName
And changed the employeeNumber from “0016” to “1616”.
With both attributes changed, when we do an import of the ADMA, we should see one update (for our modified user). Following that with a synchronization, we can now check the FIMMA “pending exports” and should see:
Here, we see the old and new attribute values for both AccountName (sAMAccountName) and PoliticianID (employeeNumber). Both are anchor attributes used for join logic, both have now been changed in the data source.
Following an export of the FIMMA, we can now get into the portal and will see:
Notice both “Account Name” and “PoliticianID” have been changed.
Now, for the question that’s on everyone’s mind: how? The answer is both simple and complex. Simple in that once an object has been managed by FIM (i.e., the initial join has occurred for pre-existing objects, or the user has been provisioned in the case of new objects), FIM no longer associates that object using the anchor attributes. Rather (and here comes the complexity), relationships between the connector space and metaverse are actually maintained in link tables within the SQL database. I don’t want to get too specific on this piece, but the main thing is that objectID is the value in use (which equates to csObjectID in the connector space and mvObjectID in the metaverse). It is also worth noting that join and projection logic is skipped once an object reaches the state of “connector”. In other words, once an initial association (join) has occurred, sAMAccountName is, essentially, no longer needed (because the object is now considered a regular connector).
Questions? Comments? Love FIM so much you can't even stand it?