Novell Home

An Introduction to LDAP: Part 1-LDAP Primer

Novell Cool Solutions: Feature
By Kirk Coombs

Digg This - Slashdot This

Posted: 21 Jun 2005
 

Applies to

  • SUSE Linux Enterprise Server


This is the first article in a two-article series which explains LDAP directories and their usage. Part 1 is a simple primer to bring users who have no experience with LDAP up to speed with the basics. Part 2 gives a practical example of how to use LDAP in a multi-platform, multi-user environment. It explains how to use a SLES server running LDAP and Samba to act as a user authentication and file server for both Linux and Windows workstations. Readers who already have a familiarity with LDAP can probably skip to Part 2.


What is LDAP?


LDAP stands for Lightweight Directory Access Protocol. LDAP is a protocol which provides access to a compliant directory via TCP/IP. The strengths of LDAP-compliant directories include speed, simplicity, and the ability to be replicated and distributed across several servers. A LDAP directory can be used to store a great deal of information: from user login credentials to company telephone directories.


LDAP was created as a less complicated implementation of the Directory Access Protocol (DAP), and is based on the OSI X.500 standard. These standards establish directories as being hierarchical---representing the structure of an organization. There are many directories that support the LDAP protocol, each with their own benefits and drawbacks. Examples include openLDAP, the open-source implementation that ships with SLES; and eDirectory, Novell's flagship identity management product.


Directories vs. databases


The terms directory and database are often used interchangeably when referring to LDAP compliant directories. In this article, directory refers to a LDAP complaint directory, and database refers to relational databases, such as MySQL or Oracle. The two are related, in that they both store information in a structured way, but differ in their implementation. In many cases, directories and databases could both fulfill a particular need. It is important to understand the differences between the two to best determine which to implement.


The largest general difference between directories and databases is complexity. Databases are capable of storing almost any arbitrary set of information and can can be greatly customized for a specific purpose. They also provide a complex query interface, allowing for flexible searches returning customized results. Directories, on the other hand, tend to have very specific implementations that follow a strict pattern or schema. This allows them to be extremely fast, and allows for easy organization and comprehension of the data they store.


From a technical standpoint, the main differences include:


  1. Layout. A database can been seen as a series of tables, or spreadsheets, consisting of rows and columns. Each column is a field, and each row is an entry, providing data for the fields. Tables can be related by one or more column, and complex queries select data based on combinations of rows and columns from various tables. For example, one table may list employee names and the department they belong to and another may list employee names, their phone numbers, and their cubicle numbers. A query can combine the two tables to return the names and phone numbers of all employees in a specific department. An example company, example.com, has the following database tables, and a query for the phone numbers of all engineers returns the following results:


Table 1: Employee/department relationships

first_name

last_name

department

Jay

Smith

Engineering

Joseph

Wilson

Engineering

John

West

Engineering

Sally

Stevens

Sales

Jane

Doe

Marketing

Table 2: Employee phone numbers

first_name

last_name

phone_number

cubicle_number

Jay

Smith

345-2332

E23

Joseph

Wilson

345-2312

E30

John

West

345-9393

E21

Sally

Stevens

345-2211

T55

Jane

Doe

345-3321

T33


Table 3: Result of query selecting names and phone numbers of all engineers

first_name

last_name

phone_number

Jay

Smith

345-2332

Joseph

Wilson

345-2312

John

West

345-9393

A directory, on the other hand, is best viewed as a hierarchical tree. It is comparable to a computer file system with folders and files. The organization, example.com, has a tree like this:

Figure 1: Example tree



It is easy to see that, based on the layout of the data, databases can be arranged to allow for extremely powerful and complex queries. Directories, on the other hand, allow for only simple queries such as listing the contents of a given sub-tree. These simple queries are strait-forward and easy to execute.


