Does your application support ADAM, Jabba?

OK, I recently posted asking the question "Does your application support AD?" and James McGovern was kind enough to comment on that post over at his blog by asking a follow-on question regarding support for ADAM...

Jackson Shaw asks the most wonderful question of software vendors. The funny thing is that he should have also asked this about ADAM. Do you know how many identity managements support Active Directory but not specifically ADAM? Likewise, many of the ECM vendors will say that they support Active Directory but for authentication. They will of course require you to copy the user store locally which is fugly. The real question is why aren't software vendors writing better directory-enabled code? Us customers desire it and many of us demand it yet it still doesn't happen...

James is quite right. I didn't ask about ADAM and I should have. ADAM was designed to be a viral product. I mean viral in a good way, not in the bad way. In other words, a product that could be easily installed by anyone and didn't require a committee to say "Sure, go ahead and try out that new directory service" and from that perspective it has been wildly successful.

Every customer meeting I go to always starts with a standard series of questions that I have just to help me maintain some statistics like...

• What OS do you run your domain controllers on?


• 32-bit? 64-bit?


• When do you think you'll go to Windows Server 2008?


• etc, and I *always* have this one:


• Looking at, using, testing ADAM and if so, what are the specifics?

Not surprisingly, most customers are doing something with it. In fact, some customers are running >10 million users in ADAM for customer web-access and it frightens me that they don't have comprehensive recovery, audit and monitoring plans. Yes, this too is fugly.

So vendors, what are your plans? Within Quest I have dictated - kind of like Jabba the Hut - that all of our products treat AD and ADAM the same - if we support AD then we must support ADAM. I still have a bit of work to do there but we've got that support in a number of products already and more are coming.

Note to ADAM users: Ah, if it is a directory it is probably doing something critical. You might want to consider investing in backup, monitoring and audit tools. LDP.EXE is not the only tool you need...

IdM vendors not supporting Exchange 2007?!

There are some storm clouds on the horizon that I don't think most people have seen yet and it will be interesting to see how the identity management vendors weather it...

Most identity management implementations include provisioning/de-provisioning of mailboxes and updating mailbox related information like distribution lists. In today's world, most mailboxes are probably Microsoft Exchange-based. If that's you, read on. If not, the bad weather is going to miss you entirely.

In Exchange 2000 and Exchange 2003 vendors relied on the "Recipient Update Service" - RUS - to interact with Active Directory. This made it easy to create, read, update and delete identity information for Exchange via Active Directory and LDAP.

In Exchange 2007, RUS is no more. RUS has been replaced by Exchange Management Shell cmdlets. The key word in that last sentence is "cmdlets". What the heck is a cmdlet?

A cmdlet is a command implemented by deriving a class from one of two specialized Windows PowerShell base classes --Microsoft.

What Microsoft has done in Exchange 2007 is move certain functionality to the Exchange Management Shell. Some of the functionality that has been moved to the Exchange Management Shell includes:

• Mailbox creation (create mailbox, mail enable an Active Directory user)


• Mailbox management (enable/disable mailbox, set mailbox attribute)


