1dent1ty cHa0s

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.