While we’ve touched on sync rules in the past with some examples, I’d like to dedicate some time to actually stepping through the creation of various types of sync rules. To start off, we’re going to do what I would consider the most common and one of the first (if not the first) to be created in most environments: inbound users from AD. Now, the “from AD” piece, while important, is less important. The main purpose of sync rules is to move objects (users, groups, etc.) and/or their attributes from point A to point B. That being said, there are subtle differences between sync rules to/from different data sources (such as AD, SQL, Oracle, etc.). Aside from that, the primary reason I like to call out the data source in the name is for human readability. When I create a sync rule named
“Inbound Users from Contoso AD”
It tells me everything I need to know. I get the direction relative to MIM (inbound) the object class being managed (users) and the connected data source (Contoso AD).
To begin, click on “Administration” in the bottom left-hand corner. This will open the “Administration” screen. Here, select “Synchronization Rules”. When the “Synchronization Rules” screen opens, at the top, select “New”:
This will open the “Create Synchronization Rule” dialogue. Enter a
and (optionally) a
. Select a
Data Flow Direction
(in this case, “Inbound”), and click “Next” to continue.
Now we must scope this SR to an object class and data source. For
Metaverse Resource Type
, select “person”. Under
select the Active Directory you wish to connect to. *NOTE: If this were, for example, a SQLMA, we would instead select SQL from the drop down menu.* Under
External System Resource Type
, select “user”. Please note, while there are “Inbound System Scoping Filters”, the use case is less common and not covered in this scenario. Click “Next” to continue.
Under “Relationship Criteria”, we must define a relationship mapping. This will be, ideally, a globally unique value mapped for the purpose of effecting joins. In my lab, I am using a custom attribute (PoliticianID) mapped to employeeID. Also, please note, if you would like these users to actually be created in the MIM portal if they do not already exist, you MUST select
Create Resource in FIM
. Failure to select this checkbox will result in a new user from AD not being created in the portal and also not giving an error. After all, you didn’t tell it to create the user, so it didn’t. This is easily missed and can be mildly infuriating.
Next, we must define some attribute flows. In a code driven, sync only solution, these flows would have been created directly on the ADMA under the “Configure Attribute Flow” tab. Now, in an SR based solution, we simply move those flows here. Click
New Attribute Flow
and select your data source object. Next, click on the
tab and select the data target attribute, then click
Here are some example flows from my environment. Please note that, while there are certainly commonly used attributes and flows, this will
in large part
be defined by your environment. I don’t know your business or data and cannot even begin to guess at what attributes you need. Also, please remember that in certain data sources (such as Active Directory), attributes may have peculiar or unclear names that don’t directly match MIM attributes. For example, “givenName” in AD maps to “firstName” in MIM.
Also note that you are not limited to static flows. For example, your environment may have multiple AD forests or domains. As such, you may have multiple SRs bringing users into the portal. For human readability in the portal, its nice to have a “domain” attribute set, and this can be easily done with a string value on the ISR. Rather than selecting an attribute, scroll to the bottom and select “string”.
Then enter the friendly name of your domain. Under the
tab, select “domain”.
Once you have reviewed and are satisfied with the values, click “Submit” to create the sync rule.
Questions? Comments? Love FIM/MIM so much you can’t