• Distribution group management (set, enable, disable, add/delete members

And "moved" means that it is no longer possible in an Exchange 2007 environment to use Active Directory and LDAP to expose this functionality. What does that mean?

If your identity management provider does not update their product(s) to use PowerShell then they will cease to be able to create, delete or modify Exchange users or distribution lists. How serious of an issue will this be for you?

I've been trolling around looking to see which identity vendors have specifically announced support for Exchange 2007 I can't find anyone. Through Quest's ActiveRoles product we support all of these capabilites because we've built in support for PowerShell. When I checked some of the IDM vendors sites here's what I found:

• IBM Tivoli Identity Manager 4.6: "Use the Active Directory connector" - When I checked their documentation they mention how the AD connector is used to set various Exchange attributes and for provisioning/deprovisioning mailboxes but there is no specific mention of Exchange 2007 support. My guess: IBM's TIM does not support Exchange 2007. My August posting to the Tivoli User Forum resulted in no responses - go figure.


• Sun Java System Identity Manager 7.0: "Microsoft Exchange 2000 and 2003 are managed through the Microsoft Windows Active Directory 2000 and 2003 resources" - My guess: Sun's product does not support Exchange 2007. In fact, if you check out this post on their developer forum you'll see how one customer had to debug PowerShell scripts themselves.


• Microsoft's Identity Lifecycle Manager 2007 (aka MIIS): This is the one solution that you'd expect to support provisioning Exchange 2007 mailboxes but it doesn't! The ILM 2007 FAQ does not list support for Exchange 2007.

Now this isn't the end of the world yet - as I said, the storm clouds are on the horizon - because this issue will only be manifested in a pure Exchange 2007 environment. Most of us are probably going to run a mixed environment for a period of time. However, better to be forewarned than have your hair on fire, your auditor's hair on fire and your boss' hair on fire, because provisioning/de-provisioning no longer works!

Start asking your IdM vendor about their plans to support Exchange 2007 now.

Quest Software
PowerShell
Exchange
identity management

Connecting ILM 2007 with SharePoint Services

Alex Tcherniakhovski over at Microsoft has blogged on how to connect ILM 2007 with SharePoint Services. Alex is a great resource around ILM (and even Quest's ActiveRoles Server). Here's his post...

In this blog I explore the possibilities of using information stored in SharePoint Services V3.0 lists to drive provisioning processes (specifically integration with Active Directory). The idea behind this approach is to merge provisioning and synchronization capabilities of ILM with collaboration and workflow components of SharePoint Services 3.0.

Please, follow this link for a complete walkthrough.

This is my second posting on this subject. In my first post “Adding workflow components into your MIIS solutions” I examined the scenario of integration of ILM with SharePoint InfoPath Libraries. Both solutions have similar goals: to utilize workflow capabilities of WSS 3.0 and to propagate information stored in SharePoint throughout the enterprise. At the same time the underlying extensible management agents utilize different technologies to accomplish the integration with WSS 3.0. The connector for InfoPath libraries utilizes Microsoft.SharePoint.dll and the connector for SharePoint Lists leverages SharePoint Web Services. Since Microsoft.SharePoint.dll can only be utilized on the same server where WSS is running, the first solution is ideal for scenarios where Workflow needs to be added to ILM provisioning processes (in other words MIIS and WSS need to be running on the same box), also InfoPath forms provide richer capabilities to workflow (ex. Digital signatures, Role based views, data validation, etc). The List Connector, on the other hand, uses SharePoint Web Services; therefore MIIS and WSS could be running on different servers, this connector is ideal for scenarios where extracting employee information from WSS is required. I am hoping one day to combine those two connectors into one, so that we don’t have be concerned whether the data resides in a list or a InfoPath library. For now depending on what you are trying to accomplish you will have to choose the appropriate solution.

Additional Links:

Walkthrough: How to build an extensible management agent for MIIS
Adding workflow components into your MIIS solutions

Technorati Tags:
identity management, ILM, Microsoft, MIIS

Happy Birthday Kim!

Kim's Birthday Party

August 31st was Kim Cameron's birthday. Yours truly got to cook the "meat blob" that was served along with a wonderful platter of Mediterranean halibut. Ian, Kim's brother and his wife came down from Vancouver to partake in the festivities. I hadn't seen Ian in years so it was great to catch up with him.

Below is a picture of Jennifer Wu, Kim and myself enjoying some of Jennifer's Chinese dumplings. The three of us worked together at ZOOMIT. Jennifer was responsible for the directory synchronization and metadirectory engine and moved to Washington with the rest of us after the acquisition of ZOOMIT by Microsoft. She's moved over to work on the "Indigo" team now.

As usual the food was awesome, the wine was great and the company was exceptional.

Technorati Tags:
Kim Cameron, Microsoft, Zoomit