A common problem I ran into was managing multiple Active Directory accounts for a single identity.  The concept is a user with a unique correlationID (cID) in the enterprise may have more than 1 account.  Some users tend to have accounts for administrative functions, testing accounts for development, or training accounts for a classroom they are responsible for. I had needed the way to join all of these accounts to a single MV object based upon the cID value which is pretty simple.  I want to update all connected AD accounts with name changes from HR, and I also want to be able to maintain employeeStatus and trigger deprovision logic if the user is no longer active in the enterprise.

Yet, I only want to import the data from the “primary” account such as sAMAccountName value, telephoneNumber, userStatus, or the user has updated his pager number and I want to flow this to the company directory application.  I would not want to take the updated information from his secondary account if it were updated, since I am only concerned with the main account to flow to other data stores.

The problem arises when you have a direct import attribute flow (IAF) rule defined on the object type.  MIIS (Microsoft Identity Integration Server) has no ability to determine which CSentry attribute value of the connected accounts in the same Connector Space you intend to import to the MVentry.  Attribute precedence across MAs does not take place here since all objects are contained in the same MA, and MIIS will throw an ambiguous import flow error.

Once this situation exists, you can no longer use a direct mapping attribute flow rule, and will have to use an advanced rule for all attributes you intend to import into the metaverse to provide MIIS with the direction of which attribute to import from which CSentry.

So how do you determine which user object to import data from?  Well the simple way is to tag a single user account as “PRIMARY” via the employeeID attribute, and have an import flow rule such as:

case "IAF_telephoneNumber":
// determine if telephoneNumber value exists and if employeeID value exists
// and if it contains the PRIMARY keyword
if (csentry["telephoneNumber"].isPresent
&& csentry["employeeID"].IsPresent
&& csentry["employeeID"]value == "PRIMARY")
// This is the primary ID for this cID so we want to import
// it's telephoneNumberValue
mventry["telephoneNumber"].value = csentry["telephoneNumber"].value
//Do Nothing.  It may not be the primary user or no telephoneNumber.

This would require you to properly tag the PRIMARY user, and keep track of this tag is on the proper user from the identity lifecycle of the user accounts.   This adds some overhead, and all new IAF rules have to follow a similar path of checking to see if the current CS object is the PRIMARY and available for import.  This allows you to manage the import attribute flow, while maintaining all joined objects benefit from the Export Attribute Flow (EAF) rules.

Sadly in my environment, this was a too simplistic approach and I had to delve deeper into automating the decision of what the “PRIMARY” account is without the luxury of having a tag defined to help out.

You could also use a common naming format to identify Admin accounts by not importing attributes from the user account that matches your format for admin account naming (“Adm-username”), but it’s possible not all of the accounts will conform to these conventions in a distributed environment.

I’ll post the MA code I used to automate the discovery of the primary user across multiple domains by giving MIIS some intelligence, and which user object to trigger the IAF rules from, and ignore the rest in a later post.

This post also applies to Identity Lifecycle Manager (ILM), and Forefront Identity Manager (FIM) as well, since they are both based on the same synchronization services.

This also applies to Microsoft’s Identity Lifecycle Manager (ILM) and Forefront Identity Manager (FIM) products.