To AD or not to AD

Ashraf Motiwala has called me out for saying that the way applications are supporting AD directly as the identity store is by using Virtual Directory, both in a comment on my post, and on his blog. I guess in my enthusiasm to get a response out to Matt’s post, I wasn’t careful enough about my words and mis-stated what I was trying to say. But that’s the beauty of the blogosphere for you, there’s always someone around to correct you (slap you around a little). And at least now I know that my feeds are working post-migration 🙂

I did not in any way mean to imply that the majority of applications that are coming out with support for AD do so using a Virtual Directory. What I was actually trying to say (poorly in the end) was this: “And how are more applications looking to support AD anyway? A lot of that has to do with the emergence of Virtual Directory solutions”. Let me talk about this separately in the context of Custom and COTS applications.

There are a large number of custom enterprise applications that support LDAP that were tied to a particular directory, usually something non-AD (most application developers would develop against free LDAP systems like Sun). This was a reality that proved to be a boon for provisioning vendors (like us), but a curse for provisioning implementers, as we then played the role of populating these non-AD directories from the main AD infrastructure. A lot of those same applications are now looking to support AD in addition to (or in place of) what they already supported OOTB, and from what I see, they are doing so by shifting to a Virtual Directory based approach. This shift seems to be specific to custom in-house applications (where Virtual Directory lock-in, a great point raised by Jeff Bohren, is not considered as big of an issue) and is prevalent in heterogeneous directory environments, where AD may be dominant, but is not the only directory available. Virtual Directory provides a nice abstraction to avoid having to deal with the heterogeneity of the environment, and allows consolidation of the spread out data into a single view. This is not really a concern in pure AD shops, but there are few large enterprises that are purely AD.

As for COTS application vendors, I mentioned what Oracle is doing with regards to their strategy on how to support multiple directories. And from talking to a few other application vendors, they are also tired of having to maintain connectors for every single major directory out there. This is one of the main reasons why there is an on-going effort to see if Oracle Virtual Directory can be made an embedded component (as opposed to its own server), something that is part of the middleware stack, so that it can act as a “directory connector” service in the application environment, freeing up applications from having to code against the idiosyncrasies of the individual directories. It is also a reason why so much emphasis is being put on some of the standardization efforts in Higgins and IGF.

Now, this is not to say that a lot of applications are not being built to go directly against AD, with little regard for other directories. All I meant was that from my vantage point (and it may be a skewed one because we are Oracle, so I am more than happy to have people contradict me or correct me on this), a lot of people are looking to support AD without getting locked into AD, and that is driving demand for both OVD and other alternatives.

James asked some good questions with regards to what Oracle is looking to do to help resolve this issue. I’ll get to those in my next post.

Update: Clayton has chimed in with some articulate and well-thought through responses, complete with examples, to this whole discussion. I should have just waited for him to come back and take this up instead of sticking my little neck out there 🙂