1dent1ty cHa0s

When adding FIM Declarative Provisioning to an existing AD, one of the issues you will need to account for is the need to apply the provisioning rules to objects that are pre-existing. These are accounts already in AD which your policies have not applied provisioning rules to mostly because your policies are built around the creation of objects or objects transitioning into certain sets. However you got here, you now need to identify these objects and force your provisioning rules to run against them.

For this solution you will need to contribute an item from the AD accounts to the FIM portal object. You may have projected objects from AD into the portal, or from HR into the portal and have the AD objects joining up. In any case, I added a new Indexed String attribute to the portal and metaverse schema's called "ADDN" and began contributing the value from AD through the FIM MA and into the portal. This sets up one side of our test – we can look for Person objects whose ADDN starts with "CN=":

/Person[starts-with(ADDN, 'CN=')]

To get the other clause in the filter we need to identify objects whose ExpectedRulesList is empty. We don't have an operator or function that tells us whether or not a multi-valued reference list is empty or not, so we need to see if the list matches any of the ComputedMembers of the All expected rule resources (ea2d3cc6-de3a-4c67-aad7-d7f930eb7378) set which is provided out of the box. This part of the filter looks like so:

/Person[not((ExpectedRulesList = /Set[ObjectID = 'ea2d3cc6-de3a-4c67-aad7-d7f930eb7378']/ComputedMember))]

When we put it together we get this:

/Person[(starts-with(ADDN, 'CN=')) and not((ExpectedRulesList = /Set[ObjectID = 'ea2d3cc6-de3a-4c67-aad7-d7f930eb7378']/ComputedMember))]

The contents of this set should be everyone who has an ADDN contributed but does not have any ERE's attached. Now you can create a new Transition-In MPR using this set and then attach your provisioning workflow as the Action. Make sure that the Action WF has the "Run On Policy Update" option checked before you create the policy in order to execute it immediately. You will also want to remember to turn ROPU off and disable this policy as you should only have to do this once, or whenever you have bulk adds to AD outside of FIM (like a migration).

Here are some other loosely affiliated ramblings.

FIM Sync

Another issue to be aware of when dealing with pre-existing accounts are accounts that have not joined but you're about to apply the provisioning logic to. Under normal circumstances, FIM would process the change, see there is no existing connector and then create a new one. Upon processing by FIM Sync you would get a provisioning failure (and a transaction rollback) because the DN/and or account name is already present. We used to solve this problem with provisioning rules extensions by swallowing the exception and letting the AD object join on the next sync of the ADMA, but we don't have that luxury anymore. To work around this type of issue you will need to disable Sync Rule provisioning, allow the objects to Project into the metaverse and then run the sync from the ADMA to join them up.

Relationship Criteria

When defining Relationship Criteria for Sync Rules, I would caution you to always use something that the remote data source has a unique constraint on. For AD, the most convenient attribute to use is samAccountName, so your Relationship Criteria mappings should always be using the AccountName –> samAccountName form. You can define whatever you want, and while you may feel inclined to use employeeID, if you end up with a duplicate value in AD you may not get what you intended when the sync applies, and worse yet, you may not know until someone complains. By forcing the SR to use something the data source applies the constraint on, you will see an error long before this happens.