Installez le démon du serveur OpenLDAP et les utilitaires de gestion traditionnels de LDAP. On les trouve respectivement dans les paquets slapd et ldap-utils.

The installation of slapd will create a working configuration. In particular, it will create a database instance that you can use to store your data. However, the suffix (or base DN) of this instance will be determined from the domain name of the localhost. If you want something different, edit /etc/hosts and replace the domain name with one that will give you the suffix you desire. For instance, if you want a suffix of dc=example,dc=com then your file would have a line similar to this:

127.0.1.1       nom_d'hote.example.com	nom-d'hote

Vous pouvez annuler la modification après l'installation du paquet.

Procédez à l'installation :

sudo apt-get install slapd ldap-utils

Since Ubuntu 8.10 slapd is designed to be configured within slapd itself by dedicating a separate DIT for that purpose. This allows one to dynamically configure slapd without the need to restart the service. This configuration database consists of a collection of text-based LDIF files located under /etc/ldap/slapd.d. This way of working is known by several names: the slapd-config method, the RTC method (Real Time Configuration), or the cn=config method. You can still use the traditional flat-file method (slapd.conf) but it's not recommended; the functionality will be eventually phased out.

During the install you were prompted to define administrative credentials. These are LDAP-based credentials for the rootDN of your database instance. By default, this user's DN is cn=admin,dc=example,dc=com. Also by default, there is no administrative account created for the slapd-config database and you will therefore need to authenticate externally to LDAP in order to access it. We will see how to do this later on.

De nos jours, certains schémas classiques (cosine, nis, inetorgperson) sont intégrés avec slapd. Il y a aussi un schéma « de base », un pré-requis pour que les schémas puissent fonctionner.

Le processus d'installation met en place 2 DIT. Un pour slapd-config et un pour vos propres données (dc=exemple, dc=com). Jetons-y un coup d’œil.

Introduisons un peu de contenu dans notre base de données. Nous allons ajouter ce qui suit :

Créez le fichier LDIF suivant et appelez le add_content.ldif :

dn: ou=People,dc=example,dc=com
objectClass: organizationalUnit
ou: People

dn: ou=Groups,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups

dn: cn=miners,ou=Groups,dc=example,dc=com
objectClass: posixGroup
cn: miners
gidNumber: 5000

dn: uid=john,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: john
sn: Doe
givenName: John
cn: John Doe
displayName: John Doe
uidNumber: 10000
gidNumber: 5000
userPassword: johnldap
gecos: John Doe
loginShell: /bin/bash
homeDirectory: /home/john

Ajouter le contenu :

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

Enter LDAP Password: ********
adding new entry "ou=People,dc=example,dc=com"

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

adding new entry "cn=miners,ou=Groups,dc=example,dc=com"

adding new entry "uid=john,ou=People,dc=example,dc=com"

Nous pouvons vérifier que l'information a été correctement ajoutée avec l'utilitaire ldapsearch :

ldapsearch -x -LLL -b dc=example,dc=com 'uid=john' cn gidNumber

dn: uid=john,ou=People,dc=example,dc=com
cn: John Doe
gidNumber: 5000

Explication des changements :

Le DIT de slapd-config peut également être interrogé et modifié. Voici quelques exemples.

Activity logging for slapd is indispensible when implementing an OpenLDAP-based solution yet it must be manually enabled after software installation. Otherwise, only rudimentary messages will appear in the logs. Logging, like any other slapd configuration, is enabled via the slapd-config database.

OpenLDAP comes with multiple logging subsystems (levels) with each one containing the lower one (additive). A good level to try is stats. The slapd-config man page has more to say on the different subsystems.

Créez le fichier logging.ldif avec le contenu suivant :

dn: cn=config
changetype: modify
add: olcLogLevel
olcLogLevel: stats

Appliquez le changement :

sudo ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f logging.ldif

This will produce a significant amount of logging and you will want to throttle back to a less verbose level once your system is in production. While in this verbose mode your host's syslog engine (rsyslog) may have a hard time keeping up and may drop messages:

