Contenu | Rechercher | Menus

OpenLDAP

OpenLDAP est une implémentation libre du protocole LDAP Lightweight Directory Access Protocol.

LDAP est un protocole TCP/IP, version simplifiée du protocole OSI X.500. Il permet d'accéder à un annuaire.

Un annuaire peut contenir par exemple :

  • des adresses mails
  • des liens
  • des comptes utilisateurs
  • en règle générale toute données majoritairement servies en lecture seule

et peut être utilisé par :

  • le système d'exploitation pour l'authentification de ses utilisateurs,
  • par des applications web
  • par un MUA (Thunderbird par exemple) pour son carnet d'adresse
  • etc.

La version actuelle du protocole est la version LDAPv3. Les versions récentes d'OpenLDAP intègrent la configuration directement dans leur base de données, permettant ainsi les changements à chaud.

Voici certains concepts et mots clefs qui seront utilisés plus bas :

  • Un annuaire LDAP est un arbre de données hiérarchique (appelé DIT pour Directory Information Tree)
  • Une entrée de cet arbre est composé d'attributs
  • Un attribut est composé d'un type (un nom ou une description) et d'une ou plusieurs valeurs
  • Chaque attribut doit être défini dans au moins une classe d'objets pour pouvoir être utilisé
  • Les attributs et les classes d'objets sont définis dans des schémas
  • Chaque entrée dispose d'une identifier unique, appelé "Distinguished Name" (noté DN ou dn).

Les termes objets, conteneurs et nœuds ont des connotations spéciales, mais sont identiques au terme entrée, qu'il faut privilégier.

OpenLDAP utilise pour ses interactions avec l'administrateur, ou éventuellement pour échanger avec d'autres serveurs LDAP, le format de fichier LDIF (LDAP Data Interchange Format). Toute information contenue dans le DIT peut être décrite dans ce format. Il est, de ce fait, incontournable pour l'administrateur.

Un fichier LDIF ressemble à l'exemple ci-dessous :

dn: cn=David Vincent,dc=ubuntu-fr,dc=lan
  cn: David Vincent
  givenName: David
  sn: Vincent
  telephoneNumber: +0033 20 99 88 77
  mail: david.vincent@ubuntu-fr.lan
  manager: cn=Will Smith,dc=ubuntu-fr,dc=lan
  objectClass: inetOrgPerson
  objectClass: organizationalPerson
  objectClass: person
  objectClass: top

On peut, à l'aide de simples fichiers textes LDIF, totalement interagir avec le serveur OpenLDAP, et ajouter, modifier ou supprimer des entrées, de la configuration du serveur ou de l'annuaire en lui-même.

D'autres implémentations de LDAP peuvent être intéressantes à tester, comme 389 Directory Server (Red Hat), qui vient avec sa console d'administration multi-plateforme. 389DS permet notamment la synchronisation avec un serveur Microsoft Active Directory, et la configuration du serveur en mode graphique. L'installation et la configuration sont très bien documentées (en anglais).

Pré-requis

L'installation du paquet slapd mettra en place une configuration fonctionnelle, avec notamment l'instance de base de données pour stocker nos données. Le suffixe utilisé pour cette instance est déterminé par le nom de domaine de la machine locale. Si le suffixe désiré n'est pas le suffixe DNS de la machine, il faut alors le changer dans le fichier /etc/hosts. Dans tous les cas, le suffixe peut être changé après l'installation, en saisissant dans un terminal la commande suivante :

dpkg-reconfigure slapd

Dans notre cas, le serveur répondra au suffixe ubuntu-fr.lan, configurez le fichier /etc/hosts comme suit :

127.0.1.1       ldap01.ubuntu-fr.lan	ldap01

Le tiret de ubuntu-fr devrait ne pas plaire à l'installeur. Il devrait vous afficher un message d'erreur, que vous pouvez ignorer, le service fonctionnera quand même.

Installation

Installez le daemon du serveur OpenLDAP, slapd ainsi que les scripts d'administration ldap-utils couramment utilisés.

Deux bases de données vont être automatiquement créés pendant le processus d'installation : la base contenant l'arbre de configuration, et une seconde contenant l'arbre de données du serveur.