In addition, unlike a database, a directory can contain multiple entries for each data type. For example, suppose John West has more than one phone at his desk. In a directory, the new phone entry can simply be added to his sub-tree. In a database, an entire new column in the table needs to be created, wasting space for all the other people who don't have two phones.


  1. Access Time. Directories are optimized for fast reads, but have slow writes. This is largely due to their simple query structure. As a result, it is not good to store frequently changing information in a directory. They are primarily used for mostly static information, such as telephone directories. Constantly changing information such as store inventories should be stored in a database.

  2. Replication and Transactions. Directories allow their trees to be partitioned and replicated among several servers. For illustration, example.com has their main headquarters with the sales and marketing departments at one location, and the engineering department at a location across the country. They host their entire directory at corporate headquarters, but partition off the engineering tree and have it hosted at their satellite location as well. The engineering copy is synchronized with the master copy occasionally. This speeds the access time for the engineers to their own tree, and reduces the network bandwidth used between the two locations.

Inherent in this model is a lack of consistency between the master copy and the replicated copy. If data on the master copy is changed, it is not immediately available on the local copy. In directories this is considered to be acceptable. Directories generally do not support the strict transactions which databases rely on. In a database, all reads and writes are ensured to either entirely happen, or not happen at all through transactions, making them perfect for data that must maintain consistency, such as banking account information. Directories contain largely static information and do not have this requirement.


LDAP concepts


As mentioned above, directories are viewed as a tree, like a computer's file system. This overall tree structure is called the Directory Information Tree (DIT). Each entry in a directory is called an object. These objects are of two types, containers and leafs. A container is like a folder: it contains other containers or leafs. A leaf is simply an object at the end of a tree. A tree cannot contain any arbitrary set of containers and leafs. It must match the schema defined for the directory. Using a common scheme, the organization example.com has the following simplified DIT:


Figure 2: Example DIT



This example contains several abbreviations specific to the scheme being used. They all stand for different elements of the organization:


  • dcdomain component. Each element of the Internet domain name of the company is given individually.

  • ouorganizational unit. The company is divided into its individual organizations.

  • cn – common name. The common name a person. The leaf objects under this container describe elements of this person.


In this example 'dc=example,dc=com', 'ou=Marketing', and 'cn=Sally Stevens' are all examples of container objects. Leaf objects include 'telephoneNumber=3452211' and 'roomNumber=T55'.


