A short history of directory trees

I would like, if I may, to take you on a strange journey: 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: your directory.

Banyan VINES

In the beginning there was Banyan VINES and StreetTalk. While they are gone, they are fondly remembered. 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.

Novell eDirectory

Along came Novell's eDirectory (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 ( webDAV), access via multiple protocols (via LDAP, DSML, SOAP, ODBC, JDBC, JNDI, and ADSI) and storing any information about any network object, relations and access rights.

Embrace, Extend and Extinguish

However the rise of Windows NT made way for the latest entrant: Active Directory from Microsoft. Using its marketing muscles and aptitude for easy to use interfaces, Microsoft swept the directory market and most followed. While loosely based on Open Standards, Microsoft messed with the Kerberos implementation using their successful embrace, extend and extinguish pattern.

Can you see the forest through the trees?

The biggest innovation in Active Directory is the concept of a Directory Forest. 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 Leaky abstraction. VINES stored its data in some ISAM file, Netware eDirectory uses FLAIM (I thought they used Btrieve, but that's a minor detail here), while AD uses the JET engine. Originally shared with MS Access, it got forked into JET Blue 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 asbestos underwear for this claim).
So the storage model leaked into the product capabilities. Anyway storing anything 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 fun and entertainment and a whole cottage industry of tool vendors.

Buying a product is not a strategy

So you can follow mainstream (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 LDAP (for your own users) or OAuth and/or SAML (for others) might do a better job. AD doesn't do much for end-point management without additional software, so your are not bound by that. The list goes on.
Happy musing!