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.

I gained a new appreciation for our new controversial object classes in FIM, the Expected Rules Entry (ERE) and the Detected Rules Entry (DRE) last week while at the MVP Summit. The ERE is necessary for creating the relationship between an object and a Synchronization Rule and if you've spent any time working with Declarative Provisioning then you are well aware of how this relationship is created and maintained. Until now I've been principally focused on the negative performance impacts of adding additional objects to the connector space as well as critical references, which the older MIIS Sync Engine had difficulty with in the past. What I failed to appreciate was some of the metadata around the ERE object – let's take a look at one:

NOTE: Either Update 2 or Update 3 added the "resourceParent" attribute which finally provides a back link to the object whereas previously only the forward link was present!

We have a few interesting attributes here:

• createdTime – This time stamp attests as to when the relationship was created via policy, but not when it was actually applied to the live object
• expectedRuleEntryAction – This simple string attests to the type of action that was performed
• status – Attests as to the applicability of the linkage, should the Sync Service be in the process of applying the relationship it will be 'Pending' but once completed it will appear as 'Applied'
• resourceParent – This is the back link to the object that this ERE applies to
• synchronizationRuleID – This is the forward link to the Sync Rule this ERE applies to

From a reference point of view, we could query for all ERE's and return both the Sync Rules being applied as well as the object they apply to, or we could follow the forward links from the objects (typically the person or group) themselves. Because the Sync Rule payload is XML, we could even follow the forward link to the Sync Rule and extract that policy. All of this is leading us to the foundation of simple reporting for policy application – the plumbing is there now, but as of yet there are no consumers.

Compliance

So, we have a good foundation for reporting on what policies are applied to which objects (remember, we can extend FIM to apply to more than just people and groups or roles), but the missing component is the final attestation that the policy was applied to the live objects – this is where the DRE comes into play.

I had pretty much written off the DRE as one of those neat ideas that someone had which had become obsolete during development as other capabilities arose. I think as Architects of a FIM IDA solution we have a much simpler, and more performant, way to confirm that something was applied in the target connected directory. The basic scenario is this:

• Create a feedback process that tells me when I can perform a confirming action, typically emailing someone that the action has completed but it could be a more complex action involving dependent automation

If you scour the forums you can find reference on how to accomplish this by flowing something like DN or objectSID back from AD (for example) and then building policies on the entry of that data into the portal. It's cake really, but I had neglected the second scenario, which at this point should come as no surprise that it is reporting based:

• Create a feedback process that attests as to when the policy was applied to the object in the connected directory

Having the same metadata available for the DRE object allows us to close the loop on when the object finally had the policy applied. From an automation perspective, the DRE really facilitates the reporting scenario around compliance. At this point in time there are no commitments from Microsoft as to when an official reporting solution for FIM would be available so it falls to ISV's and the community to provide it.

Another cross-blog awareness post – our very own Joe Zamora completed updates to his FIM Query Tool that allows you to run queries against the FIM Web Service while running on the RC1 build. With it, I can run XPath queries against the web service (using the "unsupported client") and get a result set. In this manner it's a great way to vet queries without having to resort to building objects in the portal or timing out the ASP/WSS request channels.

Please give Joe some feedback and help us improve the tool!

CShark: FIM Query Tool for FIM 2010 RC1

I meant to draw attention to this earlier, but Darryl has the best breakdown of each of the places you can configure timeouts within the FIM product. The ASP.Net timeout was a new one for me and explains some of the timeouts I've seen even when extending all of the FIM specific thresholds.

Darryl Russi's Blog : Extending FIM Timeouts

FIM RC1 Update 3 has been out for awhile now and there has been some excellent coverage of the additional functionality that it brings:

• Final Update for FIM RC1 released
• Update 3 has been released for FIM 2010 RC1

One of the unsung heroes of Update 3 is a feature we have been asking for since RC0, Request Object Expiration. This process is finally available in Update 3 but in getting to Update 3 you may be in a small minority of people, myself included, that encountered problems during the database upgrade process. There is a bug on connect tracking this here:

• Update 3 fails due to PostProcess0004.slq errors

I didn't see this error directly, I encountered a failure, retried the upgrade, and then it "worked". Upon further examination I began to suspect that it did not actually apply any of the database upgrades. I would suggest looking at the following thread to see if any of these issues are affecting you:

• Administrators Set in FIM Portal

Specifically, my response here:

Ahh, you've encountered the same issue that I did - upgrade fails initially, subsequent updates complete (due to the version number being incremented incorrectly) but the database upgrade failed to apply updates to the MPR's.  In my case I can't start with a clean database, I have to upgrade otherwise I'll lose months worth of work.

I am still searching for a fix - best I can tell you is restore back to Update 2 and try your upgrade again. The partial update problem will manifest in the following manners:

• Access Denied errors when attempting to Create, Modify or Delete MPR's
• You will not see the new attribute in the schema - "Management Policy Rule Type", nor is it bound to the user object
• You do not have the 4th FIM SQL job - FIM_DeleteExpiredSystemObjectsJob
• SELECT * FROM FIMService.fim.Version will return '5' (the version for Update 3)

If you are encountering these issues, please go and register at the bug listed above.

Expiring Request Objects

It was my quest for the FIM_DeleteExpiredSystemObjectsJob that led me to suspect something was wrong and not finding the additional schema updates clinched it. In any case, applying Update 3 will finally clean out all of the expired Request objects that have been accumulating in your database. I'll follow-up with a more in-depth look at how you can control this process and tune it for your lab versus your production environments.

Set Restrictions

Another disappointment in Update 3 is losing the ability to nest Group Membership into a Set for the purposes of delegating rights within the portal. I cover this in the following Connect bug, so if you agree, please vote this up and add your own testimonials or business cases to help prioritize a fix.

• RC1.3 – Removal of 'Resource ID IN ' for Set filters breaks delegated permissions model

Improved Error Reporting

One of my "jump up and do the happy dance" moments was finally seeing this screen after getting the failed-creation-via-web-services error:

WHOO HOO!

Now we are only a few clicks away from a meaningful error message and we don't have to go digging through logs to get it. :)