1dent1ty cHa0s

Based on a request in the MMSUG this week from Almero Steyn to provide an update regarding the ship date of MIIS SP2 and the much anticipated Password Portal, the following response was quoted by Simon Veale from Microsoft:

MIIS SP2 is the next service pack release of MIIS. The Identity Management Team received some very consistent feedback from customers in the Beta 1 for MIIS SP2. Feedback from our beta customers indicated we needed to make some significant changes to the release. Specifically, customer requirements around ease of deployment suggested that we investigate alternative designs so that Active Directory-only password reset can be easily implemented – especially for customers who have an all-Microsoft environment such as small and mid-market
customers.

We also have received feedback from customers around the support for SQL 2005, Visual Studio 2005, Virtual Server and 64-bit hardware. We believe we can release a Service Pack that includes this support as well as a number of bug fixes relatively quickly.

Due to the amount of effort required to make the requested changes to the password reset portal, and our imperative to release value to customers as quickly as possible, we made the decision to
release SP2 with the bug fixes and 2005 platform support and to release the password portal in a future release.

We have not yet closed on the timing for release of the password reset portal. We will provide an update on our progress with SP2 and the password portal in this summer.

I can certainly echo Alemero's original sentiment - Ensynch also has companies that are very anxiously awaiting functionality in the new Password Portal because while it's not entirely original, it is a) free, and b) will integrate with their existing or future MIIS deployments. Having seen the beta, and Chris Macaulay's presentation at DEC, I think I can understand why Microsoft choose to decouple it from SP2 as there is still quite a bit of work to be done and even if it is "free", Microsoft does seem to be doing the right thing here by placing form and function above a quick and easy release. I'm hoping that means we get a very functional product as opposed to something that belongs in the Resource Kit (like the MIISWorkflow example).

MVExtension Code
So, below are some of the lines of code you'll need to add to your Metaverse rules extension project. The entire file is included below, but I wanted to call attention to the pieces of code you'll need to add to an existing project.

References and Imports
The only Imports line you'll need to add to your existing project (if it is not their already) is to add the reference to Regular Expressions.

Imports System.Text.RegularExpressions

Next, you will want to have six variables assigned. Whether or not you are doing this through an XML configuration file or hardcoded, you will need the following six variables assigned:

Public Shared strSyncToMA, strSyncFromMA, strProdConfigDN, strDevConfigDN, strProdDomainDN, strDevDomainDN As String

strSyncToMA = "SyncDevAD" ' The name of the ADMA we're syncing To
strSyncFromMA = "SyncProdAD" ' The name of the ADMA we're synching From
strProdConfigDN = "CN=Configuration,DC=fabrikam,DC=com"
strProdDomainDN = "DC=fabrikam,DC=com"
strDevConfigDN = "CN=Configuration,DC=fabrikam,DC=test"
strDevDomainDN = "DC=fabrikam,DC=test"

The next thing you will want is to call our function from the Provision sub:

Dim strObjectType As String = mventry.ObjectType.ToString
SyncProdToDEV(mventry, strObjectType)

Now we need to provide the functions themselves, but since they are too large to post here I will include the link to the file instead:

ADMA Exports
The ADMA exports are pretty straightforward - they are exported from fabrikam.com and fabrikam.test forests so you'll need to replace the credentials and partitition names with your own during the import process. However, before you proceed with importing these files, make sure you have imported the MVSchema.xml file first or the imports will fail.

So that's it! I hope you find some use for this and by all means tinker and expand!

Welcome to part two of the SyncProdToDev MIIS Solution. Let us briefly touch on what the business problem is that we're trying to solve.

The Business Problem
Perhaps we started out with a typical MIIS implementation; however in order to implement MIIS and connect to systems like AD we need something to test our rules extensions against. We touched on the issue of not having a test environment in place so we need to build one quickly and have the option to update it whenever we need to. That leads us to using MIIS to buildout our test environment for us by provisioning key object types from the production forest into our test forest. We also talked about different ways of accomplishing this and what our challegnes might be, but let us move on to the solution.

The Solution
Given that this is a blog and not a file server, I found myself challenged to provide the files necessary to complete this solution. I eventually had to purchase an account at Streamload to host them. Anyway, here are the MVSchema files you'll need to update your MIIS server:

So, it seems like on every project I start I always start with the same task - creating a copy of the production AD environment in a test lab. It's surprising how few customers actually have functioning test environments if they have one at all but MIIS makes it easy to duplicate the relevant parts of a working AD environment. First let us cover what we can and cannot synchronize between environments.

Fair Game
The following objects are ok to copy between the two environments:

