Tuesday, February 23, 2010

FIM 2010 – Finding pre-existing users without ERE's

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.



Hy. Interesting post. Anyway I have one question. If I for example map AccountName from HR database and samAccountName and if they are the same, will AD account be updated ? I mean, shouldn't sync rule recognize existing object and then just update it with attributes from HR during provisioning?


Oh now I get it... You are talking about how to trigger already existing users to be provisioned to AD...


Hi Brad,
I'm totally stuck with this issue, I did follow your steps, the set will have the user once the ADdn is populated, and the MPR will be triggered for the set membership change,
my isse is the dn value is not considered as a rename, it appears as an update to the AD connector, trying to feed the value into the dn, but when i do the delta import i recive the message "exported-change-not-reimported",
i have the dn flow twice (one persistant and one as initial flow only) but still no luck,

any ideas??


It sounds like you're attempting to trigger policy when ADDN is updated, but that's not what this post is about. In this post we are exploring how an existing set of objects can be applied policy (an outbound SR in this case) when you essentially missed the operation that got them in the portal in the first place.

I'm not clear on how you have your attribute flow plumbed. If you wanted to contribute the of the AD object to the MV:ADDN and FIM:ADDN attributes you'd need:
1. Inbound AF/SR: -> ADDN
2. FIM MA Export AF: ADDN <- ADDN
That would get the DN into the portal.

When you mention persistant and initial flows you are talking about an Export Attribute flow to AD and that is the wrong direction to get attributes into the portal. :)


Hi Brad,

I have tried the solution you provide for the FIM Sync issue and the join works, but as soon as I enable again the Sync Rule provisioning the provisioning failure error comes back when I sync AD or FIM.

I am stuck with this, do you know how to get rid of this error? I have quite a lot of objects and a slotion per object is not the best for me...

Thanks a lot!


I've come across an issue like this only once before whereby inexplicably FIM Sync insisted on creating another connector despite the fact that one already existed. I was not able to repro it elsewhere but the problem did go away after completing a Full Import and Full Sync of the FIM MA.

Post a Comment