Partager via

Changing A Value Used By Join Logic

  • Article

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?

>WE WANT TO HEAR FROM YOU!<

## https://blogs.msdn.com/connector_space # #

Comments

  • Anonymous
    November 12, 2015
    Hi, This is a very interresting article. You describe well the problem, but do you have any idea on how to solve this? For example :
  • detect that the value used by join logic has been update (i.e. mventry[attr].value != csentry[attr].value)
  • remove all joins on the object
  • re-evalute join with the new udpate value from a theoretical point of view, this seems very to simple to achieve, but in fact, I do no succeed at doing this. Any idea? Thx in advance :) Sorry for my english, i'm sadly french :)

  • Anonymous
    November 12, 2015
    @itch First lets understand your particular issue you are having, Do you have incorrectly joined objects? Are your Objects just not joining? are you trying to join different resource / object types to one another? Do you have multiple potential joins for connector space? ie do you have 2 objects in a single connector space that meet the join logic? could you provide more detail?

  • Anonymous
    November 12, 2015
    @Anthony Hi Anthony, thank you for fast reply Here's more details: My user can be created both by an ADMA and a SQLMA in the metaverse. There is only one join rule on the two agents (the same join rule on each MA). It is based on a field called "employeeID" (it's just a string, like "AA123123"). My joins rules works well, objects are join with no problem, as long as AD admins fill the good employeeID in their AD. And that is where my problem happend: Sometimes, they make some typing errors on the employeeID in AD end-user profiles (for example they enter AA123122 instead of AA123123), and so the resulting join (or projection) is wrong (because of data quality, which is normal). What I have been asked is to automatically correct the join when they correct the employeeID in their AD. Hope my problem is better explained now.

  • Anonymous
    November 13, 2015
    I am sorry, but I have to respectfully disagree with this.

  1. You are using AD MA example to generalize on a broader topic. Wrong! Each MA type behaves differently.
  2. You are confusing anchor object with Join Rules.  If you did this in any other MA, but AD MA
  3. Let me explain how this works. -AD uses GUID as Anchor Object not sAMAccountName or emplouyeeNumber.  AD MA is a special MA.  
  • Once the object is joined, the join rules are not relevant anymore.  So it is OK to change the attributes used in join rules
  • Unless you change the anchor object, the join will not break
  • In a nutshell - Your misconception is with the fact that you are thinking sAMAccountName is anchor and that is the part that is not true

  • Anonymous
    November 13, 2015
    The comment has been removed

  • Anonymous
    November 14, 2015
    The comment has been removed

  • Anonymous
    November 16, 2015
    hey guys ! Thank for the exchange. I've found a solution to my problem ! I have changed my AD connector filter from "declared import filter" to a "rules extension" where I disconnect the object if I detect an update of the attribute used by join logic: Moreover, this flow chart helped me a lot to understand in which order rules are called: technet.microsoft.com/.../jj572803%28v=ws.10%29.aspx This flowchart give me the idea to play with filter to solve my problem: in my ADMAExtension code: public bool FilterForDisconnection(CSEntry csentry){ ...  check that csentry and mventry exists and are not null  ...  //if employeeID is update, object is disconnected  if (csentry["employeeID"].Value != mventry["employeeID"].Value){    return true;  }  ...  other filter code  ...  return false; ... } So now, i planned two successive sync where: first sync : cs_object is set as disconnector (with code above) second sync : cs object is re-evaluated and rejoin or projected with new employeeID value I don't how how much i am clear with my explanations, but your exchange, and more generally your blog helped me a lot. Thx again, Itch

  • Anonymous
    February 23, 2016
    Nice post. However this does not work for any other MAs. E.g I am using a SQL MA and sAMAccountName as the AnchorID. sAMAccountName is the only attribute unique in this situation. There are instances where the sAMAccountName has to change but this is a DeleteAdd for FIM. Is there any other way the sAMAccountName which used as an AnchorID can be changed?

  • Anonymous
    March 22, 2017
    @ktackett, @Anthony:I think you both are undoubtedly FIM experts and still I think this article could have been written in a clearer and "cleaner" way.In my opinion the most problematic point is the phrase "...changing the anchor attribute on the ADMA will not break joins...". It connects two concepts which - and I think we all agree - are not connected at all! The term "anchor" is only used (in official MS documentation) to nominate the attribute by which an MA maintains the correlation between an external system and a connector space object. And this is true for (probably) every MA. The ADMA is somewhat hiding the anchor (=objectGUID attribute), the SQLMA is (obviously) leaving it up to the admin to decide, but both use an anchor attribute. This is the key point!Join rules are not related to the term "anchor" in the above sense. And you should only use it in the above sense! The correlation between connector space objects and metaverse objects is maintained - and I think we all still agree - by the "internal database link". The Join rule does not maintain any "link", it is only evaluated in the absence of such "link", using some (more or less arbitrary) attributes.

    • Anonymous
      March 23, 2017
      hmmmmmmWhen we speak of "link" between Connector Space and Metaverse we are speaking in regards to the object is clearly defined when viewing the object in the Connecter Space looking at the Lineage where it displays info about how the object is "connected" to the MV and other Data sources. Doing so you can see which MA Projected the object or if which MAs the object was provisioned to or even which MAs the Object has a "join" to hence the "link"