• user objects - pretty easy, but we can't get the password here or the SID
• contact objects - easy, we do this with GALSync
• group objects - easy, MIIS will maintain the group memberships for us but we'll want to avoid System Groups or any special builtin group.
• organizationalUnit objects - easy, but we can't delete them if our source goes away (grr)
• site objects - yes, but we can't propagate renames for some reason
• subnet objects - ditto
• siteLink objects - ditto

While the first four are relatively easy, the last three require some additional attention for the following reasons:

• These objects are containers for other objects or are themselves part of parent container that must be created beforehand.
• Once these objects are created, we won't be able to rename them using csentry.DN or csentry.RDN as they are protected system objects.

This gets us the important stuff we'll need to simulate our production environment, so what is off limits?

Off Limits
The following are either not possible to synchronize due to their nature or not worth trying:

• Group Policy Objects - you might be clever enough to get the GPO objects to synch between domains, but don't forget that the object is only half; you also need the files that go with it. Plus you'd have to edit the objects and the files to sanitize the DNs.
• Delegated Permissions - you're welcome to try, but the AD MA can't see AD Access Control Lists
• Containers - you can certainly copy these objects but they are generally reserved for special areas of the domain so you're probably better off keeping these out of scope. I try to avoid anything "CN=" at the root to play it safe.
• Application objects - don't go trying to copy Exchange objects, it is certainly easier to just install Exchange in the test forest and call it good.
• Bi-directional Sync - since we're testing, we shouldn't be expecting to sync changes in our test environment back to our production environment because that would be crazy. I had to list it because someone will ask "Brad, what about bi-directional syncs?" If bi-directional synchronization of AD domains turns you on and you want to adapt this solution to accomplish that - be my guest.

Ok, so what is the challenge here?

The Challenge
So we can copy the relevant objects between forests, but the problem we are going to run into is translating the distinguished names between the forests. If we have ForestA (DC=foresta,DC=com) and ForestB (DC=forestb,DC=test) and both are single domain forests then we pretty much need to just replace all occurrences of ForestA's DN with that of ForestB's. But, what if ForestA has multiple domains, or better yet, multiple trees? That makes the problem of a simple .Replace much harder. This is where we're going to use Regular Expressions to solve this problem.

Now, unless we're collapsing multiple domains into one domain, we don't have to worry about the typical things like sAMAccountName uniqueness because it's already unique in the source. So, except for DN, we're pretty much copying like for like - pretty easy right?

We also have an issue of stepping on the same object types - so if you project everyone from ForestA as object type person and then provision them into ForestB, what happens when you need to now project from HR and join...you've got a mess.

The Messy Part
So, after you create your ADMAs to both forests and add all of the applicable object types, mappings and so on you're ready to go. But now you have complicated your test environment with stuff you don't want to bring over into production. Your server export will either contain MAs that you don't want or they will contain object types and attribute flows that you don't care about.

In order to solve the object type problem, we will certainly want to use our own object types. In the solution we will use:

• syncPerson
• syncContact
• syncGroup
• syncOrganizationalUnit
• site
• subnet
• siteLink
• siteLinkBridge
• plus all of the dependent object types I won't list here...

So that gets us around the project/join issue, but we need to address the others. Here are a few different scenarios I can think of using:

