Building an LDAP Server on Linux, Part 3

By Carla Schroder | Nov 11, 2003 | Print this Page
http://www.enterprisenetworkingplanet.com/netsysm/article.php/3107321/Building-an-LDAP-Server-on-Linux-Part-3.htm

So, you've come back for more OpenLDAP fun. Part 1 of this series served as an introduction to the Lightweight Directory Access Protocol, with a breakdown of what the protocol can and cannot do. In Part 2 we covered installation and a very basic configuration. Today we'll populate our directory with actual data and glide effortlessly through some of the more common showstoppers.

Let's start with a review of our slapd.conf configuration from part 2:

##Database Directives##
database bdb
suffix "dc=carlasworld,dc=net"
rootdn "cn=Manager,dc=carlasworld,dc=net"
rootpw secret
directory "/var/lib/ldap"

Let's take a good look at each line in the configuration.

  • First, make sure to replace "carlasworld.net" with your real domain.

  • The rootdn is extremely important. This is where you create the authorized user to make entries into the database. Here I've called it Manager. You can make this anything: admin, boss, ldapdeitysupreme — whatever your heart desires.

  • rootpw is also of extreme importance. This is the authorized user's (Manager's) password. For now, we'll use a cleartext password. In the example above, it's "secret"; again the password can be anything you want.

  • The directory where OpenLDAP stores the actual database files is on the next line. This directory MUST exist before starting slapd.
"/var/lib/ldap" is a common location created by the installer. Your Linux distribution may have plonked it somewhere else, though. You can also create a location of your own choosing. However, there is more to it than just creating the directory — see the OpenLDAP Administrator's Guide for the gory details.

The directory will already be populated by the following files:

$ ls /var/lib/ldap
__db.001 __db.003 __db.005 id2entry.bdb objectClass.bdb
__db.002 __db.004 dn2id.bdb log.0000000001

Page 2: Is It Working Yet?

Is It Working Yet?

First, check slapd.conf for syntax errors:

# slapd -t

Then run the following command exactly as written:

$ ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts

It will return several lines of mysterious stuff; look for this line:

dn:
namingContexts: dc=carlasworld,dc=net

Changing slapd.conf

Anytime you change slapd.conf, it must be restarted:

# /etc/init.d/slapd restart

Adding Entries

Now we get to the fun part. Manually creating entries is a two-step process. First, create an .ldif file, and then use the command ldapadd to put the new entries in the database. In the .ldif file — let's call it test.ldif — define some attributes of your company:

##my company##
dn: dc=carlasworld,dc=net
objectclass: dcObject
objectclass: organization
o: Tuxcomputing, inc.
dc: carlasworld

dn: cn=Manager,dc=carlasworld,dc=net
objectclass: organizationalRole
cn: Manager

.ldif Pitfalls

Be sure to trim all leading and trailing spaces, as well as any leading blank lines. Any leading spaces, or a leading blank line, will make ldapadd think there is nothing there, while a trailing space at the end of a line tells ldapadd that the next line is a continuation of the previous line. Use blank lines to separate entries.

The next step is to add the test.ldif file to ldap:

# ldapadd -x -D "cn=Manager,dc=carlasworld,dc=net" -W -f test.ldif

See man ldapadd for explanations of the various flags. ldap will ask for your LDAP password and then confirm the entry was added. If you get the infamous "ldap_bind: Invalid credentials (49)" error, it means you gave either the wrong "cn=" entry or the wrong password.

Both the common name (cn) and the password are right there in slapd.conf, so there shouldn't be any mysteries on these items. Note that we will eliminate these later. (While they are needed when creating a new database, we will replace them later on when we add stronger authorization.)

Let's see what our database looks like now:

# ldapsearch -x -b 'dc=carlasworld,dc=net' '(objectclass=*)'

This will display every entry in the database.

Page 3: Adding Users

Adding Users

Ok, now we're rolling. Let's add some actual users, with a users.ldif file:

#Tux Entry
dn: cn=Tux P Tuxedo,dc=carlasworld,dc=net
cn: Tux P Tuxedo
cn: Tux Tuxedo
objectClass: person
sn: Tuxedo

# ldapadd -x -D "cn=Manager,dc=carlasworld,dc=net" -W -f users.ldif
Enter LDAP Password:
adding new entry "cn=Tux P Tuxedo,dc=carlasworld,dc=net"

# ldapsearch -x -b 'dc=carlasworld,dc=net' '(objectclass=*)'

# extended LDIF
#
# LDAPv3
# base with scope sub
# filter: (objectclass=*)
# requesting: ALL
#

# carlasworld.net
dn: dc=carlasworld,dc=net
objectClass: top
objectClass: dcObject
objectClass: organization
o: Tuxcomputing, Inc.

# Tux P Tuxedo, carlasworld.net
dn: cn=Tux P Tuxedo,dc=carlasworld,dc=net
cn: Tux P Tuxedo
cn: Tux Tuxedo
objectClass: person
sn: Tuxedo

Hurrah! It works, it works! Note that you cannot append new entries to your .ldif file, as it must contain only new entries. If ldapadd finds any existing entries, it will stop and not process any more entries.

The Debian Difference

If you use apt-get to install OpenLDAP, dpkg will automatically configure it and set up the root domain, company, and the authorized LDAP admin and password. You can also create another LDAP admin/password combo in slapd.conf, as we did above, and use either one.

Page 4: Schema

Schema

Major sources of confusion are schema and object classes. In slapd.conf, see:

# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema

These files contain the attributes that you are allowed to use in your LDAP records. Spend some time reading through these. I know, it's a painful exercise, but understanding the schema is the key to understanding how to use LDAP.

Now might be a good time to mention a useful GUI front-end for LDAP called GQ LDAP Client. It helps a great deal in visualizing the relationships between the different attributes. The excellent Web site LDAPman Schema Reference is another valuable tool you'll want to review.

Conclusion

Ok, it looks like we'll have one more LDAP article after all. In part 4 we'll add encryption and authenticate actual users. We'll wrap up the article (and the series) with some detailed sample configs.

Resources

Building an LDAP Server on Linux, Part 1
Building an LDAP Server on Linux, Part 2
OpenLDAP Administrator's Guide
GQ LDAP Client
LDAPman Schema Reference page.


» See All Articles by Columnist Carla Schroder