LDAP permet la centralisation de l'authentification et ce quelque soit le service proposé (ftp, ssh, boîte mail, …). Outre l'avantage de la centralisation, les utilisateurs ne possèdent qu'un seul mot de passe pour accéder à l'ensemble des services qui leur sont offerts.

Cet article se limite à la mise en place de l'authentification système basée sur LDAP pour des systèmes Linux et FreeBSD.

Structure :

• Nous supposerons que la racine du serveur LDAP est dc=julp,dc=com.
• Constituée de deux OU (une pour les groupes et une pour les utilisateurs)

Quelques uns des environnements ayant servis de base quant à la rédaction du présent article :

• Debian 4.0, 5.0
• Gentoo 2007.0, 2008.0
• NetBSD 3.1, 4.0.1
• FreeBSD 6.2, 7.1
• OpenBSD 4.1

Notes :

• TODO :

  * Mettre un avertissement pour l'ajout du droit en écriture sur l'annuaire pour l'utilisateur proxy (pour passwd)
  * ACL : les attributs shadow*, objectclass et homeDirectory en lecure seule pour les utilisateurs
      => seuls userPassword, gecos, description, loginShell en écriture ?
  * Le changement de mot de passe par la commande passwd n'est opérationnel que pour root (uid effectif du processus à 0, rootbinddn, fichier ldap.secret) sur NetBSD (FreeBSD c'est OK)
  * La réplication : préciser le répertoire par défaut du système des données de slurpd + supprimer la partie relative au processus slapd esclave (elle ne présente aucun intérêt puisqu'il n'y aucune modification)

• NSS/PAM (fait - à conserver) :

  A. L'authentification à LDAP pour PAM/NSS
  * défaut : connexion anonyme
  * binddn/bindpw : information en clair pour l'authentification
  * rootbinddn : quand uid effectif est 0, le mot de passe est cherché dans le fichier ldap.secret
      ce qui permet de cacher cette information (les fichiers pam_ldap.conf/nss_ldap.conf étant
      lisibles par tous)
  Dernière solution que j'utilise dans le simple but de cacher autant que possible les mots
  de passe et ainsi éviter toute attaque par dictionnaire voire par force brute. Remarquez
  que je n'ai donné que des droits en lecture à cet utilisateur.
  
  B. Le caractère facultatif (pratique) de NSS
  (il n'est pas vital mais il est nécessaire lorsque le système aura besoin de traduire
  le login en identifiant : c'est le cas de la commande passwd, chown/chgrp à partir du
  login voir de la complétion de votre shell à ce niveau)

• Récapitulatif Debian :

  Récapitulatif :
  * Le fichier de configuration de NSS-LDAP est : /etc/libnss-ldap.conf
  * Le fichier secret pour NSS-LDAP est : /etc/libnss-ldap.secret
  
  * Le fichier de configuration de PAM-LDAP est : /etc/pam_ldap.conf
  * Le fichier secret pour PAM-LDAP est : /etc/pam_ldap.secret
  
  /!\ Si on lie les fichiers de configuration de nss, pam et du client
  la configuration du paquet n'est plus nécessaire ou seulement une fois.
  De plus, nss n'ayant pas besoin de droits particuliers, une authentification
  anonyme lui convient tout à fait (on en revient plus ou moins au cas de NetBSD)

Nous établirons, ici, les ACL de telle manière que :

• l'accès aux mots de passe, même s'ils sont hashés, soit restreint au mieux. C'est à dire interdire l'accès anonyme à l'attribut userPassword sans pour autant en empêcher la modification par l'utilisateur lui-même lorsqu'il souhaite en changer ;
• bloquer tout changement et en particulier tous les champs de type shadow ou encore l'uidNumber qui, ramené à une valeur nulle, donnerait tous les droits sur tous les clients (usurpation de l'identité root) ;
• donner accès en lecture à tout le monde, connexion anonyme comprise, à toute autre donnée, jugées non sensibles.

Nous aboutissons donc aux règles suivantes :

# Le mot de passe :
# - modifiable par l'administrateur LDAP
# - lisible de l'utilisateur "proxy" pour réaliser les authentifications
# - modifiable de l'utilisateur lui-même
# - lisible lors d'une tentative d'authentification à LDAP
# - inaccessible à tout autre cas
access to attrs=userPassword
        by dn="cn=manager,dc=julp,dc=com" write
        by dn="cn=proxyuser,dc=julp,dc=com" read
        by self write
        by anonymous auth
        by * none

# Le shell :
# - modifiable par l'administrateur LDAP
# - modifiable de l'utilisateur lui-même
# - lisible de tous
access to attrs=loginShell
        by dn="cn=manager,dc=julp,dc=com" write
        by self write
        by * read

# Le reste d'annuaire :
# - modifiable par l'administrateur LDAP 
# - lisible de tous
access to *
        by dn="cn=manager,dc=julp,dc=com" write
        by * read

Nous aurons besoin des paquets correspondants au serveur OpenLDAP ainsi que des utilitaires client console de base :

# Le serveur
apt-get install slapd

# Les clients en ligne de commande (ldapsearch & co)
apt-get install ldap-utils

Cette première installation, du serveur, doit normalement aboutir à une interface comme celle ci-dessous où il vous est offert de configurer votre annuaire en quelques points. Il est recommandé de recourir à présent à cette aide surtout si vous n'êtes pas familier avec la configuration de ce service. Les différentes étapes y sont détaillées.

Modifiez le fichier de configuration du serveur, /etc/ldap/slapd.conf, pour qu'il ressemble à celui-ci : décommenter le manager

Assurez-vous que son démarrage se fera automatiquement :

update-rc.d slapd start 19 2 3 4 5 . stop 80 0 1 6 .

Vérifiez que les permissions du répertoire où est entroposée la base de données sont correctes sinon corrigez-les :

chmod -R u=rwx,go= /var/lib/ldap
chmod -R openldap:openldap /var/lib/ldap

Si vous avez modifié la configuration du serveur et étant normalement déjà en activité, il serait alors bon de le redémarrer :

/etc/init.d/slapd restart

Nous pouvons à présent procéder à l'insertion des objets de notre jeu de test que vous pourrez trouver en fin du présent document.

ldapadd -c -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif

Le gestionnaire de paquets ayant normalement réalisé la création de l'objet racine (voir captures ci-dessus et plus précisément les étapes 2 et 3), nous ajoutons l'option c à notre ligne de commande pour que la tentative de les recréer ne bloque pas l'insertion des autres entrées.

Avant de compiler OpenLDAP, définissez éventuellement vos paramètres USE (de manière permanente via le fichier /etc/portage/package.use). La commande emerge -pv net-nds/openldap vous en donnera la liste. Exemple :

net-nds/openldap berkdb crypt ipv6 overlays readline ssl tcpd -debug -gdbm -kerberos -minimal -odbc -perl -samba -sasl -slp -smbkrb5passwd

Ceci fait, compilez/installez OpenLDAP :

emerge net-nds/openldap

Mettez en place votre configuration en modifiant /etc/openldap/slapd.conf sur ce modèle :

