All that you know about Lightweight Directory Access Protocol (LDAP) is wrong. From its inception to perceived usefulness, and ultimately, until the marketing department got a hold of it, LDAP has grown. It started as a useful protocol and a data structuring methodology (known by only a few), and became the latest and greatest way to synergize your action items and find parity with your eMarketing growth plan.

What does this mean? Hopefully your answer is the same as mine—nothing. The importance and growth of LDAP should be based on how the protocol has adapted in the past, and how we keep on innovating and adapting it as technology grows. Unfortunately for us, the marketing department has already taken a hold of LDAP, eaten it up, and—if we are not careful—it will spit it out.

The origins of LDAP

LDAP was first implemented at the University of Michigan in 1992 as a way of creating an interface to DAP over TCP/IP. This eventually evolved into a stand-alone system utilizing data structures based on types stemming from X.500. Over time, the popularity of OSI waned and TCP/IP became the de facto standard accepted for networking. One of the reasons for the failure of OSI (and its directory solution—DAP) was the complexity of the data definition and the infrastructure required to use it. No flexibility was given in any of the OSI standards and it became extremely cumbersome to deploy.

The OpenLDAP web site

With OSI’s failure and TCP/IP’s acceptance, the LDAP “community” (which at the time consisted of college age engineers meeting over pizza and beer) became more ambitious and tried to invade the space of directories and started to innovate instead of just following X.500’s lead. Following the original RFC’s for X.500 and LDAP, it can be seen that while X.500 was trying to solve problems that didn’t exist (i.e. how to replace yp, how to create a more structured information standard that was even more painful to implement), LDAP was clarifying how to access information and proposing formats for URL standardization and search filters.

**Following the original RFC’s for X.500 and LDAP, it can be seen that while X.500 was trying to solve problems that didn’t exist, LDAP was clarifying how to access information and proposing formats for URL standardization and search filters**

Because of its simplicity, ease of implementation, availability, and a little bit of luck, LDAP became a good way of centralizing information. LDAP provided an easy solution where synchronization scripts and custom code were used to keep information, on large systems, consistent. Within a relatively short time, email systems were relying on LDAP as the single authoritative source. Authentication systems were no longer relying on their own customized solutions and flat files. Netscape looked to LDAP to provide the central repository for their initial suite of products.

All of a sudden, LDAP was the quick and easy solution to many of the problems that system administrators faced. The community, large and growing, was updating standards in order to help solve the problems that the users were facing. Once other vendors were replacing their back-end databases with LDAP, it was obvious that this little experiment had finally gained acceptance.

If it ain’t broke, don’t fix it

One can easily conclude that the success of LDAP can be attributed to how fast technology evolved during the latter part of the 20th century and the general laziness of the information technology community. While new products, solutions, ideas and toys where becoming available, it was too difficult (and too expensive) to implement a database (such as Oracle) for storing profile information for all of a system’s users. It was equally frustrating, migrating flat files across different systems, which required similar information. Deploying an LDAP directory didn’t require much in the way of an investment of time. It could also be used by some of the new products that were being released. One LDAP directory provided the same authentication and profile information for all of the new toys that system administrators wanted to experiment with. So if it didn’t live up to their expectations, only hours were wasted (instead of the resources required to deploy an instance of Oracle).

The site LDAPGURU.COM is helping to provide the right LDAP information