February 18, 2012 1 Comment
LDAP – Lightweight Directory Access Prorocol
LDAP is characterised as a ‘write-once-read-many-times’ service. That is to say, the type of data that would normally be stored in an LDAP service would not be expected to change on every access. To illustrate: LDAP would NOT be suitable for maintaining banking transaction records since, by their nature, they change on every access (transaction). LDAP would, however, be eminently suitable for maintaining details of the bank branches, hours of opening, employees etc..
What is it?
Why is it used?
When is it used?
How is it used?
The nice thing about the Internet is that there’s so much information on it. The bad thing about the Internet is that there’s so much information on it.
This might seem a little cliched, but it’s true – the Web is rich in information, but poor in the tools needed to index and search it. Google’s (http://www.google.com/) doing a great job of fixing this problem, but it’s still limited largely to collating and indexing published content. If, for example, you’re looking for the email address of Sam Jones, who you know works somewhere in Long Beach with Rough Rubber Shoes, or the telephone number of your great-grand-uncle Josh, who moved to New York a few years back and was never heard from again, you’re outta luck – Google can’t help you, and neither can any of the other search engines out there.
What would be ideal in this situation is an Internet version of your local telephone directory, a public database of users and their affiliations, locations and contact information that you could query at the click of a button. Something that made it possible to easily search for resources (users, computers, businesses) by different attributes, that was universally accessible, and that was versatile enough to be used for different applications.
Something like LDAP. Let’s start with the basics: what the heck is LDAP anyhoo?
The acronym LDAP stands for Lightweight Directory Access Protocol, which, according to the official specification at http://www.ietf.org/rfc/rfc2251.txt, is a protocol “designed to provide access to the X.500 Directory while not incurring the resource requirements of the Directory Access Protocol (DAP) […] specifically targeted at simple management applications and browser applications that provide simple read/write interactive access to the X.500 Directory, and is intended to be a complement to the DAP itself”.
Yup, it didn’t make sense to me either.
Before you can understand LDAP, you need to first understand what a “directory service” is. A directory service is exactly what it sounds like – a publicly available database of structured information. The most common example of a directory service is your local Yellow Pages – it contains names, addresses and contact numbers of different businesses, structured by business category, all indexed in a manner that is easily browseable or searchable.
Like ice-cream, directory services come in many flavours. They may be local to a specific organization (the corporate phone book) or more global in scope (a countrywide Yellow Pages). They can contain different types of information, ranging from employee names, phone numbers and email addresses to domain names and their corresponding IP addresses They can exist in different forms and at different locations, either as a single electronic database within an organization’s internal network or as a series of inter-connected databases existing at different geographical locations on a corporate extranet or the global Internet. Despite these differences, however, they all share certain common attributes: structured information, powerful browsing and search capabilities, and – in the case of distributed directories – inter-cooperation between the different pieces of the database.
Now, obviously, organizing information neatly in a directory is only part of the puzzle – in order for it to be useful, you need a way to get it out. If you’re using the local phone book, getting information out it as simple as flipping to the index, locating the category of interest, and opening it to the appropriate page. If you’re using an electronic, globally distributed directory service, however, you need something a little more sophisticated.
That’s where LDAP comes in. Put very simply, LDAP is a protocol designed to allow quick, efficient searches of directory services. Built around Internet technologies, LDAP makes it possible to easily update and query directory services over standard TCP/IP connections, and includes a host of powerful features, including security, access control, data replication and support for Unicode.
LDAP is based largely on DAP, the Directory Access Protocol, which was designed for communication between directory servers and clients compliant to the X.500 standard. DAP is, however, fairly complex to implement and use, and is not suitable for the Web; LDAP is a simpler, faster alternative offering much of the same basic functionality without the performance overhead and deployment difficulties of DAP.
Since LDAP is built for a networked world, it is based on a client-server model. The system consists of one (or more) LDAP servers, which host the public directory service, and multiple clients, which connect to the server to perform queries and retrieve results. LDAP clients are today built into most common address book applications, including email clients like Microsoft Outlook and Qualcomm Eudora; however, since LDAP-compliant directories can store a diverse range of data (not just names and phone numbers), LDAP clients are also increasingly making an appearance in other applications.
A corporate directory is a database of people, network resources, organizations, and so forth. The corporate database probably holds not just phone numbers, but also other information like email addresses, employee and department numbers, and application configuration data. The corporate directory is managed by a directory server, which takes requests from client applications and serves them back directory data from the database.LDAP, Lightweight Directory Access Protocol, provides a standard language that directory client applications and directory servers use to communicate with one another about data in directories. LDAP applications can search, add, delete and modify directory data. LDAP is a lightweight version of the earlier DAP, Directory Access Protocol, used by the International Organization for Standardization X.500 standard. DAP gives any application access to the directory through an extensible and robust information framework, but at a high administrative cost. DAP does not use the Internet standard TCP/IP protocol, has complicated directory naming conventions, and generally requires a big investment. LDAP preserves most features of DAP at lower cost. LDAP uses an open directory access protocol running over TCP/IP and uses simplified encoding methods. LDAP retains the X.500 standard data model and can support millions of entries for a comparatively modest investment in hardware and network infrastructure.LDAP directories differ from relational databases. In LDAP, you do not look data up in tables. Instead, you look data up in trees, similar to the tree you get if you diagram the contents of a file system. The data is not in rows and columns, but in what are called entries. These entries are much like entries in the phone book. Entries may even actually contain phone numbers. Here is a text representation of an LDAP entry.
dn: uid=bjensen, ou=People, dc=example,dc=com cn: Barbara Jensen cn: Babs Jensen sn: Jensen givenname: Barbara objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson ou: Product Development ou: People l: Cupertino uid: bjensen mail: firstname.lastname@example.org telephonenumber: +1 408 555 1862 facsimiletelephonenumber: +1 408 555 1992 roomnumber: 0209 userpassword: hifalutin
An LDAP entry is composed of attributes and their values. At the outset of the text representation you see the DN, Distinguished Name, uid=bjensen, ou=People, dc=example,dc=com. The DN is a distinguished name, because it distinguishes the entry from all others in the directory. You also see attributes like CN, Common Name, which takes values Barbara Jensen and Babs Jensen. You further see attributes like SN, surname, which takes the value Jensen, and mail, which takes the value email@example.com.
You also see some objectClass attribute values. The objectClass attribute tells you what other attribute types the entry can have. Object class definitions are found in directory schema. Schema specify all the known object classes and attribute types available for entries in the directory. You can add schema definitions to LDAP directories, making the LDAP entries easily extensible.
When you want to look up something in a directory, you typically know the values of one of the attributes. By analogy, if you want to look up a phone number, you already know the name of the person or organization whose telephone number you want. If you are looking up a phone number, you also probably have some idea where the person or organization is located. The same is the case for LDAP directories. You typically need to have some idea where the entry is located.
For example, assume you want to look up Barbara Jensen’s phone number in the LDAP directory holding the entry shown previously. You need to know one of the attributes. In this case, you know Barbara’s name. You also need to know approximately where her entry is located. If you know that she is in the directory at Example.com, and that the root of their tree starts at dc=example,dc=com, that is enough.
There are GUI tools out there for LDAP lookups, but many systems also have a command called ldapsearch. You guessed it, ldapsearch is for searching LDAP directories. Here is an ldapsearch command that searches the entries under dc=example,dc=com for entries having common name Barbara Jensen.
$ ldapsearch -b dc=example,dc=com "(cn=Barbara Jensen)"
The argument to the -b option is the base DN for the search. By default, the ldapsearch command searches through all the entries in the tree below the base DN. The "(cn=Barbara Jensen)" is called the filter, because it tells me the criteria for filtering through the entries found under the base DN. If you have set everything up correctly, your search returns something very much like the entry shown above, except that you almost surely will not see the user password attribute and its value. You can also narrow the search results to see only the DN of the entry and the telephone number. You do this by adding the attribute or attributes you want returned after the filter.
$ ldapsearch -b dc=example,dc=com "(cn=Barbara Jensen)" telephoneNumber
If everything works as expected, this search returns a partial entry.
dn: uid=bjensen, ou=People, dc=example,dc=com telephonenumber: +1 408 555 1862
More Info : LDAP – An Introduction to LDAP