Lightweight Directory Access Protocol (LDAP) is the last remaining remnant of the OSI layer 7 application layer from the 1980s. Unfortunately, it is also one of the least functional components.
In the early 1980's, with the open standard OSI X.500 directory came a query protocol, Directory Access Protocol (DAP). However, the dominant PCs of the day were x386-based PCs. These PCs had a requirement that no matter how much memory was on the server, applications had to run in 640 KB of convention memory in order for DOS to access them. DAP was larger than 640 KB, so a "lightweight" version of DAP was created: LDAP. In dumbing down DAP, certain extras were eliminated, including encrypted transfer, sorting, paged results and others.
Flash forward to today.
Every enterprise has proprietary enterprise directories. However, while the X.500 directory went the way of the dinosaur, LDAP has remained the only non-proprietary query protocol for these directories. LDAP is used to create queries to a number of disparate repositories but has never been expanded to include all the features that were stripped out of it (a few years ago there was an effort to update LDAP, the Lightweight Directory Update Protocol (LDUP), but it never caught on).
Since LDAP doesn't provide its own security, deployments usually use SSL between the client and the supplier repository to protect the data. When SSL is unavailable, or the data doesn't need to be encrypted, the data is sent using LDAP in clear text format. To ensure the information is complete and hasn't been tampered with when sent in clear text, the repository can "sign" the LDAP packet. By signing packets, the recipient's system can check the LDAP signature to ensure it arrived from the repository it was supposed to come from and that the content is only the original results (verified through a checksum).
Since directory standards no longer exist, each LDAP configuration is different (one of the hopes of the X.500 directory was to preclude this from happening by creating standardized configuration, replication, query and storage). Assuming a Microsoft deployment, there's a Microsoft article on how to configure LDAP signing for the repository and client. If you don't have a Microsoft system, you can still use the article as a guide for the general steps. Remember, there are no standard directory configurations anymore.
(Author's note: I worked on the original X.500, DAP, and LDAP specifications at the National Institute of Standards and Technology (NIST) in Washington D.C. and was sorry to see X.500 and DAP go.)
For more information:
- Interested in LDAP? Read one expert's predictions for the furture of LDAP.
- Learn about the pros and cons of using stand-alone authentication that is not AD-based.
Dig deeper on Active Directory and LDAP Security
Related Q&A from Randall Gamby, Contributor
Is your remote desktop access software really secure? Randall Gamby offers advice for conducting a remote access audit to validate security.continue reading
Expert Randall Gamby discusses risk-based authentication, and whether that type of user identification system is right for the enterprise.continue reading
Expert Randall Gamby discusses various types of single sign-on, specifically the approaches of Ping Identity's SSO and Symplified SSO.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.