Bobby and Nima's Forefront Identity Manager Blog : Forefront Identity Manager

Run on Policy Update - Retroactive Policy Enforcement

bobbygill — Sun, 08 Nov 2009 02:39:00 GMT

Somewhat hidden within Forefront Identity Manager 2010, there is a very useful feature for action workflows called "Run on Policy Update".

Here are the situations where you may find this feature useful:

1. You are creating a new Management Policy Rule (MPR), such as one to provision all users an AD account, and you want one or more of the action workflows in your new MPR to be applied, upon creation of the MPR, to all the members of the MPR's Resource Final Set (also referred to as "Target Resource Definition After Request" in the portal's MPR wizard). For example, you may be creating a new MPR to apply a new Synchronization Rule to all users. You may want to retroactively enforce this new policy by applying the Synchronization Rule workflow to all users that already exist.

2. You are enabling a previously disabled MPR, and you want one or more of the action workflows in the MPR to be applied, upon enabling of the MPR, to all the members of the MPR's Resource Final Set.

3. You are adding a new action workflow to an existing MPR, and you want the new workflow to be applied to all the members of the MPR's Resource Final Set, immediately upon adding the workflow to the MPR.

4. You are modifying the Resource Final Set of an existing MPR to reference a new set, and you want one or more of the MPR's action workflows to be applied to all the members of the new Resource Final Set, immediately upon modification of the MPR.

5. You are manually modifying the membership of the Resource Final Set of an MPR, either by modifying the set's Filter or ExplictMember attribute, and you want one or more of the MPR's action workflows to be applied to all the *new* members of the new Resource Final Set, immediately upon modification of the set.

The "Run on Policy Update" feature is an option that lives on action workflow definitions, as an attribute labeled "RunOnPolicyUpdate" bound to the WorkflowDefinition resource type. When this boolean attribute is set to "true" for a given action workflow, if any of the 5 scenarios above are encountered with an MPR that uses this workflow, the workflow will be automatically applied to the members of the Resource Final Set of the MPR.

Following is a table that summarizes the cases where a "Run on Policy Update" enabled action workflow is applied, in addition to the normal cases where a new Request satisfies all the criteria of an MPR that uses the workflow.

User Request	Resulting Action by the FIM Service
Create new MPR	Apply each "Run on Policy Update" enabled action workflow referenced by the new MPR to all members of the MPR's ResourceFinalSet.
Enable an existing MPR	Apply each "Run on Policy Update" enabled action workflow referenced by the enabled MPR to all members of the MPR's ResourceFinalSet.
Select a new ResourceFinalSet for an existing MPR	Apply each "Run on Policy Update" enabled action workflow referenced by the MPR, to all members of the new set referenced by the ResourceFinalSet attribute.
Add a new "Run on Policy Update" enabled action workflow to an existing MPR	Apply the newly added action workflow to all members of the MPR’s ResourceFinalSet.
Modify the filter of a set	For all MPRs whose ResourceFinalSet references the set being modified, apply each "Run on Policy Update" enabled action workflow mapped to the MPR to each resource that transitions into the set because of the filter update.
Update explicit membership of a set	For all MPRs whose ResourceFinalSet references the set being modified, apply each "Run on Policy Update" enabled action workflow mapped to the MPR to each resource that that is added to the set.

Note that simply enabling the “Run on Policy Update” option for a workflow does not result in the workflow being automatically run. The workflow will only be run upon completion of one of the requests outlined in the table above.

Disabling the “Run on Policy Update” option for a workflow will allow you to perform any of the user requests outlined above, without the workflow being automatically run.

If you submit one of the user requests outlined above, thereby triggering the execution of a “Run on Policy Update” enabled action workflow, you can cancel all the workflows that have been triggered by simply cancelling the request that triggered them (eg. cancel the request tracking the creation of the MPR).

Cheers,

Nima

Farewell!

bobbygill — Tue, 28 Jul 2009 00:56:00 GMT

As a lot of you may already know, after 4 years of working on MIIS / ILM / FIM I've decided to leave Microsoft. No, I'm not being fired, nor am I jumping ship to a competitor :) Rather I am leaving Microsoft to pursue a MBA at Columbia starting this fall.

If I have one hope is it that you have found this blog, along with the talks, webcasts and reports I have done to be useful in helping to digest the seemingly endless new concepts coming out with FIM 2010. It can be a lot to take in one shot for sure, as sometimes I even find myself scratching my head as to how something works and even more so when I attempt to describe it,

To all of my colleagues and friends I have made in my time on the MIIS/ILM/FIM teams, I wish you all the best going forward. As for me, its back to the student life for the time being.

Going forward, I'll still be available to help people with FIM (as much as my new student life permits of course!) if you want to reach me, you can email me at bobby.gill (at) gmail.com and you can always find me on facebook at www.facebook.com/jasjeet

Ill be at TechReady tomorrow morning and I should be at the FOX Sports Grill event in the evening, so come grab me if you see me.

In the meantime, I leave this blog in the more than capable hands of my colleague Nima.

Thanks

Bobby

Opening the mailbox:

bobbygill — Tue, 14 Jul 2009 22:49:00 GMT

Question from one of our readers:

From:
Sent: Tuesday, July 14, 2009 11:06 AM
To: Bobby Gill
Subject: (Bobby and Nima's Forefront Identity Manager Blog) : Question about FIM/Outlook
Importance: High

Good afternoon Bobby and Nima's.

I read your blog often as I await the release of MMS...I mean MIIS...I mean ILM...I mean FIM :)

I keep seeing things about how nice it is to request to be added to groups or distribution groups through Microsoft outlook. Are all of the features available from inside Outlook available from the web interface?

The reason I'm asking is that a lot of clients may have a need to use identity management to synchronize their Microsoft world with their HR world...and their email world ! (*cough Lotus Notes*). I understand that the level of integration (especially for distribution lists) is probably not the same, but are most other features of the Outlook FIM client available on the web console ?

Thank you and feel free to post the question and answer to your blog, as I think it may help other people.

------

The simple answer to the question above is that the Outlook plug in for FIM 2010 contains a proper subset of functionality available within the web portal. That is everything that is possible through the Outlook interface is available within the web portal.

However the opposite is not true. While the Outlook plug in allows you to manage group memberships and approvals/requests, it does not nearly provide the same level of functionality as the web portal. For instance the creation of groups (both static and dynamic), deletion and modification (outside of membership) can only be done through the FIM portal.

Further, the Outlook plugin requires both Outlook 2007 as well as Exchange 2007 running on the backend. However, if you are using an email client which is not Outlook 2007, or a email server that is not Exchange 2007, you can still send notifications and approvals to email clients via any SMTP server. To perform any operations on said messages will require you to go to the portal and perform .

Introducing Hierarchical Provisioning

bobbygill — Wed, 20 May 2009 22:35:00 GMT

Yesterday I was eating my bowl of Frosted Miniwheats (by Kellogg) for dinner and out fell a coupon for another free box of Miniwheats. “Oh hot lam!” I exclaimed to myself. I had totally not seen the offer stamped on the front of the box for a free box of Miniwheats when I had purchased the jumbo, bachelor sized box of Miniwheats at Costco last Sunday. A bowl of Miniwheats alone is enough to brighten my days, but winning another 12oz of the half-sugar, half-fiber narcotic ? Well that’s like Christmas in May. I love hidden surprises.

Much like my box of Frosted Miniwheats, FIM 2010 has a few hidden surprises of it’s own that lurk underneath the covers and are often ignored. One of these features is Hierarchical Provisioning. Much like the name would imply, Hierarchical Provisioning allows objects, and more importantly, any missing parent containers, to be provisioned into the connector spaces of LDAP MAs . Previously in MMS, MIIS, and ILM 2007, if one wanted to provision a user into a container in Active Directory, one would need to ensure that they created the container in Active Directory prior to provisioning the user with MMS/MIIS/ILM. However, with Hierarchical Provisioning, you do not need to do this anymore. With some settings configured in the Management Agent (MA), the missing container can be created automatically by the Active Directory Management Agent, and then the object provisioned within it.

The steps to configure this feature are relatively straight forward. Assume that you want to provision the following user into Active Directory: “cn=Bobby Gill, ou=Redmond, ou=Users, dc=fabrikam, dc=com”. In this case, the Redmond OU does not exist in the Active Directory domain. Before the ILM AD MA can provision this new user into the OU specified, the OU needs to be created in Active Directory. This is where Hierarchical Provisioning comes into play.

As an ILM Admin, to enable Hierarchical Provisioning on a LDAP MA, you need to configure a mapping within the MA such that anytime upon export the MA detects that a parent of a object doesn’t exist, it knows what object to create in the connected directory for that parent. This configuration is done within the LDAP MA screens by mapping valid DN components to object classes in the connected directory. In this case, you would set up a mapping between the “OU” DN component to the object class “organizationalUnit”. Thus in the above scenario, when the MA is exporting the object to AD and realizes that the “OU=Redmond” parent is missing, it will look up the mapping for the “OU” component and first create a new organizationalUnit object named “Redmond” and then export the new user into the container.

Steps to configure Hierarchical Provisioning:

Create a new instance of your favorite LDAP Management Agent. Personally, I’m a Microsoft guy, so obviously I always choose Active Directory Domain Services.
You’ll notice a new page on the left tab titled ‘Configure Provisioning Hierarchy’.
Map DN components to Object Classes. The DN Component list box lists all known valid DN components for the given directory, this is inferred by analyzing the LDAP schema of the directory. To the right is the list of available object classes in the directory, again taken from the LDAP schema.

4.) Mappings are created by selecting a DN component in the left list box, and a object class in the right list box, and then clicking “new”. You can only create 1 mapping per DN component.

Once setup, Hierarchical Provisioning is transparent to the actual provisioning mechanism. Thus, if you are using Synchronization Rules or even a traditional scripted Metaverse Extension, these settings will be applied to both at export time. Hierarchical Provisioning further reduces the burden on IT Pros by allowing much more flexibility in terms of provisioning decisions made in the FIM Workflows and eliminates an often tedious manual step whenever a new business unit comes online and an associated container or OU needs to be created.

The feature is available to all LDAP Management Agents and is available in the ILM "2" RC0.

Dependencies - not just for avoiding taxes!

bobbygill — Sat, 02 May 2009 00:16:00 GMT

What's our name again?

Whoa, new product name! For those of you who have been chasing butterflies for the past month, what was once known to us as Identity Lifecycle Manager "2" is now called Forefront Identity Manager. I know, it's not the sexiest name in the world and is probably the 5th different name the product has had since it's conception, but it reflects the combination of Microsoft's security and identity product lines into the Forefront brand announced last year.

Personally, I wanted to name the product "Black Thunder II", but then again there are a myriad of reasons why I am not allowed to name Microsoft products.

But back onto the topic at hand...

Synchronization Rule Dependency

I decided to take some time off today to briefly talk about Synchronization Rule Dependencies, a powerful yet not well understood part of ~~ILM~~ FIM's synchronization capabilities. In brief, a Synchronization Rule Dependency allows one to construct and apply a series of outbound Synchronization Rules ontop of each other. The scenarios that spring to mind whereupon this functionality is useful are things such as adding/removing Exchange mailbox provisioning, or adding/removing VPN access upon a user's Active Directory account (with the former 2 being dependent on the latter).

If an Outbound Synchronization Rule (the dependent) is marked as having a dependency on another Synchronization Rule (the root), the dependent rule will apply itself ontop of the connector that the root Synchronzation Rule is applied on. At run time, when a FIM Action Workflow attempts to add an Expected Rule Entry (ERE) object for the dependent Synchronization Rule onto a FIM Resource's Expected Rules List (ERL) , there needs to also exist an ERE-Add object for the root Synchronization Rule on the ERL. (I am just going to take a minute here and say I don't think there has been that many acronyms stuffed into one sentence since the merger between the wrestling giants WWF and WCW was announced). Conversely, if an Action Workflow adds a ERE-Remove entry for a root Synchronization Rule, all EREs that correspond to Synchronization Rules further up the dependency tree will be removed.

Its important to note that when you design an Action Workflow to add or remove a series of EREs that correspond to a Synchronization Rule dependency chain, the root rule must be added to the workflow surface prior to any other dependent rules.

Multiple levels of dependency can be created, with more than one Synchronization Rule being made to depend on a single Synchronization Rule.

In the Synchronization Rule Designer, to create a Synchronization Rule Dependency is relatively straightforward. The first page of the designer allows you to select another outbound Synchronization Rule to make a new Synchronization Rule depend on. When selected, the Scope and Relationship pages are automatically greyed out. Once a Synchronization Rule is made to depend on another rule, the only settings that are adjustable on that rule are the workflow parameters and the outbound attribute flows. Conceptually, this falls cleanly from the fact that a dependent Synchronization Rule is being applied "on top" of another rule.

I wish I could paste some screenshots of what this looks like, but the FIM UI has changed markedly since the RC 0 release and I dont want to ruin the surprise just yet :)

The canonical scenario in which Synchronization Rule Dependency's are used are around creating business processes to manage the provisioning/deprovisioning of capabilities that stem from attributes set on a Active Directory user account. In a typical provisioning scenario, one would construct a base "Active Directory User Synchronization Rule" which, as the name implies, would create a new AD User object, flow the necessary base DN, samAccountName and name information. On top of that, you could then model a dependent Synchronization Rule for granting an Exchange mailbox. This Synchronization Rule would be dependent on the Active Directory User Synchronization Rule, and as a consequence would only have a single flow to the homeMDB attribute. Modelling the user account provisioning seperately from the mailbox provisioning, through the use of Synchronization Rule dependency, allows you to define independent business processes around the lifecycle management of the two through Management Policy Rules and workflow.

As always, feel free to email me any questions you might have and I will do my best to get back to them.

Bobby