rsyslogd-2177 : imuxsock a perdu 228 messages du pid 2547 à cause de la limitation de débit

Vous pouvez envisager un changement dans la configuration de rsyslog. Dans /etc/rsyslog.conf, entrez :

# Désactivez la limitation de débit
# (la limitation par défaut est de 200 messages en 5 secondes ; ci-dessous nous faisons que le 5 devienne 0)
$SystemLogRateLimitInterval 0

Et puis redémarrez le démon rsyslog :

sudo service rsyslog restart

The LDAP service becomes increasingly important as more networked systems begin to depend on it. In such an environment, it is standard practice to build redundancy (high availability) into LDAP to prevent havoc should the LDAP server become unresponsive. This is done through LDAP replication.

Replication is achieved via the Syncrepl engine. This allows changes to be synchronized using a Consumer - Provider model. The specific kind of replication we will implement in this guide is a combination of the following modes: refreshAndPersist and delta-syncrepl. This has the Provider push changed entries to the Consumer as soon as they're made but, in addition, only actual changes will be sent, not entire entries.

The management of what type of access (read, write, etc) users should be granted to resources is known as access control. The configuration directives involved are called access control lists or ACL.

When we installed the slapd package various ACL were set up automatically. We will look at a few important consequences of those defaults and, in so doing, we'll get an idea of how ACLs work and how they're configured.

To get the effective ACL for an LDAP query we need to look at the ACL entries of the database being queried as well as those of the special frontend database instance. The ACLs belonging to the latter act as defaults in case those of the former do not match. The frontend database is the second to be consulted and the ACL to be applied is the first to match ("first match wins") among these 2 ACL sources. The following commands will give, respectively, the ACLs of the hdb database ("dc=example,dc=com") and those of the frontend database:

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={1}hdb)' olcAccess

dn: olcDatabase={1}hdb,cn=config
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous
              auth by dn="cn=admin,dc=example,dc=com" write by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=example,dc=com" write by *
  read

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={-1}frontend)' olcAccess

dn: olcDatabase={-1}frontend,cn=config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,
              cn=external,cn=auth manage by * break
olcAccess: {1}to dn.exact="" by * read
olcAccess: {2}to dn.base="cn=Subschema" by * read

La toute première ACL est cruciale :

olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous
              auth by dn="cn=admin,dc=example,dc=com" write by * none

Ceci peut être représenté différemment pour une digestion plus facile :

to attrs=userPassword
	by self write
	by anonymous auth
	by dn="cn=admin,dc=example,dc=com" write
	by * none

to attrs=shadowLastChange
	by self write
	by anonymous auth
	by dn="cn=admin,dc=example,dc=com" write
	by * none

Cette ACL composée (il y en a deux) implique ce qui suit :

This DIT can be searched anonymously because of 'by * read' in this ACL:

to *
	by self write
	by dn="cn=admin,dc=example,dc=com" write
	by * read

Si ce n'est pas désiré, il vous faut modifier les ACLs. Pour forcer l'authentification lors d'une demande de liaison, vous pouvez alternativement (ou en combinaison avec l'ACL modifiée) utiliser la directive « olcRequire: authc ».

Comme mentionné précédemment, il n'existe pas de compte administrateur créé pour la base de données slapd-config. Il y a cependant une identité SASL accordée pour un accès complet à celle-ci. Il représente le super-utilisateur de l'hôte local (root/sudo). Le voici :

dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth 

La commande suivante affichera les ACL (listes de contrôle d’accès) de la base de données slapd-config :

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcDatabase={0}config)' olcAccess

dn: olcDatabase={0}config,cn=config
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,
              cn=external,cn=auth manage by * break

Since this is a SASL identity we need to use a SASL mechanism when invoking the LDAP utility in question and we have seen it plenty of times in this guide. It is the EXTERNAL mechanism. See the previous command for an example. Note that:

Voici une façon rapide d'obtenir toutes les ACL :

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b \ cn=config '(olcAccess=*)' olcAccess olcSuffix

Il y a beaucoup à dire sur le sujet du contrôle d'accès. Voir la page de manuel sur les accès.slapd.

Pour s'authentifier sur un serveur OpenLDAP, il est préférable d'utiliser une session chiffrée. Cela peut être accompli en utilisant le protocole TLS (Transport Layer Security).

Ici, nous serons notre propre autorité de certification (CA), puis nous allons créer et signer notre certificat de serveur LDAP en tant que CA. Puisque slapd est compilé avec la bibliothèque gnutls, nous utiliserons l'utilitaire certtool pour effectuer ces tâches.

Créez le fichier certinfo.ldif avec le contenu suivant (ajustez en conséquence, notre exemple suppose que nous avons créé les certificats en utilisant https://www.cacert.org) :

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/ldap01_slapd_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/ldap01_slapd_key.pem

Utilisez la commande ldapmodify pour informer slapd de notre emploi de TLS via la base de données slapd-config :

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f /etc/ssl/certinfo.ldif

Contrairement à la croyance populaire, vous n'avez pas besoin de ldaps :// dans /etc/default/slapd pour utiliser le chiffrement. Vous devriez avoir seulement :

SLAPD_SERVICES="ldap:/// ldapi:///"

Resserrez la propriété et les autorisations :

sudo adduser openldap ssl-cert
sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem
sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem
sudo chmod o-r /etc/ssl/private/ldap01_slapd_key.pem

Redémarrez OpenLDAP :

sudo service slapd restart

Consultez les fichiers de journalisation de votre hôte (/var/log/syslog) pour voir si le serveur a démarré correctement.

If you have set up replication between servers, it is common practice to encrypt (StartTLS) the replication traffic to prevent evesdropping. This is distinct from using encryption with authentication as we did above. In this section we will build on that TLS-authentication work.

The assumption here is that you have set up replication between Provider and Consumer according to Réplication and have configured TLS for authentication on the Provider by following TLS.

As previously stated, the objective (for us) with replication is high availablity for the LDAP service. Since we have TLS for authentication on the Provider we will require the same on the Consumer. In addition to this, however, we want to encrypt replication traffic. What remains to be done is to create a key and certificate for the Consumer and then configure accordingly. We will generate the key/certificate on the Provider, to avoid having to create another CA certificate, and then transfer the necessary material over to the Consumer.

Une fois que vous avez un serveur LDAP fonctionnel, vous devrez installer des bibliothèques sur le client qui saura comment et quand les contacter. Sur Ubuntu, ceci a été traditionnellement fait par l'installation du paquet libnss-ldap. Ce paquet apportera d'autres outils qui vous assisteront dans l'étape de configuration. Maintenant, installez ce paquet :

sudo apt-get install libnss-ldap

Vous serez invité à entrer les détails de votre serveur LDAP. Si vous faites une erreur, vous pouvez essayer à nouveau en utilisant :

sudo dpkg-reconfigure ldap-auth-config

Le résultat de la configuration est visible dans /etc/ldap.conf. Si votre serveur requiert des options non couvertes par l'assistant, modifiez ce fichier en conséquence.

Maintenant, configurez le profil LDAP pour NSS :

sudo auth-client-config -t nss -p lac_ldap

Configurez le système pour qu'il utilise LDAP pour l'authentification :

sudo pam-auth-update

Dans le menu, choisissez LDAP et les autres mécanismes d'authentification dont vous avez besoin.

Vous devriez maintenant être capable de vous connecter en utilisant les informations d'identification basées sur LDAP.

Les clients LDAP devront se référer à plusieurs serveurs si la réplication est en cours d'utilisation. Dans /etc/ldap.conf, vous devriez avoir quelque chose comme :

uri ldap://ldap01.example.com ldap://ldap02.example.com

The request will time out and the Consumer (ldap02) will attempt to be reached if the Provider (ldap01) becomes unresponsive.

Si vous envisagez d'utiliser LDAP pour stocker les utilisateurs Samba, vous devrez configurer le serveur Samba pour qu'il s'authentifie en utilisant LDAP. Voir Samba et LDAP pour plus de détails.

The ldap-utils package comes with enough utilities to manage the directory but the long string of options needed can make them a burden to use. The ldapscripts package contains wrapper scripts to these utilities that some people find easier to use.

Installez le paquet :

sudo apt-get install ldapscripts

Puis éditez le fichier /etc/ldapscripts/ldapscripts.conf pour arriver à quelque chose de semblable à ce qui suit :

SERVER=localhost
BINDDN='cn=admin,dc=example,dc=com'
BINDPWDFILE="/etc/ldapscripts/ldapscripts.passwd"
SUFFIX='dc=example,dc=com'
GSUFFIX='ou=Groups'
USUFFIX='ou=People'
MSUFFIX='ou=Computers'
GIDSTART=10000
UIDSTART=10000
MIDSTART=10000

Maintenant, créez le fichier ldapscripts.passwd pour permettre l'accès de rootDN au répertoire :

sudo sh -c "echo -n 'secret' > /etc/ldapscripts/ldapscripts.passwd"
sudo chmod 400 /etc/ldapscripts/ldapscripts.passwd

Les scripts sont maintenant prêts à vous aider à gérer votre répertoire. Voici quelques exemples de la façon de les utiliser :

Il existe des utilitaires dans le paquet qui n'ont pas été abordés ici. En voici la liste complète :

ldaprenamemachine
ldapadduser
ldapdeleteuserfromgroup
ldapfinger
ldapid
ldapgid
ldapmodifyuser
ldaprenameuser
lsldap
ldapaddusertogroup
ldapsetpasswd
ldapinit
ldapaddgroup
ldapdeletegroup
ldapmodifygroup
ldapdeletemachine
ldaprenamegroup
ldapaddmachine
ldapmodifymachine
ldapsetprimarygroup
ldapdeleteuser

ldap tourne maintenant tout juste comme nous le voulons, il est temps de s'assurer que nous pouvons enregistrer l'ensemble de notre travail et le restaurer si nécessaire.

What we need is a way to backup the ldap database(s), specifically the backend (cn=config) and frontend (dc=example,dc=com). If we are going to backup those databases into, say, /export/backup, we could use slapcat as shown in the following script, called /usr/local/bin/ldapbackup:

#!/bin/bash

BACKUP_PATH=/export/backup
SLAPCAT=/usr/sbin/slapcat

nice ${SLAPCAT} -n 0 > ${BACKUP_PATH}/config.ldif
nice ${SLAPCAT} -n 1 > ${BACKUP_PATH}/example.com.ldif
nice ${SLAPCAT} -n 2 > ${BACKUP_PATH}/access.ldif
chmod 640 ${BACKUP_PATH}/*.ldif

Then, it is just a matter of having a cron script to run this program as often as we feel comfortable with. For many, once a day suffices. For others, more often is required. Here is an example of a cron script called /etc/cron.d/ldapbackup that is run every night at 22:45h:

MAILTO=backup-emails@domain.com
45 22 * * *  root    /usr/local/bin/ldapbackup

Les fichiers étant créés, ils doivent être copiés sur un serveur de sauvegarde.

En supposant que nous ayons fait une réinstallation fraîche de ldap, le processus de restauration pourrait être quelque chose comme ceci :

sudo service slapd stop
sudo mkdir /var/lib/ldap/accesslog
sudo slapadd -F /etc/ldap/slapd.d -n 0 -l /export/backup/config.ldif
sudo slapadd -F /etc/ldap/slapd.d -n 1 -l /export/backup/domain.com.ldif
sudo slapadd -F /etc/ldap/slapd.d -n 2 -l /export/backup/access.ldif
sudo chown -R openldap:openldap /etc/ldap/slapd.d/
sudo chown -R openldap:openldap /var/lib/ldap/
sudo service slapd start