• Discrete Install of IIFP - we could use an entirely separate installation of IIFP (since we're only doing AD to AD) with just this solution and that way we wouldn't muddle the test cases, or
• Discrete Install of MIIS - same as above, but no added value here, or
• Same Install of MIIS/Same MAs - this is the one we probably want to avoid, using the same MAs we're developing to move into production to also synch our environments, or
• Same Install of MIIS/Separate MAs - this is probably the most logical, we're just going to build two completely separate MAs that only contain our synch information. The only hitch here is unless we use MVRouter, we will at least have a function in the MVExtension to do the provisioning of these objects which means you need to allow for the condition. That means you'll need to delete the two synch MAs if you're doing full server imports or not import them if you're doing each MA individually. That just leaves the extra schema attributes which you'll have to live with or go to the IIFP scenario.

Rules Extensions
Since DN is the only thing that needs to be altered and we only care about DN during Provisioning, the only extension code we need is going to be in Provisioning, so no MA extensions or advanced attribute flow (aww shucks!).

In part two we'll look at the code, schema and provide the MA exports - stay tuned!

I considered trying something like "free money" to get your attention, but with all of the scams going on these days it might quickly get filed in the bit-bucket, so I took the less dramatic approach. I wanted to lament about a problem that no one seems to be able to answer - why are there no companies out there making money by selling Extensible management Agents for MIIS? Allow me to put this into perspective.

Microsoft, as of Service Pack 1 has provided the foundation for building your own MAs for MIIS provided that you are versed in the APIs of the system/application you want to connect to.

Now most, if not all of the MIIS Engineers I have met are not principally developers, although they can code to some degree (some are obviously better than others), but tend to come more from systems background with generally more familiarity with Active Directory and Exchange than something like SAP, PeopleSoft, or Remedy. That being said, much of the really advanced stuff you'd want to use an XMA for is beyond my paltry developer skills at least and probably many others. This has a lot to do with the fact that we rarely have time to research and become fluent with a whole new API - it's not that we can't do it typically, but whenever something adds a week or three to a project in order to come up to speed and start testing then PMs start getting nervous and priorities begin to shift. So faced with a difficult connector and no current expertise on the API set and you end up with nothing. I mean, faced with the alternative of finding someone who knows some obscure API AND MIIS XMAs is pretty rare to impossible. Plus it certainly seems like SAP and PeopleSoft programmers don't have difficulty staying employed, which seems likely the more specialized the skill set required and the more niche the product. Somehow, someway, we need to be able to bridge this gap.

Now, someone out there is actually using these APIs, and I would dare to say that it is much easier to come up to speed on how to write an XMA than it is to learn the Remedy APIs (of which there are no books published on the subject). So, it should be obvious by now that there is certainly a need for custom MAs or at least specialty ones for popular systems. Now, Microsoft is steaming ahead with most of the big ones (SAP [currently in beta - sign in with your passport account and when prompted enter Invitation ID: SAP-G48Q-JQ4T] and PeopleSoft are due out in SP2) but it's the little ones that are the bear; however, I hear more and more people asking for OS/400 now. So, given the demand, why is there no supply?

I think in some ways, the XMA is as much a curse to the success of MIIS as it is a boon. If you think about it, Microsoft has an "easy out" by stating "if we don't make an MA for it, you can always write your own, because we are extensible." And they are correct, the XMA is very easy to extend, it's just understanding the other system which is the challenge.

Don't Be Fooled

So, you say, "what about products like BMC's Identity Management (formally OpenNetwork) or M-Tech's IDSync? Don't they provide connectors for MIIS to systems not supported out of the box?" Well, yes and no. You see, while these products do every bit of what they advertise, they do it by creating a connector to their product - which has all of the connectors to these other rare and magical systems that you can't quite talk to directly. I won't even go into how crazy it seems to purchase and implement an entirely separate (and potentially competing product) solution (plus licensing) just to connect to one or two systems. I mean, you really have to want that connectivity bad in order to sacrifice the entire value proposition Microsoft offers with MIIS. Not to mention needing another skillset to support the new product. But hey, you could just always write the XMA yourself right?

Attention ISVs - Your Services Are Required

Given your focus and staff of able developers, might you consider helping the growing base of MIIS deployments by directing some time to solving a few of these harder to connect to systems? And if you didn't get too greedy and try to license the darn thing by the user then you could actually stand to make a few bucks.

So, while Microsoft seems to be making ample progress on SAP, PeopleSoft, TopSecret and ACF2 that most people will wait for those to come out, the following are so far out or are not currently being considered that they should be considered fair game:

• OS/400
• Infinium on OS/400
• BMC Remedy
• Unix OS (RedHat, Solaris, AIX, HP-UX, etc...)

Click the comment link below and add your own to the pile!

The University of Advancing Technology (UAT) is sponsering a free one-day event to promote software development in the Phoenix area. There are some really interesting topics here and many still need someone to volunteer to teach. If you are interested in attending or think you can teach one of the topics, please register now!

Keith Brown has an excellent post this morning in the MSDN Flash newsletter regarding InfoCard. Ever since Pamela Dingle's presentation at DEC this year I've been keeping an eye on this technology.

InfoCard distinguishes itself from Microsoft Passport in many ways, but among the most important are:

• "user centric" identity management - you choose which attributes of your identity are sent to the identity provider and always have the ability to "opt out"
• Identity information is not stored on your PC or in a central repository, it is stored and managed by the identity provider

For more in depth information on InfoCards, see Kim Cameron's Identity Blog.

So, buried in the Microsoft Partner newsletter today was an interesting blog from Tim Landgrave regarding Identity Management and MIIS. There were some interesting statistics here quoted from PWC/Meta:

• Enterprise users spend an average of 16 minutes per day logging in and authenticating into the systems necessary to do their work. This equates to 2,666 hours, or 1.3 FTEs per day.
• IT staff spend an average of 54,180 hours per year managing users, user stores, credentials, and authorizations.
• 45% of all help-desk calls are for password resets. Without automation, an enterprise spends an average of US$1.9 million per year just to handle these calls.
• 38% of external users and 75% of internal users have multiple identities contained in multiple internal systems. Consolidation of these user stores would reduce administration time by at least 1,236 hours per year.

This is always good information to have lying around, although I'd really like to get the stats out of Chris Macaulay's presentation at DEC 2006 which had an expanded set of statistics from Microsoft's own internal helpdesk.

Thanks to Tim Landgrave for posting this!