# Schémas de base
include        /etc/openldap/schema/core.schema
# Schémas requis pour les comptes Posix
include        /etc/openldap/schema/cosine.schema
include        /etc/openldap/schema/inetorgperson.schema
include        /etc/openldap/schema/nis.schema

# Fichiers nécessaires au bon fonctionnement de LDAP
pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

# Modules dynamiques de backend
# modulepath    /usr/lib/openldap/openldap
# moduleload    back_shell.so
# moduleload    back_relay.so
# moduleload    back_passwd.so
# moduleload    back_null.so
# moduleload    back_monitor.so
# moduleload    back_meta.so
# moduleload    back_hdb.so
# moduleload    back_dnssrv.so


##### Les règles d'accès aux données (ou ACL pour les intimes) #####
##### Recopiez celles qui sont données en première partie #####


# Système de stockage utilisé en arrière-plan
database    bdb
# Racine de l'annuaire
suffix      "dc=julp,dc=com"
# Nom distingué du manager LDAP pour accéder à l'annuaire
rootdn      "cn=manager,dc=julp,dc=com"
# Son mot de passe en clair ou crypté via la commande slappasswd
# Ici "secret", sous forme hashée, obtenue par la commande "slappasswd -h '{MD5}'"
rootpw      {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
# Emplacement des fichiers de stockage des données
directory   /var/lib/openldap-data

# Les attributs indexés
index    objectClass              eq
index    cn,sn,uid,displayName    pres,sub,eq
index    uidNumber,gidNumber      eq

Vous souhaiterez maintenant sans doute que l'annuaire soit démarré de manière automatique lorsque la machine sera (re)bootée :

rc-update add slapd default

Avant le premier démarrage d'OpenLDAP, nous procéderons à une vérification des permissions de la base de données :

chmod -R u=rwx,go= /var/lib/openldap-data
chown -R ldap:ldap /var/lib/openldap-data

À présent, nous pouvons enfin démarrer notre annuaire …

/etc/init.d/slapd start

… puis y ajouter quelques données que vous pourrez trouver en annexe :

ldapadd -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif

Les ports utilisés par défaut par LDAP sont :

• le port 636 pour les connexions (tcp) SSL (protocole LDAPS)
• le port 389 pour les connexions (tcp) non sécurisées ou sécurisées utilisant TLS (protocole LDAP)

Pour les utilisateurs de Packet Filter qui veulent autoriser les requêtes LDAP et LDAPS entrantes et leurs réponses, voici la règle à ajouter :

##### Macros #####
if = "fxp0" # Votre interface
clients_ldap = "fxp0:network" # Vos clients LDAP, ici ceux de notre réseau
tcpflags = "flags S/SFRA"

##### Options #####
set skip on lo0

##### Règles #####
# Par défaut tout bloquer et logguer
block log

# ...

# LDAP et LDAPS
pass in quick on $if inet proto tcp from $clients_ldap \
    to $if port { ldap ldaps } $tcpflags keep state

# ...

L'installation de l'annuaire se déroule ainsi, le système de logiciels portés se chargera pour nous des dépendances :

cd /usr/ports/net/openldap<version>-server
# On procède à la configuration
make config
# Puis à la compilation/installation 
make install

# Création de liens symboliques nécessaires au bon fonctionnement du client LDAP
ln -s /usr/local/etc/openldap/ldap.conf /usr/local/etc/ldap.conf
ln -s /usr/local/etc/openldap/ldap.conf /etc/ldap.conf

# Utilisation d'une configuration par défaut concernant Berkeley DB (environnement)
cp /usr/local/etc/openldap/DB_CONFIG.example /var/db/openldap-data/DB_CONFIG

Prenez dans la mesure du possible la dernière version stable disponible.

Les options de compilation du logiciel porté (make config) correspondant au serveur LDAP vous mènera à cette interface :

Attention :

• Sélectionnez soigneusement les options en fonction de vos besoins et notez-les dans un coin si besoin. Certaines, dont DYNAMIC_BACKENDS, interviendront lors de la configuration. Nous aurons, bien entendu, l'occasion d'y revenir par la suite. Si vous ne savez pas à quoi elles correspondent, conservez les paramètres par défaut.
• Si la version d'OpenLDAP employée par défaut par les logiciels portés est différente de celle que vous avez choisi alors il peut apparaître qu'il vous demande cette première comme dépendance lors de nouvelles installations de logiciels portés. Vous pouvez toutefois, dans une telle situation, faire prévaloir la vôtre en la forçant par l'ajout de la ligne suivante dans votre fichier /etc/make.conf :

  WANT_OPENLDAP_VER=24 # Ici pour forcer l'utilisation de la branche 2.4 d'OpenLDAP

Pour plus de commodités, nous allons démarrer le serveur LDAP au démarrage de la machine. Pour cela rajouter les lignes ci-dessous à votre fichier /etc/rc.conf :

# LDAP
slapd_enable="YES"
slapd_flags="-h ldap://<votre adresse IP réseau>" # Ou plus simplement : slapd_flags="-h ldap:///"

Vous trouverez ci-dessous un fichier de configuration du serveur LDAP (/usr/local/etc/openldap/slapd.conf) commenté.

# Schémas de base
include        /usr/local/etc/openldap/schema/core.schema
# Schémas requis pour les comptes Posix
include        /usr/local/etc/openldap/schema/cosine.schema
include        /usr/local/etc/openldap/schema/inetorgperson.schema
include        /usr/local/etc/openldap/schema/nis.schema

# Modules 
# Si vous avez sélectionné l'option dynamic_backends décommentez ces deux-lignes
#modulepath     /usr/local/libexec/openldap
#moduleload     back_bdb

# Fichiers nécessaires au bon fonctionnement de LDAP
pidfile        /var/run/openldap/slapd.pid
argsfile       /var/run/openldap/slapd.args


##### Les règles d'accès aux données (ou ACL pour les intimes) #####
##### Recopiez celles qui sont données en première partie #####


# Système de stockage utilisé en arrière-plan
database    bdb
# Racine de l'annuaire
suffix      "dc=julp,dc=com"
# Nom distingué du manager LDAP pour accéder à l'annuaire
rootdn      "cn=manager,dc=julp,dc=com"
# Son mot de passe en clair ou crypté via la commande slappasswd
# Ici "secret", sous forme hashée, obtenue par la commande "slappasswd -h '{MD5}'"
rootpw      {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
# Emplacement des fichiers de stockage des données
directory   /var/db/openldap-data

# Les attributs indexés
index    objectClass              eq
index    cn,sn,uid,displayName    pres,sub,eq
index    uidNumber,gidNumber      eq

Attention : Si lors de la configuration du logiciel porté vous avez coché l'option DYNAMIC_BACKENDS (Build dynamic backends), la petite partie commentée comportant les directives modulepath et moduleload doit être restaurée sinon votre serveur ne fonctionnera pas !

L'ultime étape avant le démarrage du serveur LDAP afin d'assurer son bon fonctionnement est de modifier le propriétaire des fichiers où sont stockées les données. Le dossier correspondant est désigné par directory (valeur par défaut : /var/db/openldap-data) dans votre fichier /usr/local/etc/openldap/slapd.conf. Voici donc la commande à exécuter :

# Modifier le path selon votre configuration si besoin
chmod -R u=rwx,go= /var/db/openldap-data
chown -R ldap:ldap /var/db/openldap-data

Tout est désormais prêt pour le démarrage du serveur LDAP :

/usr/local/etc/rc.d/slapd start

Importez le jeu de test (qui serait ici stocké dans un fichier sous le nom de test.ldif), ce qui nous permettra de contrôler le bon fonctionnement de l'annuaire :

ldapadd -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif

Après avoir pris connaissance des différentes options disponibles à l'aide de la commande make show-options lancée dans le répertoire du logiciel porté correspondant, ajoutez celles que vous désirez au niveau de /etc/mk.conf. Exemple :

PKG_OPTIONS.openldap-client= inet6
PKG_OPTIONS.openldap-server= bdb inet6

Puis passez à la compilation :

cd /usr/pkgsrc/databases/openldap-client/
make install

cd /usr/pkgsrc/databases/openldap-server/
make install

Si vous n'avez pas défini la variable PKG_RCD_SCRIPTS à YES dans le fichier /etc/mk.conf, vous devrez vous-même copier les scripts rc.d de gestion de l'annuaire :

cp /usr/local/share/examples/rc.d/slapd /etc/rc.d/

Éditez /etc/rc.conf pour le démarrage automatique de l'annuaire :

slapd=YES

Configurez l'ensemble du serveur au travers de /usr/pkg/etc/openldap/slapd.conf devant à présent s'approcher de celui ci-dessous :

# Schémas de base
include        /usr/pkg/etc/openldap/schema/core.schema
# Schémas requis pour les comptes Posix
include        /usr/pkg/etc/openldap/schema/cosine.schema
include        /usr/pkg/etc/openldap/schema/inetorgperson.schema
include        /usr/pkg/etc/openldap/schema/nis.schema

# Fichiers nécessaires au bon fonctionnement de LDAP
pidfile        /var/openldap/run/slapd.pid
argsfile       /var/openldap/run/slapd.args


##### Les règles d'accès aux données (ou ACL pour les intimes) #####
##### Recopiez celles qui sont données en première partie #####


# Système de stockage utilisé en arrière-plan
database    bdb
# Racine de l'annuaire
suffix      "dc=julp,dc=com"
# Nom distingué du manager LDAP pour accéder à l'annuaire
rootdn      "cn=manager,dc=julp,dc=com"
# Son mot de passe en clair ou crypté via la commande slappasswd
# Ici "secret", sous forme hashée, obtenue par la commande "slappasswd -h '{MD5}'"
rootpw      {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
# Emplacement des fichiers de stockage des données
directory   /var/openldap/openldap-data

# Les attributs indexés
index    objectClass              eq
index    cn,sn,uid,displayName    pres,sub,eq
index    uidNumber,gidNumber      eq

Vérifiez que les permissions sur le répertoire de la base sont correctes :

# Modifier le path selon votre configuration si besoin
chmod -R u=rwx,go= /var/openldap/openldap-data
chown -R slapd:ldap /var/openldap/openldap-data

Démarrez l'annuaire :

/etc/rc.d/slapd start

Procédez enfin à l'insertion des données de notre jeu de test :

ldapadd -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif

Installez le client ainsi que le serveur LDAP à l'aide des paquets binaires :

# (ba|k)sh
export PKG_PATH=ftp://ftp.fr.openbsd.org/pub/OpenBSD/`uname -r`/packages/`machine -a`/
# (t)csh
setenv PKG_PATH "ftp://ftp.fr.openbsd.org/pub/OpenBSD/`uname -r`/packages/`machine -a`/"

# Installation du client
pkg_add openldap_client
# Installation du serveur
pkg_add openldap-server

Éventuellement, si vous préférez recourir aux logiciels portés, la procédure est la suivante :

cd /usr/ports/databases/openldap
env SUBPACKAGE="-server" FLAVOR="bdb" make install clean

Afin d'exécuter le démon slapd au démarrage de la machine nous devons modifier le fichier /etc/rc.local :

# OpenLDAP
SLAPDCONF='/etc/openldap/slapd.conf'
if [ -f $SLAPDCONF -a -x /usr/local/libexec/slapd ]; then
    if grep -q "^[[:space:]]*TLS" $SLAPDCONF; then
        echo -n " slapd(ldap + ldaps) "; /usr/local/libexec/slapd -h ldap:/// ldaps:///
    else
        echo -n " slapd(ldap) "; /usr/local/libexec/slapd
    fi
fi

Il faudra également réaliser l'opération inverse, à savoir mettre fin à celui-ci lors du processus d'extinction. Pour ce faire, nous complétons le fichier /etc/rc.shutdown de la manière suivante :

# OpenLDAP
if [ -r /var/run/slapd.pid ]; then
    kill `cat /var/run/slapd.pid`
fi

Ci-dessous le fichier de configuration commenté de slapd (/etc/openldap/slapd.conf), utilisé sur OpenBSD :

# Schémas de base
include        /etc/openldap/schema/core.schema
# Schémas requis pour les comptes Posix
include        /etc/openldap/schema/cosine.schema
include        /etc/openldap/schema/inetorgperson.schema
include        /etc/openldap/schema/nis.schema

# Nécessaire aux clients utilisant la version 2 du protocole (et à la suite)
allow bind_v2

# Fichiers nécessaires au bon fonctionnement de LDAP
pidfile        /var/run/slapd.pid
argsfile       /var/run/slapd.args


##### Les règles d'accès aux données (ou ACL pour les intimes) #####
##### Recopiez celles qui sont données en première partie #####


# Système de stockage utilisé en arrière-plan
database    ldbm
# Racine de l'annuaire
suffix      "dc=julp,dc=com"
# Nom distingué du manager LDAP pour accéder à l'annuaire
rootdn      "cn=manager,dc=julp,dc=com"
# Son mot de passe en clair ou crypté via la commande slappasswd
# Ici "secret", sous forme hashée, obtenue par la commande "slappasswd -h '{MD5}'"
rootpw      {MD5}Xr4ilOzQ4PCOq3aQ0qbuaQ==
# Emplacement des fichiers de stockage des données
directory   /var/openldap-data

# Les attributs indexés
index    objectClass              eq
index    cn,sn,uid,displayName    pres,sub,eq
index    uidNumber,gidNumber      eq

Modifiez, si besoin, les propriétaire et droits du répertoire accueillant la base de données (désigné par la directive directory) :

chmod -R u=rwx,go= /var/openldap-data
chown -R _openldap:_openldap /var/openldap-data

Vous pouvez à présent démarrer le serveur à l'aide de la commande ci-dessous ou attendre le prochain redémarrage de votre machine.

/usr/local/libexec/slapd -d 1

Insérer le jeu de test pour la suite et tester le fonctionnement de l'annuaire :

ldapadd -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif

Pour plus de commodités lors de l'utilisation des différentes commandes cliente (ldapsearch, etc), je vous invite à créer le fichier ldap.conf sur votre serveur si vous n'y utilisez pas les modules LDAP pour PAM ou NSS :

# La racine par défaut
BASE            dc=julp,dc=com
# L'adresse du serveur
URI             ldap://localhost/

Son chemin exact dépend de votre système. Toutefois les distributions GNU/Linux utilisent généralement pour les paquets officiels /etc/ldap.conf. Sinon, reportez-vous aux sections précédentes si votre système y est abordé.

Si l'annuaire ne démarre pas, au sens où il n'y a aucun processus slapd lancé : contrôlez le journal de l'annuaire. Si vous ne trouvez toujours pas la raison de ce dysfonctionnement voici quelques pistes :

• Vérifier les permissions du répertoire où sont stockées les données en backend ;
• Tenter de relancer slapd avec les options de verbosité maximale (-d -1). Il ne fonctionnera ainsi plus en arrière-plan comme démon et affichera ses messages sur la sortie d'erreur standard ;
• Il est possible que l'origine soit plus intimement liée à la base de données comme une incompatibilité de versions suite à une mise à jour isolée de l'un des deux composants (la base ou le serveur openldap), si tel est le cas vous devriez rapidement en être averti. Dans le cas de bases BerkeleyDB les données peuvent avoir été corrompues, auquel cas la commande db_recover devrait résoudre le problème.

Warning - No DB_CONFIG file found in directory /var/lib/ldap: (2) Expect poor performance for suffix dc=julp,dc=com.

Pluggable Authentication Modules (en français : modules d'authentification enfichables) est un mécanisme d'authentification flexible, permettant par le biais de modules, de définir des stratégies et de proposer différents médias comme sources pour l'identification des utilisateurs (bases de données, annuaire, clé USB, …). L'administrateur système n'est plus ainsi limité aux fichiers /etc/passwd et /etc/shadow. L'authentification via PAM ne concerne pas seulement l'accès au système mais tout service que la machine héberge.

Name Service Switch (ou commutateur de services de nommages), permet de fournir au système non pas des services d'authentification, mais des services de correspondances entre noms, de toutes sortes (noms de machines, utilisateurs, groupes, …), et les identifiants de ces mêmes objets pour la machine (respectivement adresses IP, uid, gid par rapport aux exemples précédents). NSS, fonctionne de manière similaire à PAM, c'est-à-dire sur la base de modules.

De fait, le module LDAP pour NSS n'est pas vital au système tant que ce dernier n'a pas besoin des informations sur les comptes (ou d'autres objets qui dépassent le cadre de cet article). Mais pour des raisons pratiques, il est bien plus pratique de manipuler des noms que des identifiants numériques comme lors, par exemple, de commandes chown/chgrp.

Les modules LDAP pour PAM et NSS prévoient trois méthodes d'authentification auprès de l'annuaire :

1. anonymement par défaut, c'est-à-dire en l'absence des directives binddn/bindpwd et rootbinddn ;
2. connexion non anonyme à partir des nom distingué et mot de passe (en clair) respectivement spécifiés par les directives binddn et bindpwd dans le fichier de configuration du module. Si le processus est exécuté avec un identifiant effectif nul et que la directive rootbinddn est renseignée, la règle qui suit est alors appliquée ;
3. lorsque le processus est exécuté sous un identifiant nul et que la directive rootbinddn est présente pour indiquer le nom distingué de connexion alors le mot de passe correspondant est lu dans un fichier communément appelé ldap.secret. Ce fichier peut et doit être protégé de toute lecture ou écriture autres que celles de l'administrateur.

TODO : l'équivalent de PF (iptables) ce serait bien

TODO : installation (trouver l'option pour qu'il n'y ait pas de configuration)

apt-get install libnss-ldap
apt-get install libpam-ldap

Modifier uniquement les lignes passwd, shadow et group :

• /etc/nsswitch.conf :

  passwd:    files ldap
  shadow:    files ldap
  group:     files ldap

• ? :

  # On conserve les fichiers "originaux" à titre d'exemple
  mv /etc/libnss-ldap.conf /etc/libnss-ldap.conf.sample
  mv /etc/pam_ldap.conf /etc/pam_ldap.conf.sample
  
  # On lie les fichiers des configuration des modules de sorte
  # à ce qu'ils consultent /etc/ldap.conf
  ln -s /etc/ldap/ldap.conf /etc/libnss-ldap.conf
  ln -s /etc/ldap/ldap.conf /etc/pam_ldap.conf

/etc/ldap/ldap.conf :

# Propriétés du serveur LDAP
base               dc=julp,dc=com
uri                ldap://votre adresse IP réseau ou nom la de machine/
ldap_version       3
timelimit          10

# Authentification
rootbinddn         cn=proxyuser,dc=julp,dc=com

# Pour NSS & PAM
pam_password       md5
pam_min_uid        500
nss_base_passwd    ou=Utilisateurs,dc=julp,dc=com?one
nss_base_shadow    ou=Utilisateurs,dc=julp,dc=com?one
nss_base_group     ou=Groupes,dc=julp,dc=com?one

• ? :

  # On supprime les fichiers *.secret
  rm -f /etc/libnss-ldap.secret /etc/pam_ldap.secret
  
  # On crée le fichier /etc/ldap.secret que PAM et NSS consulteront grâce aux liens
  echo 'proxy' > /etc/ldap.secret
  chmod u=rw,go= /etc/ldap.secret
  ln -s /etc/ldap.secret /etc/libnss-ldap.secret
  ln -s /etc/ldap.secret /etc/pam_ldap.secret

• /etc/pam.d/common-account :

  account    sufficient                                          pam_ldap.so
  account    [success=1 new_authtok_reqd=done default=ignore]    pam_unix.so
  account    requisite                                           pam_deny.so
  account    required                                            pam_permit.so

• /etc/pam.d/common-auth :

  auth    sufficient                    pam_ldap.so
  auth    [success=1 default=ignore]    pam_unix.so nullok_secure
  auth    requisite                     pam_deny.so
  auth    required                      pam_permit.so

• /etc/pam.d/common-session :

  session    optional       pam_ldap.so
  session    [default=1]    pam_permit.so
  session    requisite      pam_deny.so
  session    required       pam_permit.so
  session    required       pam_unix.so

• /etc/pam.d/common-password :

  password     sufficient                    pam_ldap.so use_authtok
  password     [success=1 default=ignore]    pam_unix.so obscure md5
  password     requisite                     pam_deny.so
  password     required                      pam_permit.so

emerge sys-auth/pam_ldap
emerge sys-auth/nss_ldap

Modifiez les lignes passwd, shadow et group telles que :

• /etc/nsswitch.conf :

  passwd:    files ldap
  shadow:    files ldap
  group:     files ldap

• ? :

  mv /etc/ldap.conf /etc/ldap.conf.sample
  mv /etc/openldap/ldap.conf /etc/openldap/ldap.conf.sample

* /etc/openldap/ldap.conf :

# Propriétés du serveur LDAP
base               dc=julp,dc=com
uri                ldap://votre adresse IP réseau ou nom la de machine/
ldap_version       3
timelimit          10

# Authentification
rootbinddn         cn=proxyuser,dc=julp,dc=com

# Pour NSS & PAM
pam_password       md5
pam_min_uid        500
nss_base_passwd    ou=Utilisateurs,dc=julp,dc=com?one
nss_base_shadow    ou=Utilisateurs,dc=julp,dc=com?one
nss_base_group     ou=Groupes,dc=julp,dc=com?one

• ? :

  ln -s /etc/openldap/ldap.conf /etc/ldap.conf

• ? :

  # On enregistre le mot de passe dans le fichier /usr/local/etc/ldap.secret
  echo "proxy" > /etc/ldap.secret
  # On le rend lisible que par root
  chmod u=rw,go= /etc/ldap.secret

• /etc/pam.d/system-auth :

  #%PAM-1.0
  
  auth       required     pam_env.so
  auth       sufficient   pam_unix.so try_first_pass likeauth nullok
  auth       required     pam_deny.so
  
  account    required     pam_unix.so
  
  # This can be used only if you enabled the cracklib USE flag
  password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
  # This can be used only if you enabled the cracklib USE flag
  password   sufficient   pam_unix.so try_first_pass use_authtok nullok md5 shadow
  # This can be used only if you enabled the !cracklib USE flag
  # password   sufficient pam_unix.so try_first_pass nullok md5 shadow
  password   required     pam_deny.so
  
  session    required     pam_limits.so
  session    required     pam_unix.so
  
  auth    required    pam_env.so
  auth    sufficient  pam_unix.so likeauth nullok shadow
  auth    sufficient  pam_ldap.so use_first_pass
  auth    required    pam_deny.so
  
  account requisite  pam_unix.so
  account sufficient pam_localuser.so
  account required   pam_ldap.so
  
  password    required pam_cracklib.so retry=3
  password    sufficient pam_unix.so nullok use_authtok shadow md5
  password    sufficient pam_ldap.so use_authtok use_first_pass
  password    required pam_deny.so
  
  session required    pam_limits.so
  session required    pam_unix.so
  session required    pam_mkhomedir.so skel=/etc/skel/ umask=0066
  session optional    pam_ldap.so

Les ports utilisés par défaut par LDAP sont :

• le port 636 pour les connexions (tcp) SSL (protocole LDAPS)
• le port 389 pour les connexions (tcp) non sécurisées ou sécurisées utilisant TLS (protocole LDAP)

Pour les utilisateurs de Packet Filter qui veulent autoriser les requêtes LDAP et LDAPS sortantes et les réponses du serveur, voici la règle à ajouter :

##### Macros #####
if = "fxp0" # Votre interface
serveur_ldap = "192.168.0.1" # Votre serveur LDAP
tcpflags = "flags S/SFRA"

##### Options #####
set skip on lo0

##### Règles #####
# Par défaut tout bloquer et logguer
block log

# ...

# LDAP et LDAPS
pass out quick on $if inet proto tcp from $if \
    to $serveur_ldap port { ldap ldaps } $tcpflags keep state

# ...

Les modules LDAP pour NSS et PAM sont tous deux disponibles parmi les logiciels portés. Leur installation sera, par conséquent :

# Installation de PAM_LDAP
cd /usr/ports/security/pam_ldap
make install

# Installation de NSS_LDAP
cd /usr/ports/net/nss_ldap
make install

Pour indiquer au système de consulter l'annuaire pour trouver les comptes utilisateur après avoir cherché dans les fichiers, nous modifions /etc/nsswitch.conf ainsi :

hosts:          files    dns
networks:       files
protocols:      files
ethers:         files
rpc:            files
netmasks:       files
bootparams:     files
services:       files
passwd:         files    ldap
group:          files    ldap
shadow:         files    ldap
netgroup:       files

Les fichiers de configuration du client LDAP et de NSS étant sensiblement identiques, nous allons les lier pour qu'ils soient plus faciles à maintenir :

# Conservation du fichier
mv /usr/local/etc/nss_ldap.conf /usr/local/etc/nss_ldap.conf.bak
# Nous lions les deux fichiers de configuration
ln -s /usr/local/etc/ldap.conf /usr/local/etc/nss_ldap.conf

Éditons /usr/local/etc/ldap.conf afin de préciser de quelle manière et à quel emplacement précis le système pourra trouver les données relatives aux utilisateurs et groupes dans l'annuaire.

# Propriétés du serveur LDAP
base               dc=julp,dc=com
uri                ldap://localhost/
ldap_version       3
timelimit          10

# Authentification
#rootbinddn         cn=proxyuser,dc=julp,dc=com

# Pour NSS & PAM
pam_password               md5
pam_min_uid                500
nss_base_passwd            ou=Utilisateurs,dc=julp,dc=com?one
nss_base_shadow            ou=Utilisateurs,dc=julp,dc=com?one
nss_base_group             ou=Groupes,dc=julp,dc=com?one
bind_policy                soft
nss_initgroups_ignoreusers root,ldap

La machine cliente aura recours à l'utilisateur LDAP nommé cn=proxyuser,dc=julp,dc=com afin de vérifier que la personne qui s'authentifie sur ce système fournit un couple, login et mot de passe, valide. Ce compte nécessitant un mot de passe (valeur 'proxy' dans cet exemple) pour pouvoir consulter l'annuaire, il faut le fournir à NSS et PAM pour qu'ils puissent procéder aux vérifications :

# On enregistre le mot de passe dans le fichier /usr/local/etc/ldap.secret
echo "proxy" > /usr/local/etc/ldap.secret
# On le rend lisible que par root
chmod u=rw,go= /usr/local/etc/ldap.secret

Pour les accès locaux, il nous faut modifier quelque peu /etc/pam.d/system :

# auth
auth        sufficient    pam_opie.so                   no_warn no_fake_prompts
auth        requisite     pam_opieaccess.so             no_warn allow_local
auth        sufficient    /usr/local/lib/pam_ldap.so    no_warn try_first_pass
auth        required      pam_unix.so                   no_warn try_first_pass nullok

# account
account     sufficient    /usr/local/lib/pam_ldap.so
account     required      pam_login_access.so
account     required      pam_unix.so

# session
session     required      pam_lastlog.so                no_fail

# password
password    sufficient    /usr/local/lib/pam_ldap.so    no_warn try_first_pass
password    required      pam_unix.so                   no_warn try_first_pass

En ce qui concerne SSH, ça se passe dans /etc/pam.d/sshd :

# auth
auth        required      pam_nologin.so                no_warn
auth        sufficient    pam_opie.so                   no_warn no_fake_prompts
auth        requisite     pam_opieaccess.so             no_warn allow_local
auth        sufficient    /usr/local/lib/pam_ldap.so    no_warn
auth        required      pam_unix.so                   no_warn try_first_pass

# account
account     required      pam_login_access.so
account     required      pam_unix.so

# session
session     required      pam_permit.so

# password
password    required      pam_unix.so                   no_warn try_first_pass

Attention :

• Il est ainsi pratique de procéder aux changements de mot de passe des utilisateurs mais attention à tous les risques que ce choix implique : quiconque se saisirait du mot de passe associé au compte effectuant ce changement serait libre de modifier à volonté, au moins tout mot de passe. Si telle est votre décision prenez garde aux permissions du fichier ldap.secret.
• Dans la mesure du possible, il serait plus approprié d'en laisser le soin à l'utilisateur (connexion à l'annuaire via ses propres paramètres). Ceci pouvant être réalisé dans le but de simplifier l'opération pour les utilisateurs par un programme ou script.

Concernant l'annuaire il faut donner à l'utilisateur cn=proxyuser,dc=julp,dc=com les droits d'écriture sur les attributs userPassword. Il faut alors changer l'ACL suivante dans le fichier de configuration de l'annuaire (/usr/local/etc/openldap/slapd.conf) :

access to attr=userPassword
    by dn="cn=manager,dc=julp,dc=com" write
    by dn="cn=proxyuser,dc=julp,dc=com" read
    by self write
    by anonymous auth
    by * none

En :

access to attr=userPassword
    by dn="cn=manager,dc=julp,dc=com" write
    by dn="cn=proxyuser,dc=julp,dc=com" write
    by self write
    by anonymous auth
    by * none

Par défaut, le programme passwd refuse le changement de mot de passe par l'utilisation de modules PAM. Pour changer ce comportement, nous devons en modifier quelque peu sa source. Pour cela, éditez /usr/src/usr.bin/passwd/passwd.c afin de changer :

        errx(1,
      "Sorry, `passwd' can only change passwords for local or NIS users.");

En :

        /*errx(1,
      "Sorry, `passwd' can only change passwords for local or NIS users.");*/
        fprintf(stderr, "Now you can change password via PAM\n");

Puis recompiler le programme passwd :

cd /usr/src/usr.bin/passwd/
make && make install

Enfin modifions /etc/pam.d/passwd tel que :

password    sufficient    pam_unix.so                   no_warn try_first_pass nullok
password    sufficient    /usr/local/lib/pam_ldap.so    use_first_pass

Il existe un module PAM commun aux systèmes Linux et FreeBSD, nommé pam_mkhomedir, qui permet de créer automatiquement le répertoire de l'utilisateur si celui-ci n'existe pas à sa connexion.

Les distributions Linux en disposent de base par contre pour FreeBSD il faut l'ajouter, son installation se fait ainsi à l'aide des logiciels portés :

cd /usr/ports/security/pam_mkhomedir/
make install

Puis suivant les programmes utilisés pour se connecter, vous devez ajouter aux fichiers de configuration adéquats situés dans /etc/pam.d la ligne suivante :

session     required      /usr/local/lib/pam_mkhomedir.so

Note : certains programmes console supportent mal ce module PAM comme su où il sera sans effet ou encore le comportement de login qui crée bien le répertoire mais vous positionne sur la racine.

cd /usr/pkgsrc/security/pam-ldap/
make install

cd /usr/pkgsrc/databases/nss_ldap
make install

/etc/nsswitch.conf :

group:          files ldap
hosts:          files dns
netgroup:       files
networks:       files
passwd:         files ldap
shells:         files

/usr/pkg/etc/openldap/ldap.conf :

# Propriétés du serveur LDAP
base               dc=julp,dc=com
uri                ldap://votre adresse IP réseau ou nom la de machine/
ldap_version       3
timelimit          10
timeout            3

# Authentification
rootbinddn         cn=proxyuser,dc=julp,dc=com

# Pour NSS & PAM
pam_password       md5
pam_min_uid        500
nss_base_passwd    ou=Utilisateurs,dc=julp,dc=com?one
nss_base_shadow    ou=Utilisateurs,dc=julp,dc=com?one
nss_base_group     ou=Groupes,dc=julp,dc=com?one

# Conserver le fichier pam_ldap.conf fourni à titre d'exemple
mv /usr/pkg/etc/pam_ldap.conf /usr/pkg/etc/pam_ldap.conf.sample
# On le fait à présent pointer sur le fichier de configuration du client LDAP
ln -s /usr/pkg/etc/openldap/ldap.conf /usr/pkg/etc/pam_ldap.conf

# On fait de même pour celui qui accomple le module NSS
mv /usr/pkg/etc/nss_ldap.conf /usr/pkg/etc/nss_ldap.conf.sample
ln -s /usr/pkg/etc/openldap/ldap.conf /usr/pkg/etc/nss_ldap.conf

ln -s /usr/pkg/etc/openldap/ldap.conf /usr/pkg/etc/ldap.conf
ln -s /usr/pkg/etc/openldap/ldap.conf /etc/ldap.conf

# On enregistre le mot de passe dans le fichier /usr/pkg/etc/nss_ldap.secret
echo "proxy" > /usr/pkg/etc/nss_ldap.secret
# On le rend lisible que par root
chmod u=rw,go= /usr/pkg/etc/nss_ldap.secret

ln -s /usr/pkg/etc/ldap.secret /usr/pkg/etc/pam_ldap.secret

/etc/pam.d/system :

# auth
auth        sufficient    pam_krb5.so                          no_warn try_first_pass
auth        sufficient    /usr/pkg/lib/security/pam_ldap.so    no_warn try_first_pass
auth        required      pam_unix.so                          no_warn try_first_pass nullok

# account
account     sufficient    /usr/pkg/lib/security/pam_ldap.so
account     required      pam_krb5.so
account     required      pam_unix.so

# session
session     required      pam_lastlog.so                       no_fail no_nested

# password
password    sufficient    pam_krb5.so                          no_warn try_first_pass
password    sufficient    /usr/pkg/lib/security/pam_ldap.so    no_warn try_first_pass
password    required      pam_unix.so                          no_warn try_first_pass

/etc/pam.d/sshd :

# auth
auth        required      pam_nologin.so                       no_warn
auth        sufficient    pam_krb5.so                          no_warn try_first_pass
auth        sufficient    /usr/pkg/lib/security/pam_ldap.so    no_warn try_first_pass
auth        required      pam_unix.so                          no_warn try_first_pass

# account
account     required      pam_krb5.so
account     required      pam_login_access.so
account     required      pam_unix.so

# session
session     required      pam_permit.so

# password
password    sufficient    pam_krb5.so                          no_warn try_first_pass
password    required      pam_unix.so                          no_warn try_first_pass

TODO : ça marche mais uniquement en root : y aurait-il encore un problème au niveau de l'uid effectif ?)

cd /usr/pkgsrc/security/PAM/
make install

Note : OpenBSD ne dispose ni de PAM ni de NSS. C'est pourquoi tout ce qui touche à l'authentification devra être géré par l'application elle-même au lieu de pouvoir compter sur PAM.

Nous ne verrons ici que l'authentification système, pour laquelle nous devrons installer et utiliser un substitut de la commande login standard, login_ldap, qui interrogera par lui-même le ou les annuaires indiqués. Débutez par son installation :

# Par les paquets binaires
pkg_add login_ldap

# Par les logiciels portés
cd /usr/ports/sysutils/login_ldap/
make install clean

Créer une classe d'utilisateurs dans /etc/login.conf indiquant ainsi que l'identification sera gérée par une application tierce (ligne auth) et tous les paramètres utiles de connexion à LDAP tel le modèle suivant :

ldap:\
    :requirehome@:\
    :auth=-ldap:\
    :x-ldap-server=ADRESSE_DU_SERVEUR_LDAP:\
    :x-ldap-port=389:\
    :x-ldap-basedn=ou=Utilisateurs,dc=julp,dc=com:\
    :x-ldap-binddn=cn=proxyuser,dc=julp,dc=com:\
    :x-ldap-bindpw=proxy:\
    :x-ldap-uscope=onelevel:\
    :x-ldap-noreferrals:\
    :x-ldap-filter=(&(objectclass=posixAccount)(uid=%u)):

La connexion n'est ici pas chiffrée. Un exemple plus complet de toutes les options est disponible sur votre système : /usr/local/share/login_ldap/login_ldap.conf.

Toute modification apportée au fichier /etc/login.conf requiert une régénération de la base binaire associée pour être prise en compte (commande cap_mkdb) :

cap_mkdb /etc/login.conf

Attention : Assurez-vous de n'avoir commis aucune erreur dans le fichier /etc/login.conf et contrôler la valeur de retour de la commande précédente. Toute faute pouvant, ici, être lourde de conséquences.

Malheureusement, cette approche ne réalise que l'authentifcation et requiert, par conséquent, tout de même une création manuelle de vos comptes utilisateurs. Pour chacun d'eux, il est nécessaire de les créer en les associant à la classe ldap, exemple avec ppda :

useradd -m -d /home/ppda -s /bin/ksh -L ldap ppda

Pour vérifier que vos comptes sont reconnus vous pouvez employer la commande suivante :

/usr/libexec/auth/login_-ldap -d -s login ppda ldap ; echo $?

Utilisez des commandes id ppda ou getent passwd (suivant votre système) par exemple pour vérifier que NSS fonctionne convenablement.

Dans le cas contraire et si vous obtenez de gros lags vérifiez que l'annuaire est en fonctionnement et joignable sinon les fichiers de configuration du module nss_ldap et /etc/nsswitch.conf ainsi que vos ACL.

On testera la bonne réalisation de l'authentification, le plus simplement du monde, en testant un compte LDAP sur un service configuré pour passer par PAM.

À moins d'une erreur dans la saisie des identifiants ou d'une incompatibilité par rapport au mot de passe, une anomalie serait à plutôt chercher du côté de l'annuaire en lui-même.

2 solutions

Principe : le maître transmet les modifications aux esclaves

Il est recommandé de créer un utilisateur LDAP spécifique (classe d'objet person ou fille par héritage) pour la réplication Celui-ci ne sera ainsi utilisé que par l'annuaire maître pour accéder à un annuaire esclave. Vous pouvez, par ailleurs, choisir un utilisateur différent par annuaire esclave. Voici à titre d'exemple, notre utilisateur au format LDIF (fichier replicateur.ldif) :

dn: cn=syncuser,dc=julp,dc=com
objectClass: top
objectClass: person
cn: replication
# sn est obligatoire
sn: syncuser
userPassword: {MD5}Y62dNPNQOCbl9kmua3rJLA==
# mot de passe : 'sync' obtenu grâce avec la commande : slappasswd -h '{MD5}'

L'ajout à l'annuaire maître se fait avec la commande suivante :

ldapadd -H ldap://<adresse ou nom de la machine maître> -D "cn=manager,dc=julp,dc=com" -W -x -f replicateur.ldif

Il faut apporter quelques modifications à la configuration de l'annuaire maître afin de faire fonctionner la réplication. En effet, l'utilisateur associé à la réplication doit avoir accès en lecture aux objets de l'annuaire (éventuellement partielle) et il faut également lui indiquer le serveur LDAP accueillant la réplication pour qu'il puisse communiquer avec ce dernier. Par conséquent, voici les modifications et/ou ajouts à apporter à votre fichier slapd.conf :

# ...

# ACL : donner accès en lecture à l'annuaire entier à l'utilisateur LDAP assurant la réplication
access to *
        by dn="cn=manager,dc=julp,dc=com" write
        by dn="cn=syncuser,dc=julp,dc=com" read
        by users read

# ...

# Réplication
# Comment contacter l'annuaire esclave ?
replica
    uri=ldap://<adresse ou nom de l'annuaire esclave>
    binddn="cn=syncuser,dc=julp,dc=com"
    bindmethod=simple credentials=<le mot de passe associé à ce compte en clair>
# Journal
replogfile /var/db/openldap-slurp/replica/replog

# ...

Dans le cas de l'annuaire esclave, il faut aussi apporter quelques modifications où à l'inverse d'un annuaire maître, il faut autoriser l'utilisateur de réplication à écrire et lui indiquer qui est son serveur LDAP maître. Voici les modifications et/ou ajouts à apporter à votre fichier slapd.conf :

# ...

# ACL : donner accès en écriture à l'annuaire entier à l'utilisateur assurant la réplication
access to *
        by dn="cn=manager,dc=julp,dc=com" write
        by dn="cn=syncuser,dc=julp,dc=com" write
        by users read

# ...

# Réplication
# DN de l'utilisateur de réplication
updatedn        "cn=syncuser,dc=julp,dc=com"
# Comment joindre l'annuaire maître ?
updateref       "ldap://<adresse ou nom de l'annuaire maître>"

# ...

Les différents services doivent être démarrés dans cet ordre :

1. Sur la machine officiant en tant que maître : le service slapd puis slurpd
2. Le démon slapd sur les machines esclaves

• Maître :

  update-rc.d slurpd start PRIORITE 2 3 4 5 . stop PRIORITE 0 1 6 .

• Esclave : rien à faire de plus

• Maître :

  rc-update add slurpd default

• Esclave : rien à faire de plus

Votre fichier /etc/rc.conf de votre annuaire maître doit contenir :

# LDAP
slapd_enable="YES"
slapd_flags="-h ldap:///"
# Réplication
slurpd_enable="YES"

Et quant à l'annuaire esclave accueillant la réplique :

# LDAP
slapd_enable="YES"
slapd_flags="-h ldap:///"

?

?

Vous avez sans doute remarqué la présence de slurpd seulement sur l'annuaire maître, en effet, c'est ce programme qui se charge de renvoyer les requêtes vers les annuaires esclaves ainsi que du journal qui garde, sous forme LDIF, les modifications (à exploiter lorsque la réplication n'a pas fonctionné).

?

Principe : l'esclave se connecte au maître et rafraichit ses données à intervalle régulier La copie peut être partielle Certaines indépendances mutuelles

Forme générale :

syncrepl rid=<replica ID> provider=ldap[s]://<hostname>[:port]
	     [type=refreshOnly (à intervalle régulier)|refreshAndPersist (constamment en écoute)] [interval=jj:hh:mm:ss]
	     [retry=[<retry interval> <# of retries>]+]
		 [searchbase=<base DN>]
		 [scope=sub|one|base]
	     [filter=<filter str>]
		 [attrs=<attr list>]
	     [attrsonly]
		 [sizelimit=<limit>]
		 [timelimit=<limit>]
	     [schemachecking=on|off]
		 [starttls=yes|critical]
	     [bindmethod=simple|sasl]
		 [binddn=<dn>]
		 [saslmech=<mech>]
	     [authcid=<identity>]
		 [authzid=<identity>]
		 [credentials=<passwd>]
	     [realm=<realm>] 
		 [secprops=<properties>]
		 [logbase=<base DN>]
	     [logfilter=<filter str>]
		 [syncdata=default|accesslog|changelog]

Exemple :

syncrepl rid=123
    provider=ldap://provider.example.com:389
    type=refreshOnly
    interval=00:00:15:00 # 15 minutes
    searchbase="dc=julp,dc=com"
    filter="(objectClass=*)"
    scope=sub
    schemachecking=on
    bindmethod=simple
    binddn="cn=syncuser,dc=julp,dc=com"
    credentials=sync

Partie(s) à modifier sur le maître :

index entryCSN,entryUUID eq

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

Partie(s) à modifier sur les esclaves :

index entryCSN,entryUUID eq

# + directive syncrepl

openssl req -new -keyout server-key.pem -out server-req.pem -days 3600

Generating a 1024 bit RSA private key
.............++++++
..........................................++++++
writing new private key to 'ca-key.pem'
Enter PEM pass phrase:la passphrase de l'autorité de certification
Verifying - Enter PEM pass phrase:resaisissez cette dernière
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:le nom de votre autorité de certification
Email Address []:l'adresse email associée à cette autorité de certification

openssl req -new -keyout server-key.pem -out server-req.pem -days 3600

Generating a 1024 bit RSA private key
........++++++
.....++++++
writing new private key to 'server-key.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:le nom exact de votre serveur
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:un mot de passe solide (vous n'avez nul besoin de le mémoriser)
An optional company name []:

openssl x509 -req -in server-req.pem -days 3600 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem

Signature ok
subject=/C=FR/CN=freebsd6
Getting CA Private Key
Enter pass phrase for ca-key.pem:la passphrase de l'autorité de certification

Si vous ne désirez pas que le serveur vous demande la passphrase à chacun de ses démarrages, vous pouvez supprimer son cryptage par la passphrase en procédant ainsi :

# On conserve une copie du certificat original chiffré :
cp server-key.pem server-key.pem.orig
# On supprime ce chiffrage :
openssl rsa -in server-key.pem -out server-key.pem

Changer les permissions ? (attention aux utilisateur/groupe)

chown -R root:ldap /.../.../certs/
chmod ug=r,o= /.../.../certs/server-key.pem

Modifier le fichier ldap.conf :

# A modifier pour SSL seulement (TLS n'est pas concerné)
URI                 ldaps://mon_serveur/

# TLS et SSL, ajoutez
TLS_CACERT          /.../.../certs/ca-cert.pem
TLS_CIPHER_SUITE    HIGH

# PAM & NSS
# Pour SSL
ssl                 on
# Pour TLS
ssl                 start_tls

Modifier le fichier slapd.conf :

TLS_CIPHER_SUITE         HIGH
TLSCertificateFile       /.../.../certs/server-cert.pem
TLSCertificateKeyFile    /.../.../certs/server-key.pem
TLSCACertificateFile     /.../.../certs/ca-cert.pem
TLSVerifyClient          never

Exécution du démon (slapd) :

• normal et TLS : le drapeau -h "ldap:///" suffira (modifier si besoin l'URL)
• SSL uniquement : le drapeau -h "ldaps:///" conviendra
• normal, TLS et SSL : le drapeau host comportera -h "ldap:/// ldaps:///"

Pour tester (une fois slapd redémarré) :

• Connexion TLS :

  ldapsearch -H ldap://votre_serveur_ldap -ZZ -D "cn=manager,dc=julp,dc=com" -W -x

• Connexion SSL :

  ldapsearch -H ldaps://votre_serveur_ldap -D "cn=manager,dc=julp,dc=com" -W -x

slapcat -l dump.ldif

Cette extension requiert une version d'OpenLDAP supérieure ou égale à 2.3, sachant toutefois que les directives qui lui sont propres ont évoluées. Elle permet, par exemple, d'assurer l'unicité d'identifiants comme ceux de vos utilisateurs et de vos groupes et de limiter les erreurs.

Illustration, pour une version 2.4, visant à interdire l'introduction de deux logins (attributs uid), deux identifiants utilisateurs (uidNumber) ou de groupe (gidNumber) égaux :

# Activation de l'overlay
overlay unique

# Un même identifiant utilisateur (uidNumber) ne peut être partagé par deux comptes (posixAccount)
unique_uri ldap:///?uidnumber,uid?sub?(objectclass=posixaccount)

# Un même identifiant de groupe (gidNumber) ne peut être partagé par deux groupes(posixGroup)
unique_uri ldap:///?gidnumber?sub?(objectclass=posixgroup)

# La racine de l'annuaire
dn: dc=julp,dc=com
dc: julp
objectclass: top
objectclass: domain
objectclass: domainRelatedObject
description: Mon annuaire
associatedDomain: julp.com
 
# Le conteneur pour les utilisateurs
dn: ou=Utilisateurs,dc=julp,dc=com
objectclass: top
objectclass: organizationalUnit
ou: Utilisateurs
description: Les utilisateurs
 
# Le conteneur pour les groupes
dn: ou=Groupes,dc=julp,dc=com
objectclass: top
objectclass: organizationalUnit
ou: Groupes
description: Les groupes
 
# Patrick Poivre d'Arvor, notre utilisateur de test
dn: cn=Patrick Poivre d'Arvor,ou=Utilisateurs,dc=julp,dc=com
# Common Name
cn: Patrick Poivre d'Arvor
# Surnom
sn: ppda
# Les classes (l'inférieure dérivant de la supérieure)
objectclass: top
objectclass: person
objectclass: posixAccount
objectclass: shadowAccount
# Login
uid: ppda
# Identifiant de l'utilisateur
uidnumber: 2000
# Groupe principal de l'utilisateur
gidnumber: 2000
# Nom complet
gecos: Patrick Poivre d'Arvor
# Shell
loginShell: /bin/csh
# Répertoire personnel
homeDirectory: /home/ppda
# Mot de passe
# "ppda" obtenu par "slappasswd -h '{MD5}'"
userpassword: {MD5}tcIIRTe2hjtHpCz0Usaupw==
 
# LdapUsers, un groupe Unix de test
dn: cn=LdapUsers,ou=Groupes,dc=julp,dc=com
objectclass: top
objectclass: posixGroup
# Identifiant du groupe
gidNumber: 2000
# Intitule du groupe
cn: LdapUsers
# Membres du groupe
memberUid: ppda
 
# Notre utilisateur 'proxy' pour vérifier les authentifications
dn: cn=proxyuser,dc=julp,dc=com
objectClass: top
objectClass: person
cn: proxyuser
# sn est obligatoire
sn: proxyuser
# Mot de passe : 'proxy' obtenu grâce avec la commande : slappasswd -h '{MD5}'
userPassword: {MD5}QxOH63Ji4c/HmxJeuKZ8YA==

Note : Dans l'hypothèse où vos propres fichiers LDIF contiennent des caractères spéciaux, vous devrez alors les encoder au format UTF-8 (à l'aide de votre éditeur ou encore par conversion via l'utilitaire iconv).

Nous avons mis en oeuvre un annuaire LDAP pour assurer l'authentification liée au système mais son rôle ne s'arrête pas nécessairement là. Il est en effet possible d'exploiter l'annuaire pour assurer l'identification de bien d'autres services comme de pages web avec Apache, FTP, etc. Ou l'utiliser dans d'autres tâches que l'authentification : informations sur les machines du parc (matériels, résolution de noms), …