The candidate should be able to configure an LDAP server. This objective includes configuring a directory hierarchy and adding group, hosts, services and other data to the hierarchy. Also included are: importing items from LDIF files and adding items with a management tool, as well as adding users to the directory and changing their passwords.
Key files, terms and utilities include:
slapd
|
slapd.conf
|
LDAP stands for Lightweight Directory Access Protocol. As the name suggests, it is a lighter version of DAP, which stands for the Directory Access Protocol that is defined by the X.500 standard. For more information on X.500, please read RFC 2116.
The reason for a lightweight version is that DAP was rather heavy on processor load, thereby asking for more than the processors could provide at the time. LDAP is described in RFC 2251.
The LDAP project was started at the University of Michigan, but, as can be read on their site, is no longer maintained there. For current information, the University of Michigan site points visitors to the OpenLDAP site instead.
The type of information best suited for storage in a directory is information with a low mutation grade. The reason for this is that directories can not compete with RDBM systems because they are only optimized for read access. So then, what do we store in a directory? Typically, LDAP directories contain employee data such as surname, christian name, address, phone number, department, social security number, E-mail address. Alternatively, directories might store newsletters for everyone to read, description of company policies and procedures, templates supporting the house style of documents.
The Open Source LDAP software can be downloaded from the OpenLDAP Download site.
Detailed instructions on installing LDAP can be found in the OpenLDAP Administrator's Guide.
On a Debian system, apt-get install slapd will
do the trick. You will have to edit the file
/etc/ldap/slapd.conf to reflect your wishes.
After this, the slapd daemon can be started with the command /etc/init.d/slapd start.
Let's take the company MegaFix in The Netherlands as an example.
This figure shows MegaFix's organisational structure.
The company consists of three departments: Sales, Engineering and Administration.
In order to provide local support to their customers, the Engineering department has offices in London, Paris, Rome and Amsterdam with, for the moment, one or two engineers.
So, how do we build a directory for this organization?
First, we must decide what kind of information to store in the directory. Let's put ourselves in the shoes of the customer:
The organizational structure of the company
Information about people working at the company
The second thing to do is select or create object class and schema
definitions. The directory /etc/ldap/schema
contains a number of predefined ones and
core.schema fits our needs (trust me, or have
a look at it if you don't).
The third thing to do is choose the object class we are going to use. This depends on the data we wish to store. An object class describes an object by defining its possible attributes.
For the organizational structure of the company, we are going to use the object classes organization, organizationalUnit (note the “z”) and country. This gives us the following attributes:
postalAddress
For people working for the company, we are going to use the object class person, which supports the following attributes:
commonName or “cn” in short notation
surname or “sn” in short notation
userPassword
telephoneNumber
seeAlso
description
Let's configure slapd to reflect these
choices by editing the
configuration file /etc/ldap/slapd.conf:
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
# Schema check allows for forcing entries to
# match schemas for their objectClasses's
schemacheck off
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd.args
# Read slapd.conf(5) for possible values
loglevel 0
#######################################################################
# ldbm database definitions
#######################################################################
# The backend type, ldbm, is the default standard
database ldbm
# The base of your directory
suffix "o=MegaFix,c=NL"
# Where the database files are physically stored
directory "/var/ldap-test"
# Distinguished name, not subject to access control
rootdn "cn=Manager,o=MegaFix,c=NL"
rootpw blabla
# Save the time that the entry gets modified
lastmod on
For further details on the configuration file, please read the man page (man slapd.conf).
Nest, we need to create the directory where the databases will reside: mkdir /var/ldap-test. Now we're ready to start the daemon:
# /etc/init.d/slapd start
Starting ldap server(s): slapd.
It seems to work. Let's see if there are any error messages that have been logged:
# ls -ltr /var/log
...
-rw-r----- 1 root adm 934047 Jan 25 16:44 syslog
-rw-r----- 1 root adm 45275 Jan 25 16:44 debug
-rw-r----- 1 root adm 282043 Jan 25 16:45 auth.log
There are no messages in syslog and debug but auth.log contains:
# grep "slapd" /var/log/auth.log
Jan 25 16:44:22 pug slapd[1373]: unable to open Berkeley db /etc/sasldb: No
such file or directory
SASL stands for “Simple Authentication and Security Layer”. This is the layer between OpenLDAP and Kerberos. Since we're not using Kerberos, let's silently ignore the message.
Finally, we define the MegaFix organization in LDAP Data Interchange Format (ldif). See ldif's man page (man ldif) for further details.
#------------------------------------------------------------
# The organisational structure
#
# dn = distinguishedName
# ou = organizationalUnit
# o = organizationName
# c = country
#------------------------------------------------------------
# The organisation MegaFix in the Netherlands
dn: o=MegaFix, c=NL
objectClass: organization
description: The MegaFix Company Ltd.
# The Sales department
dn: ou=Sales, o=MegaFix, c=NL
objectClass: organization
description: Sales dept.
# The engineering department
dn: ou=Engineering, o=MegaFix, c=NL
objectClass: organization
description: Engineering dept.
# Engineering - London division
dn: ou=London, ou=Engineering, o=MegaFix, c=NL
objectClass: organization
description: Division London
# Engineering - Paris division
dn: ou=Paris, ou=Engineering, o=MegaFix, c=NL
objectClass: organization
description: Division Paris
# Engineering - Rome division
dn: ou=Rome, ou=Engineering, o=MegaFix, c=NL
objectClass: organization
description: Division Rome
# Engineering - Amsterdam division
dn: ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
objectClass: organization
description: Division Amsterdam
dn: ou=Administration, o=MegaFix, c=NL
objectClass: organization
description: Administration dept.
#------------------------------------------------------------
# The persons in the organisation
#
# dn = distinguishedName
# ou = organizationalUnit
# o = organizationName
# c = country
# cn = commonName
# sn = surname
#------------------------------------------------------------
# The Company's Manager
dn: cn=Manager, o=MegaFix, c=NL
objectClass: person
cn: Manager
cn: Gordon Gekko
sn: Gekko
description: General Manager - The Big Boss
telephoneNumber: 555-1255
# The engineers in London
dn: cn=John Hughes, ou=London, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: John Hughes
sn: Hughes
description: Engineer
dn: cn=Peter Baines, ou=London, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: Peter Baines
sn: Baines
description: Engineer
# The engineers in Paris
dn: cn=Linda Charteris, ou=Paris, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: Linda Charteris
sn: Charteris
description: Engineer
# The engineers in Rome
dn: cn=Marcello Conti, ou=Rome, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: Marcello Conti
sn: Conti
description: Engineer
# The engineers in Amsterdam
dn: cn=Pieter Jansen, ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: Pieter Jansen
sn: Jansen
description: Engineer
dn: cn=Johan Klaassens, ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: Johan Klaassens
sn: Klaassens
description: Engineer
To update our directory with the data from the above file
MegaFix.ldif, we use the command:
# ldapadd -f /etc/ldap/MegaFix.ldif -D 'cn=Manager,o=Megafix,c=NL' -W -x
Enter LDAP Password: (which is 'blabla')
adding new entry "o=MegaFix, c=NL"
adding new entry "ou=Sales, o=MegaFix, c=NL"
adding new entry "ou=Engineering, o=MegaFix, c=NL"
adding new entry "ou=London, ou=Engineering, o=MegaFix, c=NL"
adding new entry "ou=Paris, ou=Engineering, o=MegaFix, c=NL"
adding new entry "ou=Rome, ou=Engineering, o=MegaFix, c=NL"
adding new entry "ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL"
adding new entry "ou=Administration, o=MegaFix, c=NL"
adding new entry "cn=Manager, o=MegaFix, c=NL"
adding new entry "cn=John Hughes, ou=London, ou=Engineering, o=MegaFix, c=NL"
adding new entry "cn=Peter Baines, ou=London, ou=Engineering, o=MegaFix, c=NL"
adding new entry "cn=Linda Charteris, ou=Paris, ou=Engineering, o=MegaFix, c=NL"
adding new entry "cn=Marcello Conti, ou=Rome, ou=Engineering, o=MegaFix, c=NL"
adding new entry "cn=Pieter Jansen, ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL"
adding new entry "cn=Johan Klaassens, ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL"
The data has been added.
To check if everything works the way we want it to, let's ask our directory for a list of all entries concerning the “engineering” organizationalUnit, “ou” for short:
# ldapsearch -LLL -b 'ou=engineering,o=MegaFix,c=nl' -x cn description
dn: ou=Engineering, o=MegaFix, c=NL
description: Engineering dept.
dn: ou=London, ou=Engineering, o=MegaFix, c=NL
description: Division London
dn: ou=Paris, ou=Engineering, o=MegaFix, c=NL
description: Division Paris
dn: ou=Rome, ou=Engineering, o=MegaFix, c=NL
description: Division Rome
dn: ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
description: Division Amsterdam
dn: cn=John Hughes, ou=London, ou=Engineering, o=MegaFix, c=NL
cn: Engineer
cn: John Hughes
description: Engineer
dn: cn=Peter Baines, ou=London, ou=Engineering, o=MegaFix, c=NL
cn: Engineer
cn: Peter Baines
description: Engineer
dn: cn=Linda Charteris, ou=Paris, ou=Engineering, o=MegaFix, c=NL
cn: Engineer
cn: Linda Charteris
description: Engineer
dn: cn=Marcello Conti, ou=Rome, ou=Engineering, o=MegaFix, c=NL
cn: Engineer
cn: Marcello Conti
description: Engineer
dn: cn=Pieter Jansen, ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
cn: Engineer
cn: Pieter Jansen
description: Engineer
dn: cn=Johan Klaassens, ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
cn: Engineer
cn: Johan Klaassens
description: Engineer
And it works!
The distinguishedName, or “dn”, consists of the set of attributes that uniquely identify an entry. This set of attributes corresponds to the “path” that has to be traveled to reach that entry. The last result shown above, “Johan Klaassens”, is found by starting to search at “o=MegaFix and c=NL”, going to the department of “Engineering” and finally going to the division “Amsterdam”.
MegaFix's sales in Amsterdam have increased and thus the need for a third engineer arose. Luckily, Mr. Wim Poorten applied for the job and got it.
To add Mr. Poorten to our directory, we create the file
/etc/ldap/MegaFix.Amsterdam.Add.ldif, I like
descriptive names, and issue the command:
# ldapadd -f /etc/ldap/MegaFix.Amsterdam.Add.ldif -D 'cn=Manager,o=MegaFix,x=NL' -W -x
Enter LDAP Password: (which is 'blabla')
There should now be three engineers working in the Amsterdam division:
# ldapsearch -LLL -b 'ou=amsterdam,ou=engineering,o=MegaFix,c=nl' -x cn
dn: ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
dn: cn=Pieter Jansen, ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
cn: Engineer
cn: Pieter Jansen
dn: cn=Johan Klaassens, ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
cn: Engineer
cn: Johan Klaassens
dn: cn=Wim Poorten, ou=Amsterdam, ou=Engineering, o=MegaFix, c=NL
cn: Engineer
cn: Wim Poorten
And, as you can see, there are!
Unfortunately, sales are down in London but are expected to increase the next quarter. In Paris, there are a lot of problems, so an extra engineer for a week or two would be nice. John Hughes always wanted to see Paris and offered to assist his colleague Linda for a week or two.
Naturally, the directory should reflect this new situation to enable people to locate John when needed. Since the “ou” is part of the distinguishedName and ou occurs twice, a simple modify won't work. The safest way to do this is to get the existing entry and write it to a file in ldif format. Then, modify that file to first delete the existing entry and then add a new one with the new location.
# ldapsearch -LLL -b 'ou=london,ou=engineering,o=MegaFix,c=nl' -x > MegaFix.John.to.Paris.ldif
This gives all information about the London division of the Engineering department:
dn: ou=London, ou=Engineering, o=MegaFix, c=NL
objectClass: organization
description: Division London
dn: cn=John Hughes, ou=London, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: John Hughes
sn: Hughes
description: Engineer
dn: cn=Peter Baines, ou=London, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: Peter Baines
sn: Baines
description: Engineer
Remove the all entries except the one from John Huges and modify/add lines so that the file looks like this:
# Remove John Hughes from London
dn: cn=John Hughes, ou=London, ou=Engineering, o=MegaFix, c=NL
changetype: delete
# And place him in the Paris division
dn: cn=John Hughes, ou=Paris, ou=Engineering, o=MegaFix, c=NL
changetype: add
objectClass: person
cn: Engineer
cn: John Hughes
sn: Hughes
description: Engineer
To commit the changes to the database, we issue the command:
# ldapmodify -r -f MegaFix.John.to.Paris.ldif -D 'cn=Manager,o=MegaFix,c=NL' -W -x
Enter LDAP Password: (which is 'blabla')
deleting entry "cn=John Hughes, ou=London, ou=Engineering, o=MegaFix, c=NL"
adding new entry "cn=John Hughes, ou=Paris, ou=Engineering, o=MegaFix, c=NL"
To demonstrate that John is now stationed in Paris, we issue the following search command:
pug:/etc/ldap# ldapsearch -LLL -b 'ou=Paris,ou=engineering,o=MegaFix,c=nl' -x
dn: ou=Paris, ou=Engineering, o=MegaFix, c=NL
objectClass: organization
description: Division Paris
dn: cn=Linda Charteris, ou=Paris, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: Linda Charteris
sn: Charteris
description: Engineer
dn: cn=John Hughes, ou=Paris, ou=Engineering, o=MegaFix, c=NL
objectClass: person
cn: Engineer
cn: John Hughes
sn: Hughes
description: Engineer
If you would like to read more about LDAP, this section points you to a few sources of information:
The Internet FAQ archives where RFC's and other documentation can be searched and found.