1dent1ty cHa0s

I've been remiss in talking about TEC this year, but I'm happy to say that we're completing several FIM 2010 TAP engagements and starting a few more new FIM projects so it's a busy quarter for sure. Ensynch is sponsoring the TEC 2010 conference for the 2nd year now and we have three new speakers to introduce as well:

	Jeff Holliday Solutions Architect, Ensynch Jeff Holliday is the Solutions Architect for Ensynch and their SharePoint Consulting Practice. He oversees the technical solution designs for all SharePoint projects and managed Ensynch’s participation in the SharePoint 2010 Partner Technical Preview Program. He currently focuses on architecture design, branding customization, business process automation and web part development. Holliday has designed, built and deployed everything from single server, single site SharePoint installations to multi-continent/multi-farm global infrastructures. Jeff and Chris Calderon are presenting a combined session: Federated SSO Solutions Using SharePoint 2010 Speakers: Chris Calderon and Jeff Holliday In the world of on premise and hosted “cloud based” solutions, how can you best simplify your coexistence strategy? Attend this session presented by Ensynch’s Identity Management and SharePoint teams to see how the combined knowledge of each practice helped shape one of the most robust methods for you to enable Single Sign On for your on premise and cloud based apps.
	Joe Zamora  Senior Consultant, Ensynch Joe Zamora is a senior consultant in the Identity Management practice at Ensynch. Joe has 10 years experience in development, is the author of the CShark blog: http://c–shark.blogspot.com/, and has published several projects on Codeplex for the FIM 2010 community. Custom Workflow Development in FIM 2010 Speaker: Joe Zamora Get an in-depth look at the extensibility of Forefront Identity Manager 2010 through the use of custom workflow development. Although FIM 2010 includes a new “codeless provisioning” feature set, you’ll find that you can’t quite satisfy all real-world business requirements with codeless provisioning. Learn how to tap into the power of FIM’s new request framework that’s built on Windows Workflow Foundation. Overcome the first hurdle of custom development by demystifying the process and discovering what resources are available. Learn the tools of the trade, ins and outs, gotchas, and hidden gems of workflow development. Finally, bring it all together with a demonstration of a custom workflow that’s already available to the community.
	Justin Hiedeman MCTIP Enterprise Messaging Administrator, Ensynch Justin Hiedeman, MCTIP Enterprise Messaging Administrator, has been working with Microsoft Exchange for nearly 10 years. The past 2 and half years have been spent as a senior consultant with Ensynch Incorporated designing and implementing Unified Communications solutions for customers across the Southwest. His certifications include: MCSE, MCITP: Enterprise Messaging Administrator and MCTS: Office Communications Server 2007 – UC Voice (Ensynch is also a select Microsoft UC Voice partner). As a Solutions Architect for Ensynch he has designed and led numerous Exchange migration/implementations from Groupwise, Lotus and Exchange, to Exchange/Exchange Online projects. Exchange 2010 Migration to Microsoft Exchange Online: Hands-on Workshop Speaker: Justin Hiedeman Microsoft Exchange 2010 is available both as on-premise software and as a hosted service, and you can now choose the right deployment option for your organization, whether you deploy Exchange Server on-premises, host your mailboxes with Exchange Online, or combine these two options in a hybrid deployment. In this hands-on lab, you will configure an on premise Exchange Server 2010 environment for a mock enterprise. An existing Exchange Server 2007 environment will also be part of the lab from which we will migrate users to on premise Exchange 2010 servers as well as to Exchange Online. Administrators will experience the integration and complexities of managing on premise users and cloud users from the same tools. Lastly, administrators will learn the basics of managing users in a mixed on-premise/online-cloud environment.

David Lundell, Chris Calderon and myself will also be returning, so look for us there and be sure to check out our sessions! If you're attending the pre-conference training, be sure to check out Justin's Exchange 2010 workshop.

It's finally here, FIM 2010 has been released to manufacturing and is now available to TAP and RDP customers while media will likely be available by the April timeframe. You can download the evaluation version here now:

• Microsoft® Forefront™ Identity Manager 2010 Evaluation Version

The official announcement was made today at the 2010 RSA Conference in San Francisco during Scott Charney's keynote. I would also encourage you to sign-up for the upcoming TechNet webcasts on FIM.

History

What is now known as FIM 2010 had a long and challenging path to RTM – it started in concept as the successor to MIIS codenamed Gemini – originally scheduled to ship in the "Longhorn" wave, focused on process integration services, including rich workflow, centralized auditing and reporting, codeless provisioning, self-entitlement management and a self-service platform; this was the first time we saw the possibility of adding declarative provisioning, self-service password reset or workflow to the product but these things were on the drawing board as early as 2005. Later on, the efforts were crystallized under the Raven concept and emphasized self-service but both this and the Gemini names were eventually dropped for ILM "2" after MIIS was rebranded as Identity Lifecycle Manager 2007.

By the time the 2006 Directory Experts Conference had rolled around, the concepts had begun to take shape and for the first time I was treated to an architectural futures deck presented by Bobby Gill. Many of the key items conceptualized back in 2005 and 2006 are present in FIM 2010. While auditing features were cut, the plumbing is present in FIM allowing Microsoft Partners, ISV's and future efforts to begin taking advantage of the request and ERE/DRE data present in the system.

When the delay to ship ILM "2" until Q1 2010 was announced at the 2009 TEC Conference, it really hit hard but was ultimately the right decision. The delay gave the product group an entire year to nail down some challenging performance goals and opened up a wealth of opportunities for valuable feedback. Feedback from the TAP and RDP-Lite programs essentially allowed companies to deploy early on RC bits in order to test core functionality and yet delay official licensing until after the product RTM'd. All of the RC participants helped to make the FIM RTM a solid release.

So, for extra credit, who can tell me what the original acronym and term was for the engine theme inspired group management system? It later evolved into what we now know of as the Set->MPR->WF processing engine.

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 <dn> 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