I would like, if I may, to take you on a
: Where did directory trees come from?
This isn't about flowers and bees or our green friends, who missed the evolutionary advantage to
emit WIFI signals
, but the constructs we rely on for authentication and keeping the network in order, in other words:
In the beginning there was
and StreetTalk. While they are gone, they are
. Other than the Wikipedia article I recall, that it needed almost 300k of memory (probably with all services loaded) which wasn't good when 640k was the limit.
At that time it was the only system offering directory services as a tree. Its demise was triggered by Banyan's late awakening to the fact, that requiring a propriety OS to run a directory service will lead to a collapse of hardware support.
Along came Novell's
(ca. 20 years ago). Originally called NDS (Novell Directory Services) it suffered from teething problems giving room for other entrants. Initially it required a
Novell Netware 4.x
server and almost missed the boat in TCP/IP support.
Similar to VINES, the propriety OS became an issue and only in 2003 eDirectory became multi-platform. Novell had quite some ideas: HTTP based file sharing (
), access via multiple protocols (via
) and storing
network object, relations and access rights.
Embrace, Extend and Extinguish
However the rise of Windows NT made way for the latest entrant:
from Microsoft. Using its marketing muscles and aptitude for easy to use interfaces, Microsoft swept the directory market and
. While loosely based on Open Standards, Microsoft messed with the Kerberos implementation using their successful
embrace, extend and extinguish
Can you see the forest through the trees?
The biggest innovation in Active Directory is the concept of a
. Vines and eDirectory only use a single tree. When you ask around for opinions about the feature, you will find, that any consultant paid by the hour will love it. It introduces complexity and endless hours of configuration. IT managers who know their stuff loath it. So what happened?
The leaky abstraction
IMHO this is a case of
. VINES stored its data in some ISAM file, Netware eDirectory uses
(I thought they used
, but that's a minor detail here), while AD uses the
engine. Originally shared with MS Access, it got forked into
instead of the more robust (?) SQL server.
Despite the impressive numbers in the specs JET didn't scale as well as expected, so instead of fixing it, large trees were broken down into smaller trees and regrouped into a forest (Wearing my
for this claim).
So the storage model
into the product capabilities. Anyway storing
extra (which is the whole idea of a directory service) is a perilous undertaking, once added to the schema, it
never will get out
. This led to
and a whole cottage industry of
Buying a product is not a strategy
So you can
(and don't argue,
I heard them all before
) or give it a really hard thought:
- What do I want to accomplish?
- Am I comfortable with Jet Blue?
- How easy can I take the dependency on a single vendor or do I want to be able to select from a rich heritage?
- Is my long term strategy better served with open standards?
For user management and authentication
(for your own users) or
(for others) might do a better job. AD doesn't do much for end-point management without
, so your are not bound by that. The list goes on.