Much like computer file systems, directories also support the concept of a path. In a directory, this is called a Distinguished Name (DN). The DN for John West is: cn=John West,ou=Engineering,dc=example,dc=com. It is built by individual Relative Distinguished Names (RDN's), separated by commas. Depending on the directory being used, each RDN should be separated by either a comma or a period.


openLDAP on SLES


SLES uses the open-source implementation of LDAP, called openLDAP. It is already be installed on any system that uses the default installation settings. There are only a few files that generally need to be accessed directly:


  • /etc/openldap/sldap.conf – The main configuration file for openLDAP. It contains sections for defining the schema of the directories, the access control settings for the directories, and the general settings for each individual directory.

  • /etc/openldap/schema/*.schema – Directories follow specifically defined schemes. These .schema files define several standard schemes. Referencing these .schema files in /etc/openldap/sldap.conf applies these schemes to the openLDAP directories.

  • /etc/init.d/ldap – The init script used to start, stop, and restart the openLDAP service.


There is extensive documentation available for /etc/openldap/sldap.conf and the .schema files in the SUSE LINUX Enterprise Server Administration Guide, sections 21.8.2 and 21.8.3. For additional information on various LDAP schema standards, see the Internet RFC/STD/FYI/BCP Archives. The files in /etc/openldap/schema/ are well commented and often list which RFC standards they contain elements of.

SLES has great a YaST module for managing the settings for openLDAP. Following is a brief introduction to configuring and adding a new directory for example.com.


  1. To get to the module, open the YaST Control Center, and select Network Services > LDAP Server. The first option is whether to start the server on system boot. Leave this as yes and select configure.

    Figure 3: LDAP Server Module


  1. The next screen allows for configuration of the LDAP server and directories. There is a navigation pane on the left. For example, selecting Global Settings > Schema Files shows the current schemes being used, and allows for schemes to be added or removed. For more in-depth information about LDAP configuration with YaST, see section 21.8.5 in the SUSE LINUX Enterprise Server Administration Guide.

    Figure 4: Schema Configuration


  2. The Databases section shows the currently configured directories. If SLES is installed with the defaults there will be one directory, site, which contains the login information for the users on this system. Create a new directory be selecting Databases in the left pane, and clicking Add Database. A new window is displayed which allows for new database information to be entered. Fill in all the fields as follows:

  • Base DN: dc=example,dc=com

  • Root DN: cn=Admin (Be sure Append Base DN is checked. Otherwise this field would need: cn=Admin,dc=example,dc=com)

  • LDAP Password: Enter a new password for the directory and select the encryption method.

  • Database Directory: /var/lib/ldap/example.com/

    This is the path to a folder where the directory files will be stored. Make sure the folder already exists.

    Figure 5: Database Configuration


  1. Select OK and notice the new directory now shows up in the database list. Select Finish to commit the changes.

  2. The new directory for example.com has now been set up. It has the base DN of dc=example,dc=com and an administrator user, cn=Admin,dc=example,dc=com. It is now ready to have additional entries added either by other clients which administer LDAP directories (such as the Network Services > LDAP Client), or by using the openLDAP command-line tools. The following section goes over these tools. For more information about using the LDAP Client, see Part 2 of this article.

Using the openLDAP command-line tools


openLDAP provides several command-line tools to add, modify, view, and delete objects from a directory. In this section, these tools are used to show how to manage the example.com DIT shown in Figure 2 above.


The openLDAP commands all share some common flags. The most important flags are outlined in Table 4.


Table 4: The openLDAP flags

Flag

Meaning

-x

By default, SASL authentication is used. -x causes simple authentication to be used instead.

-D <DN of Administrator user>

Specifies the user to authenticate for the current operation

-W

Prompts for the LDAP password

-f <file.ldif>

Specifies the file to import commands from.

-b <base DN of current operation>

Specifies the base DN to use for the current operation.


  1. ldapadd – The ldapadd command is used to insert objects into a DIT. It makes use of LDIF files to add multiple entries to a DIT at once. The LDIF format is simple, and is best shown by example. The hash (#) character indicates a line is a comment. For more information about LDIF files, see the slapd.replog(5) man page. Create a file called example.ldif which contains the following:


#Begin by adding example.com's departments

dn: ou=Marketing,dc=example,dc=com

objectClass: organizationalUnit

ou: Marketing


dn: ou=Sales,dc=example,dc=com

objectClass: organizationalUnit

ou: Sales


dn: ou=Engineering,dc=example,dc=com

objectClass: organizationalUnit

ou: Engineering


#Next, add the employees, their phone numbers, and their cubicle numbers.

#Notice that the schema require more information than was originally represented in the simple example.com DIT.

#Also notice how the employees are sorted into their organizations: Their DN places them under the ou (oranizational unit)

#they should belong to.

dn: cn=Jane Doe,ou=Marketing,dc=example,dc=com

objectClass: inetOrgPerson

cn: Jane Doe

givenName: Jane

sn: Doe

telephoneNumber: 3453321

roomNumber: T33


dn: cn=Sally Stevens,ou=Sales,dc=example,dc=com

objectClass: inetOrgPerson

cn: Sally Stevens

givenName: Sally

sn: Stevens

telephoneNumber: 3452211

roomNumber: T55


dn: cn=Jay Smith,ou=Engineering,dc=example,dc=com

objectClass: inetOrgPerson

cn: Jay Smith

givenName: Jay

sn: Smith

telephoneNumber: 3452332

roomNumber: E23


dn: cn=Joseph Wilson,ou=Engineering,dc=example,dc=com

objectClass: inetOrgPerson

cn: Joseph Wilson

givenName: Joseph

sn: Wilson

telephoneNumber: 3452312

roomNumber: E30

dn: cn=John West,ou=Engineering,dc=example,dc=com

objectClass: inetOrgPerson

cn: John West

givenName: John

sn: West

telephoneNumber: 3459393

roomNumber: E21


Make sure there is no trailing white space at the end of the lines—this will cause a syntax error. The entries can now be inserted into the directory with the following ldapadd command:


ldapadd -x -D cn=Admin,dc=example,dc=com -W -f example.ldif


If there are no syntax or schema errors, the output shows that the entries were all successfully inserted:


> ldapadd -x -D cn=Admin,dc=example,dc=com -W -f example.ldif

Enter LDAP Password:

adding new entry "ou=Marketing,dc=example,dc=com"


adding new entry "ou=Sales,dc=example,dc=com"


adding new entry "ou=Engineering,dc=example,dc=com"


adding new entry "cn=Jane Doe,ou=Marketing,dc=example,dc=com"


adding new entry "cn=Sally Stevens,ou=Sales,dc=example,dc=com"


adding new entry "cn=Jay Smith,ou=Engineering,dc=example,dc=com"


adding new entry "cn=Joseph Wilson,ou=Engineering,dc=example,dc=com"


adding new entry "cn=John West,ou=Engineering,dc=example,dc=com"


  1. ldapsearch – The ldapsearch command is used to return all or part of a DIT. The syntax is similar to that of the ldapadd command. For example, the command:


ldapsearch -x -b dc=example,dc=com


returns the entire contents of the DIT. Notice that all the entries added in the LDIF file above are returned, as well as one more:


dn: dc=example,dc=com

dc: example

o: example

objectClass: organization

objectClass: dcObject


This entry was created by the LDAP Server module, and is the object representing the root of the tree.


It is possible to restrict the search results in a couple of ways. The first is to restrict the branches of the tree being searched. This is done by restricting the search base further. For example:


ldapsearch -x -b ou=Engineering,dc=example,dc=com


returns only the ou=Engineering container, and everything below it. This includes the three people under the Engineering branch.


The next restriction can come as a filter. For example, we may want to return only the employees with a cubicle in building E. The entire tree can be searched, but then filtered on the cubicle number:


ldapsearch -x -b dc=example,dc=com “(roomNumber=E*)”


This search returns only the entries for the engineers.


  1. ldapmodify – The ldapmodify command allows for the information currently in a directory to be changed. Its syntax and behavior are nearly identical to the ldapadd command. It takes a LDIF file as input and makes the changes contained to the directory. For example, if Joseph Wilson moves to cubicle E22 his information is changed with the following LDIF file (change.ldif):


dn: cn=Joseph Wilson,ou=Engineering,dc=example,dc=com

changetype: modify

replace: roomNumber

roomNumber: E22


The directory is modified with the following:


ldapmodify -x -D cn=Admin,dc=example,dc=com -W -f change.ldif


The password is prompted for and the contents are modified.


Both the ldapadd and ldapmodify commands can take input directly from the keyboard as well. Simply leave the -f <file.ldif> flag off and the modification can be entered after the password is prompted for. Use <CRTL>-D to exit when all changes have been made.

  1. ldapdelete – The ldapdelete command removes one or more entry from a tree. The syntax is similar to the other commands, with the exception of a recursive operation flag, -r. If ldapdelete is called on anything other than a leaf object, the -r flag must be used to avoid an error message.


For example, to delete the leaf object Jane Doe, enter the following:


ldapdelete -x -D cn=Admin,dc=example,dc=com -W “cn=Jane Doe,ou=Marketing,dc=example,dc=com


To delete the entire engineering tree, enter the following:


ldapdelete -x -r -D cn=Admin,dc=example,dc=com -W ou=Engineering,dc=example,dc=com


Where to go next


This primer taught the basics of LDAP. For more information on practical uses of LDAP, see Part 2 of this article, Using LDAP to Create a User Authentication and File Server for Linux and Windows Clients.


References


  1. Lightweight Directory Access Protocol, http://en.wikipedia.org/wiki/Ldap

  2. The openLDAP Project, http://www.openldap.org/

  3. Introduction to LDAP, Brad Mashall, http://quark.humbug.org.au/publications/ldap/ldap_tut.html

  4. Understanding LDAP - Design and Implementation, http://www.redbooks.ibm.com/redbooks/SG244986/wwhelp/wwhimpl/java/html/wwhelp.htm

  5. SUSE Linux Enterprise Server Administration Guide, http://www.novell.com/documentation/sles9/pdfdoc/sles_9_admin_guide/sles_9_admin_guide.pdf, section 21.8


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell