7.8. OpenLdap (Ldap)

Important

LDAP means lightweight directory access protocol and is a protocol for accessing data based on an X.500 service. It is run on TCP/IP and the directory is similar to that of a database that contains information based on attributes. The system allows this information to be organised in a secure manner and uses replicas to maintain its availability, ensuring its coherence and verification of accessed-modified data.

The service is based on the client-server model, where there is one or more servers that contain the data; when a client connects and asks for information, the server replies with the data or a pointer to another server where more information can be extracted, but the client will only see a directory of global information. [Mou01, Mal07]

To import and export information between ldap servers or to describe a number of changes that will be applied to the directory, we use a format called LDIF (LDAP data interchange format). LDIF stores the information in hierarchies oriented at objects that will then be converted to the internal format of the database. An LDIF file has a similar format to:

dn: o = UOC, c = SP
or: UOC
objectclass: organization
dn: cn = Pirulo Nteum, o = UOC, c = SP
cn: Pirulo Nteum
sn: Nteum
mail: nteum@uoc.edu
objectclass: person

Each entry is identified by a name indicated as a distinguished name (DN). The DN consists of the entry name plus a series of names that relate it to the directory's hierarchy and where there is an objectclass, that defines the attributes that can be used in this entry. LDAP offers a basic set of object classes: groups (including disorganised lists of individual objects or groups of objects), locations (such as countries and their description), organisations and people. An entry can also belong to more than one object class, for example, an individual is defined by the class of person, but can also be defined by attributes of the classes inetOrgPerson, groupOfNames, and organisation. The structure of the server's objects (called schema) determines what the permitted attributes are for an object of a class (which are defined in /etc/ldap/schema as opeldap.schema, corba.schema, nis.schema, inetorgperson. schema etc.).

All the data are represented as a pair attribute = value where attribute is the description of the information it contains, for example, the attribute used to store the name of a person is commonName, or cn, in other words for a person called Pirulo Nteum, it will be represented by cn: Pirulo Nteum and will have associated other attributes of the person class such as givenname: Pirulo surname: Nteum mail: pirulo@uoc.edu. The classes have obligatory and optional attributes and every attribute has an associated syntax which indicates what type of information the attribute contains, for example, bin (binary), ces (case exact string, case must match in search), cis (case ignore string, case can be ignored during the search), tel (telephone number string, ignores spaces and '-'), dn (distinguished name). An example of a file in LDIF format could be:

dn: dc = UOC, dc = com
objectclass: top
objectclass: organizationalUnit
dn: ou = groups, dc = UOC, dc = com
objectclass: top
objectclass: organizationalUnit
ou: groups
dn: ou = people, dc = UOC, dc = com
objectclass: top
objectclass: organizationalUnit
ou: people
dn: cn = Pirulo Nteum, ou = people, dc = UOC, dc = com
cn: Pirulo Nteum
sn: Nteum
objectclass: top
objectclass: person
objectclass: posixAccount
objectclass: shadowAccount
             uid:pirulo
             userpassword:{crypt}p1pss2ii(0pgbs*do&@ = )eksd
             uidnumber:104
             gidnumber:100
             gecos:Pirulo Nteum
             loginShell:/bin/bash
             homeDirectory: /home/pirulo
             shadowLastChange:10877
             shadowMin: 0
             shadowMax: 999999
             shadowWarning: 7
             shadowInactive: -1
             shadowExpire: -1
             shadowFlag: 0
dn: cn = unixgroup, ou = groups, dc = UOC, dc = com
objectclass: top
objectclass: posixGroup
cn: unixgroup
gidnumber: 200
memberuid: pirulo other-user
memberuid:

The long lines can be continued underneath starting with a space or a tab (LDIF format). In this case, the DN base has been defined for the institution dc = UOC, dc = com, which contains two sub-units: people and groups. Then it has described a user that belongs to people and to group. Having prepared the file with the data, we need to import it to the server so that it is available for LDAP clients. There are tools for converting the data of different databases to the LDIF format. [Mal07]

In Debian, we need to install the slapd package which is the OpenLdap server. During the installation, it will ask a number of questions such as: Method of installing the directory: auto; extensions to the directory [domain-host,site,institution]: host, domain, password of the Adm; replicate local changes to other servers: no. This installation will generate a configuration file in /etc/ldap/slapd.conf and the database on /var/lib/ldap. There is also another file /etc/ldap/ldap.conf (or ~/.ldaprc), which is the configuration file used for initialising default values when ldap clients are executed. Here it indicates which is the database, which is the ldap server, security parameters, size of the search etc.

The /etc/ldap/slapd.conf server configuration file (see man slap.con) consists of different sections, each indicated by one of the following guidelines: global, backend specific and database specific, and in that order. The global guideline is of a general nature and applies to all the backends (databases) and defines general questions such as access permissions, attributes, waiting times, schemas etc. The backend specific guideline defines the attributes to the specific backend that it defines (bdb, dnssrv, ldbm...), and the database specific guideline defines the specific attributes for the database it defines. To boot the server, we need to run:

/etc/init.d/slapd start (or stop to stop it)

During the installation, the system will have created the right links for running it after start up.

7.8.1. Creating and maintaining the database

There are two methods for entering data in the LDAP database. The first one is easy and suitable for small amounts of data, it is interactive and we need to use tools such as ldapadd (or any other such as Ldap Browser http://www.iit.edu/~gawojar/ldap/) to make new entries. The second needs to be worked on offline and is suitable for large databases and uses the slapadd command included with slapd. Because it is more general, we will briefly describe the second method, where we must first verify that it contains the following attributes in slapd.conf: suffix (top of the directory, for example "o = UOC, c = SP"); directory /var/lib/ldap (directory where the indexes will be created and that can write slapd). We must also verify that the database contains the definitions of the indexes we wish to use:

index cn,sn,uid
index objectClass pres,eq

Having defined the slapd.conf, we must execute the command:

slapadd -l entry-f configuration [-d level] [-n whole| -b suffix]

The arguments are:

-l: file in LDFI format.
-f: server configuration file where it indicates how to create the indexes.
-d: level of debugging.
-n: Nro of the database, if we have more than one.
-b: specifies what database need to be modified.

There are other commands with slapd such as slapindex, which allows the indexes to be regenerated, and slapcat, which allows dumping the database to a file in LDIF format.