Is AD really the dominant Identity Store out there?
James McGovern has challenged my position that applications should not be written to go directly against AD. And he got the backing of Jackson Shaw in this argument. James says:
If pretty much every Fortune 500 enterprise has Active Directory, why should any of them consider yet another product?
Martin (no last name) left a comment on my post that included the following point:
AD is the directory in just about every organization running Windows. Let me see. What does that work out to be? 99% of them out there?
Here is my point. Martin says “AD is the directory…”. I say that “AD is a directory…”, and that too because Windows forced it on those enterprises, not because of their Identity Management needs. Yes, almost all the Fortune 500 have AD, but are they using it as an Identity Store, or as a Windows Account Store (which is very different)?
Obviously our opinions are shaped by our experiences. My experiences, coming from the provisioning world, would be different from James or Jackson’s. In a lot of the projects we were involved in, AD was a downstream repository, a target of the provisioning system and not the source of identity data. That was usually an HR system or, more often, a Sun directory. Most of the time, the provisioning system would push the bare minimum attributes to AD to enable the Windows environment to work.
In a few deployments, we actually were responsible for populating a directory with identity data so it could act as an identity store for other applications. Most of the time, that directory was a Sun directory. So while AD may be more widely deployed, I would contend that based on my small but relevant sample size, Sun is dominant in the Identity Store business. And that is really what we are talking about here – what should applications be going to for their identity data. Sure, AD being more widely deployed positions it to be used as an identity store, but that is seldom the case, primarily because AD administrators often closely guard their environments and do not want it overloaded with data or consuming applications.
Again, when James asks about practical futures, my hope is that the future eliminates all such arguments about directories and metadirectories by having applications code against Identity Services APIs, like the IGF APIs or the Higgins IdAS APIs. James asked what we at Oracle are doing to help application developers. Clayton mentioned our work on the IGF, and the APIs that are being defined as part of it that eliminate the need for application developers to have to worry about LDAP, instead providing simple APIs that use a provider model to get the data from where it needs to. And I have joined the Burton Groups Identity Services Working Group (now that it is open to vendors), where I hope to work with the community to help advance the concepts and reality of Identity Services. Hopefully, soon, this will be a question that nobody will need to ask any more.
By the way, why is it that architectural purists don’t ask when Microsoft will make it possible for Windows environments to work against any directory and not just AD, but Oracle Applications must support directories other than OID? In the end, both Microsoft and Oracle are wrong to push proprietary stores into deployments, contributing to the mess we have.
About The Author
OK – so MS *forced* the organizations to use AD.
The freedom of choice is not an acceptable answer for why a company should add a second directory and that is the essence of your argument.
AD is a perfectly acceptable directory.
What deficiency or defect exists in AD that *requires* a company to add a second directory? None.
Directories are directories are directories. They all have some differences that makes one incrementally better in one metric or another over the others and they all have warts.
The deficiencies in AD are well documented, so I won’t go into them. Just do a Google search on the topic. And once you get past simple attribute management, each directory introduces some value added features that become differentiators when talking about identity store deployments.
I am not saying enterprises must get a second directory, only that they should have their choice of directory. Again, going back to my experience, the fact that companies were choosing directories other than AD for their projects, after careful consideration and despite already having AD in house, means that the choice is necessary. OID, for instance, has a much stronger base in the telco industry due to performance benefits it has over other directories.
I’m not seeing where anyone is saying the AD LAN should be the same as the AD identity store. Microsoft doesn’t say that. I think the point is simply that AD “can” be an identity store, just as Novell, Sun, Oracle directories “can” be an identity store, and since many organization already have AD and AD expertise, it may make sense for them to deploy AD as an identity store. Or ADAM…
James
http://duckdown.blogspot.com/2008/07/active-directory-20.html
Where does he get that wonderful identity data?
Finally getting around to participating in the latest stream of blog postings following up the “meta-directory is dead” and “daddy, does Active Directory grow on trees?” discussions… Nishant has already addressed some of these comments in his post fr…
I can see how you may not want to use AD as “the” identity store, especially when you have multiple domains/forests, decentralized management, etc. If not architected correctly, it can be unwieldy for applications. This is limitation of the architect, not the technology itself though.
Heck, many applications still don’t “understand” the concept of multiple Domains/NCs, and want to only use a single partition to connect too relying only on a unique username.
But what if you have multiple HR systems as well? I hope the majority of enterprises have a single authoritative source for identity data from an HR unit.
You will end up with some concept of an aggregated identity store (either through a Vdir or Metadirectory product), to which point if you go the directory route, it is a “Directory is a directory is a directory”
Now why would I choose to use OID as my aggregated identity store over ADLDS when I have experience with managging ADDS already? It might not be a hard sell to add an additional directory to aggregate data, but it would be a harder sell to switch technologies/vendors providing that directory.
An ADLDS instance with aggregated identity information, and proxy bind objects goes a long way before having to bring in another directory product.
Also many places who grew up on NT4 Domains may not have understood that AD is more than just a complex NT4 domain with usernames and basic information, and are not using it for the underlying directory metadata. I can see how a vendor could come in and sell them a “solution” they already have, but just don’t understand.
Jef
Martin said:
AD is a perfectly acceptable directory.
What deficiency or defect exists in AD that *requires* a company to add a second directory?
Answer: Platform
If allow guest access or partner/contractor access onto your network, you don’t want to add these people to the corp. AD do you? A 2nd identity store could be useful and alleviate management and resource headaches. I’m not sure you’d need a full blow 2nd AD though.