Pendant l'installation, un mot de passe est demandé pour le "rootDN". Cet utilisateur dispose de tous les droits sur l'arbre de données, et uniquement sur l'arbre de données, puisqu'il n'existe pas dans l'arbre de configuration. Son DN est par défaut : cn=admin,dc=ubuntu-fr,dc=lan). Vous utiliserez par la suite ce DN pour vous connecter en tant qu'administrateur de l'arbre de données.

Les schémas classiques (cosine, nis, inetorgperson) sont pré-configurés par défaut, de même que le schéma "core", un prérequis pour tous les autres schémas.

L'arbre de configuration cn=config

Contrairement aux versions précédentes, la partie configuration d'openldap ne se situe plus dans des fichiers, mais directement dans une base de données distincte des enregistrements du serveur : l'arbre cn=config. Cet arbre peut être modifié à chaud, sans avoir à redémarrer le service pour prendre en compte les changements, ce qui peut être un avantage, mais qui, en cas d'erreurs de configuration, peut tout simplement empêcher le redémarrage du service.

L'interaction avec l'arbre de configuration, se fait bien entendu avec les scripts ldap et les fichiers ldif.

Il n'y a pas de compte d'administration "rootDN" pour l'arbre de configuration. Il faut donc s'authentifier d'une manière externe pour y accéder.

Tests de bon fonctionnement

Le bon fonctionnement du serveur peut être testé à l'aide de ces deux commandes :

sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn

devrait répondre :

dn: cn=config
 
dn: cn=module{0},cn=config
 
dn: cn=schema,cn=config
 
dn: cn={0}core,cn=schema,cn=config
 
dn: cn={1}cosine,cn=schema,cn=config
 
dn: cn={2}nis,cn=schema,cn=config
 
dn: cn={3}inetorgperson,cn=schema,cn=config
 
dn: olcBackend={0}hdb,cn=config
 
dn: olcDatabase={-1}frontend,cn=config
 
dn: olcDatabase={0}config,cn=config
 
dn: olcDatabase={1}hdb,cn=config

et

ldapsearch -x -LLL -H ldap:/// -b dc=ubuntu-fr,dc=lan dn

répondra :

dn: dc=ubuntu-fr,dc=lan
 
dn: cn=admin,dc=ubuntu-fr,dc=lan

Les options de la commande ldapsearch permettent :

  1. x : de ne pas utiliser la méthode d'authentification SASL, qui est la valeur par défaut.
  2. LLL: de désactiver l'impression LDIF des informations de schéma.

Peupler la base

Il est temps d'ajouter du contenu dans l'annuaire.

Vous pouvez ajouter :

  • un noeud "People", pour contenir les utilisateurs
  • un noeud "Groups", pour contenir les groupes d'utilisateurs

pour organiser le contenu de votre annuaire.

Ces deux noeuds seront du type organizationalUnit (ou).

Pour cela, créez un fichier ou-base.ldif contenant :

dn: ou=People,dc=ubuntu-fr,dc=lan
objectClass: organizationalUnit
ou: People

dn: ou=Groups,dc=ubuntu-fr,dc=lan
objectClass: organizationalUnit
ou: Groups

puis ajouter ces deux OU à l'aide de la commande ldapadd :

ldapadd -x -D cn=admin,dc=ubuntu-fr,dc=lan -W -f ou-base.ldif
 
Enter LDAP Password: ********
adding new entry "ou=People,dc=ubuntu-fr,dc=lan"
 
adding new entry "ou=Groups,dc=ubuntu-fr,dc=lan"

Vous pouvez vérifier que ce contenu est bien ajouté dans la base avec la commande ldapsearch vue précédemment.

Maintenant que vous disposez de conteneurs, vous pouvez y ajouter des utilisateurs et des groupes, de la même façon que vous avez utilisé des UO.

Créez le fichier users.ldif :

dn: cn=contributeurs,ou=Groups,dc=ubuntu-fr,dc=lan
objectClass: posixGroup
cn: contributeurs
gidNumber: 5000

dn: uid=mickael,ou=People,dc=ubuntu-fr,dc=lan
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: Mickael
sn: Vendetta
givenName: Mickael
cn: Vendetta
displayName: Mickael Vendetta
uidNumber: 10000
gidNumber: 5000
userPassword: secret
gecos: Mickael Vendetta
loginShell: /bin/bash
homeDirectory: /home/mickael.vendetta

De la même façon que ci-dessus, ajoutez le contenu de ce fichier au serveur :

ldapadd -x -D cn=admin,dc=ubuntu-fr,dc=lan -W -f users.ldif
 
Enter LDAP Password: ********
adding new entry "cn=contributeurs,ou=Groups,dc=ubuntu-fr,dc=lan"
 
adding new entry "uid=mickael,ou=People,dc=ubuntu-fr,dc=lan"

A propos des UID et des GID Les UID et GID utilisés dans l'annuaire LDAP ne doivent pas être identiques au UID et GID de l'ordinateur local. C'est pourquoi il est préférable d'utiliser des valeurs commençant par exemple à 5000. Par la suite, les utilisateurs ou les groupes LDAP pourront également être facilement identifiés par la valeur très élevée de leur UID/GID.

L'utilisateur créé ci-dessus implémente les objectClass posixAccount et shadowAccount. En effet, si l'objectClass shadowAccount n'est pas implémenté, le système distant ne pourra pas connecter l'utilisateur.

Sécuriser le serveur

Un client peut se connecter de 3 façons sur le serveur :

  • en clair, sur le port 389, ce qui n'est pas raisonnable lors du transfert de mot de passe ou de données sensibles
  • en chiffré, sur le port 636, méthode qui est dépréciée
  • en chiffré, sur le port 389, avec le STARTTLS, qui permet le passage en mode crypté de la session à n'importe quel moment. Un des avantages certain de cette méthode est de n'ouvrir qu'un seul port, le 389, pour toutes les connexions, cryptée ou non.

TLS nécessite un certificat pour le serveur, signé par une autorité de certification. Faire signer son certificat par une autorité à un coût, il est alors possible de créer sa propre autorité de certification (CA), et de signer soit même ses certificats. Le revers de la médaille (et de la gratuité), sera d'obligatoirement déployer sur chaque client le certificat de la CA.

Il faut donc être conscient de deux choses lors de la mise en place de TLS :

  • le certificat de la CA doit être présent sur tous les clients,
  • le FQDN utilisé à la génération du certificat doit impérativement être celui que les clients utiliseront lors des accès au serveur, sinon le certificat du serveur ne sera pas reconnu.

Génération des certificats auto-signés

Utilisez les utilitaires certtool pour accomplir cette tâche :

sudo apt-get install gnutls-bin ssl-cert

La clef de l'autorité de certification

Créez la clef privée pour l'autorité de certification :

sudo sh -c "certtool --generate-privkey > /etc/ssl/private/cakey.pem"

Ce fichier est critique d'un point de vue sécurité. En effet, tout certificat généré par lui sera automatiquement valide pour tous vos clients, et vous en aurez peut être besoin pour créer d'autres certificats pour d'autres services dans le futur, sans devoir redéployer sur chaque client une seconde autorité de certification. Il s'agit donc de le sauvegarder et le conserver en lieu sûr !

Créez ensuite un fichier modèle pour définir la CA : /etc/ssl/ca.info

cn = Ubuntu FR
ca
cert_signing_key

Ce fichier sera réutilisé par les utilitaires certtool.

Créez le certificat auto-signé de la CA

sudo certtool --generate-self-signed \
  --load-privkey /etc/ssl/private/cakey.pem \ 
  --template /etc/ssl/ca.info \
  --outfile /etc/ssl/certs/cacert.pem

Ce fichier cacert.pem est le fichier à déployer sur l'ensemble des clients du serveur. Vous pouvez retrouver ce fichier nommé cacert.asc selon la distribution linux du client.

La clef privée du serveur

Il faut générer pour chaque serveur une clef et la signer avec la clef de la CA.

Créez une clef privée :

sudo certtool --generate-privkey \
  --bits 1024 \
  --outfile /etc/ssl/private/ldap01_slapd_key.pem

Remplacer ldap01 par le nom de votre serveur. Il est recommandé de nommer les certificats avec les noms des hôtes pour lesquels ils sont destinés et leur fonction pour les reconnaître plus facilement.

A la manière de la CA, vous allez maintenant créer un fichier info qui contiendra les informations propres à ce certificat : Fichier : /etc/ssl/ldap01.info

organization = Ubuntu-fr
cn = ldap01.ubuntu-fr.lan
tls_www_server
encryption_key
signing_key
expiration_days = 3650
  • La ligne cn, doit contenir le nom du serveur qui sera utilisé par les clients, le plus simple étant le nom DNS.
  • La ligne expiration_days est réglée pour 10 ans, vous pouvez l'ajuster à vos besoins.

Créez maintenant le certificat du serveur :

sudo certtool --generate-certificate \
  --load-privkey /etc/ssl/private/ldap01_slapd_key.pem \
  --load-ca-certificate /etc/ssl/certs/cacert.pem \
  --load-ca-privkey /etc/ssl/private/cakey.pem \
  --template /etc/ssl/ldap01.info \
  --outfile /etc/ssl/certs/ldap01_slapd_cert.pem

Application du certificat au serveur

Pour appliquer ce certificat au serveur, créez un fichier ldif /etc/ssl/certinfo.ldif. Cette fois-ci, c'est la base de configuration du serveur qui est visée.

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

et appliquez ces changements :

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

Pour accéder au serveur en TLS, et contrairement à ce que l'on peut penser, il n'y a pas besoin d'utiliser le protocole ldaps:, mais bien uniquement ldap:.

Reste à appliquer les permissions adéquates sur les fichiers sensibles et redémarrer le service :

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
sudo service slapd restart

Vérifiez les logs (/var/log/syslog) pour voir si le service à correctement démarré.

Vérifications

Pour se connecter au serveur LDAP en TLS, ajoutez l'option -ZZ aux commandes ldap, pour forcer la connexion en TLS.

A ce stade, si vous tapez notre commande :

ldapsearch -ZZ -x -LLL -H ldap:/// -b dc=ubuntu-fr,dc=lan dn

vous obtiendrez un message d'erreur inconnue.

Il faut configurer le client ldap pour qu'il utilise le certificat de notre CA. Le fichier /etc/ldap/ldap.conf doit maintenant ressembler à ceci :

#
# LDAP Defaults
#

BASE     dc=ubuntu-fr,dc=lan
URI        ldap://ldap01.ubuntu-fr.lan

SIZELIMIT    12
TIMELIMIT   15
DEREF         NEVER

TLS_CA_CERT    /etc/ssl/certs/cacert.pem

et vérifier la présence de ce fichier dans votre répertoire :

ls /etc/ssl/certs/cacert.pem

Authentification des postes clients par LDAP

Pour utiliser l'authentification LDAP sur les postes clients, il faut configurer pam et nsswitch. Les distributions actuelles prennent en charge la configuration automatique de ces deux services.

Avant de pouvoir utiliser le service LDAP, le fichier /etc/ldap/ldap.conf doit avoir été configuré sur le client comme vu précédemment, et le certificat de la CA copié en local.

Le méta-package ldap-auth-client va installer les packages nécessaires à notre configuration. Il est également fortement conseillé de conserver le service nscd démarré.

sudo apt-get install ldap-auth-client nscd
sudo auth-client-config -t nss -p lac_ldap

On peut vérifier que le client reconnaît maintenant nos utilisateurs LDAP avec la commande :

getent passwd

qui doit laisser apparaître notre nouvel utilisateur.

Pour utiliser l'authentification LDAP dans sa version sécurisée, il faut modifier le fichier /etc/ldap.conf, cette fois-ci, qui a été créé pendant l'installation du métapackage ldap-auth-client. Décommentez les lignes :

ssl start_tls
tls_cacertdir /etc/ssl/certs/

Un reboot du poste client devrait permettre l'authentification des nouveaux utilisateurs.

Chez RedHat, c'est le programme system-config-auth qui permet la configuration automatique de l'authentification. Il faut également modifier les fichiers /etc/openldap/ldap.conf et le fichier /etc/ldap.conf (à vérifier) comme expliqué ci-dessus.

Erreurs connues

Indexation de la base

Dans le log /etc/log/syslog, des messages relatifs à l'indexation LDAP apparaissent. Par défaut, le serveur n'indexe que les objectClass et les cn.

Créer le fichier indexchanges.ldif suivant :

dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcDbIndex
olcDbIndex: uid,uidNumber,gidNumber,memberUid,uniqueMember,objectClass,cn eq

Et appliquer les changements à notre base :

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

Interfaces graphiques et outils d'administration

Voir aussi

—- Contributeurs principaux : lmrv,

Basé sur Ubuntu Server Guide > OpenLDAP Server.


utilisateurs/lmrv/openldap.txt · Dernière modification: Le 08/09/2012, 08:30 par lmrv
Le contenu de ce wiki est sous licence : CC BY-SA v3.0