julp

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Synopsis ======

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.

====== Préambule/Présentation/Introduction ======

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 : <code>* 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)</code>
  * NSS/PAM (fait - à conserver) :<code>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)</code>
  * Récapitulatif Debian :<code>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)</code>

===== Définition des ACL =====

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 :
<code># 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</code>

====== Installation et configuration du serveur LDAP ======

===== Les distributions GNU/Linux =====

==== Debian ====

Nous aurons besoin des paquets correspondants au serveur OpenLDAP ainsi que des utilitaires client console de base :
<code># Le serveur
apt-get install slapd

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

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.
  - {{ :ldap:debian-slapd-etape1.png?nolink }}
  - {{ :ldap:debian-slapd-etape2.png?nolink |}}
  - {{ :ldap:debian-slapd-etape3.png?nolink |}}
  - {{ :ldap:debian-slapd-etape4.png?nolink |}}
  - {{ :ldap:debian-slapd-etape5.png?nolink |}}
  - {{ :ldap:debian-slapd-etape6.png?nolink |}}

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 :
<code>update-rc.d slapd start 19 2 3 4 5 . stop 80 0 1 6 .</code>

Vérifiez que les permissions du répertoire où est entroposée la base de données sont correctes sinon corrigez-les :
<code>chmod -R u=rwx,go= /var/lib/ldap
chmod -R openldap:openldap /var/lib/ldap</code>

Si vous avez modifié la configuration du serveur et étant normalement déjà en activité, il serait alors bon de le redémarrer :
<code>/etc/init.d/slapd restart</code>

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.
<code>ldapadd -c -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif</code>

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.

==== Gentoo ====

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 :
<code>net-nds/openldap berkdb crypt ipv6 overlays readline ssl tcpd -debug -gdbm -kerberos -minimal -odbc -perl -samba -sasl -slp -smbkrb5passwd</code>

Ceci fait, compilez/installez OpenLDAP :
<code>emerge net-nds/openldap</code>

Mettez en place votre configuration en modifiant /etc/openldap/slapd.conf sur ce modèle :
<code># 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</code>

Vous souhaiterez maintenant sans doute que l'annuaire soit démarré de manière automatique lorsque la machine sera (re)bootée :
<code>rc-update add slapd default</code>

Avant le premier démarrage d'OpenLDAP, nous procéderons à une vérification des permissions de la base de données :
<code>chmod -R u=rwx,go= /var/lib/openldap-data
chown -R ldap:ldap /var/lib/openldap-data</code>

À présent, nous pouvons enfin démarrer notre annuaire ...
<code>/etc/init.d/slapd start</code>

... puis y ajouter quelques données que vous pourrez trouver en annexe :
<code>ldapadd -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif</code>

===== Les systèmes BSD =====

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 :
<code>##### 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

# ...</code>

==== FreeBSD ====

L'installation de l'annuaire se déroule ainsi, le système de logiciels portés se chargera pour nous des dépendances :
<code>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</code>

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 :
{{ :ldap:freebsd-openldap-server-config.png?nolink |}}

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 :<code>WANT_OPENLDAP_VER=24 # Ici pour forcer l'utilisation de la branche 2.4 d'OpenLDAP</code>

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 :
<code># LDAP
slapd_enable="YES"
slapd_flags="-h ldap://<votre adresse IP réseau>" # Ou plus simplement : slapd_flags="-h ldap:///"</code>

Vous trouverez ci-dessous un fichier de configuration du serveur LDAP (/usr/local/etc/openldap/slapd.conf) commenté.
<code># 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</code>

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 :
<code># 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</code>

Tout est désormais prêt pour le démarrage du serveur LDAP :
<code>/usr/local/etc/rc.d/slapd start</code>

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 :
<code>ldapadd -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif</code>

==== NetBSD ====

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 :
<code>PKG_OPTIONS.openldap-client= inet6
PKG_OPTIONS.openldap-server= bdb inet6</code>

Puis passez à la compilation :
<code>cd /usr/pkgsrc/databases/openldap-client/
make install

cd /usr/pkgsrc/databases/openldap-server/
make install</code>

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 :
<code>cp /usr/local/share/examples/rc.d/slapd /etc/rc.d/</code>

Éditez /etc/rc.conf pour le démarrage automatique de l'annuaire :
<code>slapd=YES</code>

Configurez l'ensemble du serveur au travers de /usr/pkg/etc/openldap/slapd.conf devant à présent s'approcher de celui ci-dessous :
<code># 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</code>

Vérifiez que les permissions sur le répertoire de la base sont correctes :
<code># 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</code>

Démarrez l'annuaire :
<code>/etc/rc.d/slapd start</code>

Procédez enfin à l'insertion des données de notre jeu de test :
<code>ldapadd -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif</code>

==== OpenBSD ====

Installez le client ainsi que le serveur LDAP à l'aide des paquets binaires :
<code># (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</code>

Éventuellement, si vous préférez recourir aux logiciels portés, la procédure est la suivante :
<code>cd /usr/ports/databases/openldap
env SUBPACKAGE="-server" FLAVOR="bdb" make install clean</code>

Afin d'exécuter le démon slapd au démarrage de la machine nous devons modifier le fichier /etc/rc.local :
<code># 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</code>

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 :
<code># OpenLDAP
if [ -r /var/run/slapd.pid ]; then
    kill `cat /var/run/slapd.pid`
fi</code>

Ci-dessous le fichier de configuration commenté de slapd (/etc/openldap/slapd.conf), utilisé sur OpenBSD :
<code># 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</code>

Modifiez, si besoin, les propriétaire et droits du répertoire accueillant la base de données (désigné par la directive directory) :
<code>chmod -R u=rwx,go= /var/openldap-data
chown -R _openldap:_openldap /var/openldap-data</code>

Vous pouvez à présent démarrer le serveur à l'aide de la commande ci-dessous ou attendre le prochain redémarrage de votre machine.
<code>/usr/local/libexec/slapd -d 1</code>

Insérer le jeu de test pour la suite et tester le fonctionnement de l'annuaire :
<code>ldapadd -x -D "cn=manager,dc=julp,dc=com" -W -h localhost -f test.ldif</code>

==== Configuration du client sur le serveur ====

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 :
<code># La racine par défaut
BASE            dc=julp,dc=com
# L'adresse du serveur
URI             ldap://localhost/</code>
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é.

===== Problèmes courants et résolution =====

==== L'annuaire ne démarre pas ====

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.

==== Message d'erreur lié à l'absence d'un certain fichier DB_CONFIG ====

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

===== Authentifications des utilisateurs par LDAP =====

==== Définitions ====

=== PAM ===

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.

=== NSS ===

 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.

=== Approche choisie vis à vis de la configuration des modules PAM/NSS ===

Les modules LDAP pour PAM et NSS prévoient trois méthodes d'authentification auprès de l'annuaire :
  - anonymement par défaut, c'est-à-dire en l'absence des directives binddn/bindpwd et rootbinddn ;
  - 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 ;
   - 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.

==== Les distributions GNU/Linux ====

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

=== Debian ===

TODO : installation (trouver l'option pour qu'il n'y ait pas de configuration)
<code>apt-get install libnss-ldap
apt-get install libpam-ldap</code>

Modifier uniquement les lignes passwd, shadow et group :
  * /etc/nsswitch.conf :<code>passwd:    files ldap
shadow:    files ldap
group:     files ldap</code>
  * ? : <code># 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</code>
/etc/ldap/ldap.conf :<code># 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</code>
  * ? : <code># 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</code>
  * /etc/pam.d/common-account :<code>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</code>
  * /etc/pam.d/common-auth :<code>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</code>
  * /etc/pam.d/common-session :<code>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</code>
  * /etc/pam.d/common-password :<code>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</code>

=== Gentoo ===

<code>emerge sys-auth/pam_ldap
emerge sys-auth/nss_ldap</code>

Modifiez les lignes passwd, shadow et group telles que :
  * /etc/nsswitch.conf :<code>passwd:    files ldap
shadow:    files ldap
group:     files ldap</code>
  * ? : <code>mv /etc/ldap.conf /etc/ldap.conf.sample
mv /etc/openldap/ldap.conf /etc/openldap/ldap.conf.sample</code>
 * /etc/openldap/ldap.conf :<code># 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</code>
  * ? : <code>ln -s /etc/openldap/ldap.conf /etc/ldap.conf</code>
  * ? : <code># 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</code>
  * /etc/pam.d/system-auth :<code>#%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</code>

==== Les systèmes BSD ====

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 :
<code>##### 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

# ...</code>

=== FreeBSD ===

== Installation et configuration générale de NSS et PAM ==

Les modules LDAP pour NSS et PAM sont tous deux disponibles parmi les logiciels portés. Leur installation sera, par conséquent :
<code># Installation de PAM_LDAP
cd /usr/ports/security/pam_ldap
make install

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

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 :
<code>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</code>

Les fichiers de configuration du client LDAP et de NSS étant sensiblement identiques, nous allons les lier pour qu'ils soient plus faciles à maintenir :
<code># 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</code>

É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.
<code># 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</code>

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 :
<code># 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</code>

== Configuration de services utilisant PAM ==

Pour les accès locaux, il nous faut modifier quelque peu /etc/pam.d/system :
<code># 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</code>

En ce qui concerne SSH, ça se passe dans /etc/pam.d/sshd :
<code># 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</code>

== Permettre le changement de mot de passe par la commande passwd ==

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) :
<code>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</code>
En :
<code>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</code>
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 :
<code c>        errx(1,
      "Sorry, `passwd' can only change passwords for local or NIS users.");</code>
En :
<code c>        /*errx(1,
      "Sorry, `passwd' can only change passwords for local or NIS users.");*/
        fprintf(stderr, "Now you can change password via PAM\n");</code>
Puis recompiler le programme passwd :
<code>cd /usr/src/usr.bin/passwd/
make && make install</code>
Enfin modifions /etc/pam.d/passwd tel que :
<code>password    sufficient    pam_unix.so                   no_warn try_first_pass nullok
password    sufficient    /usr/local/lib/pam_ldap.so    use_first_pass</code>

== Création automatique du répertoire utilisateur ==

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 :
<code>cd /usr/ports/security/pam_mkhomedir/
make install</code>

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 :
<code>session     required      /usr/local/lib/pam_mkhomedir.so</code>

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.

=== NetBSD ===

== Installation et configuration générale de NSS et PAM ==

<code>cd /usr/pkgsrc/security/pam-ldap/
make install

cd /usr/pkgsrc/databases/nss_ldap
make install</code>

/etc/nsswitch.conf :
<code>group:          files ldap
hosts:          files dns
netgroup:       files
networks:       files
passwd:         files ldap
shells:         files</code>

/usr/pkg/etc/openldap/ldap.conf :
<code># 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</code>

<code># 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</code>

== Configuration de services utilisant PAM ==

/etc/pam.d/system :
<code># 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</code>

/etc/pam.d/sshd :
<code># 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</code>

== Permettre le changement de mot de passe par la commande passwd ==

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

== Création automatique du répertoire utilisateur ==

<code>cd /usr/pkgsrc/security/PAM/
make install</code>

=== OpenBSD ===

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 :
<code># Par les paquets binaires
pkg_add login_ldap

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

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 :
<code>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)):</code>

 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) :
<code>cap_mkdb /etc/login.conf</code>
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 :
<code>useradd -m -d /home/ppda -s /bin/ksh -L ldap ppda</code>

Pour vérifier que vos comptes sont reconnus vous pouvez employer la commande suivante :
<code>/usr/libexec/auth/login_-ldap -d -s login ppda ldap ; echo $?</code>

==== Phase de tests ====

=== Résolution des logins (NSS) ===

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.

=== L'authentification (PAM) ===

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.

===== La réplication =====

2 solutions

==== slurpd ====

Principe : le maître transmet les modifications aux esclaves

=== Création d'un compte utilisateur dédié à la réplication ===

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) :
<code 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}'</code>

L'ajout à l'annuaire maître se fait avec la commande suivante :
<code>ldapadd -H ldap://<adresse ou nom de la machine maître> -D "cn=manager,dc=julp,dc=com" -W -x -f replicateur.ldif</code>

=== Configuration de l'annuaire maître ===

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 :
<code># ...

# 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

# ...</code>

=== Configuration de l'annuaire esclave ===

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 :
<code># ...

# 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>"

# ...</code>

=== Démarrage ===

Les différents services doivent être démarrés dans cet ordre :
  - Sur la machine officiant en tant que maître : le service slapd puis slurpd
  - Le démon slapd sur les machines esclaves

== Les distributions GNU/Linux ==

== Debian ==

  * Maître :<code>update-rc.d slurpd start PRIORITE 2 3 4 5 . stop PRIORITE 0 1 6 .</code>
  * Esclave : rien à faire de plus

== Gentoo ==

  * Maître :<code>rc-update add slurpd default</code>
  * Esclave : rien à faire de plus

== Les systèmes BSD ==

== FreeBSD ==

Votre fichier /etc/rc.conf de votre annuaire maître doit contenir :
<code># LDAP
slapd_enable="YES"
slapd_flags="-h ldap:///"
# Réplication
slurpd_enable="YES"</code>

Et quant à l'annuaire esclave accueillant la réplique :
<code># LDAP
slapd_enable="YES"
slapd_flags="-h ldap:///"</code>

== NetBSD ==

?

== OpenBSD ==

?

=== Note ===

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é).

=== Résolution des problèmes ===

?

====  LDAP Sync Replication ====

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 :
<code>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]</code>

Exemple :
<code>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</code>

Partie(s) à modifier sur le maître :
<code>index entryCSN,entryUUID eq

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100</code>

Partie(s) à modifier sur les esclaves :
<code>index entryCSN,entryUUID eq

# + directive syncrepl</code>

===== Aller plus loin =====

==== Chiffrer les échanges : protocoles TLS/SSL ====

=== Introduction ===

=== Création de l'autorité de certification ===

<code>openssl req -new -keyout server-key.pem -out server-req.pem -days 3600</code>
<code>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</code>

=== Création du certificat ===

<code>openssl req -new -keyout server-key.pem -out server-req.pem -days 3600</code>
<code>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 []:</code>

<code>openssl x509 -req -in server-req.pem -days 3600 -CA ca-cert.pem -CAkey ca-key.pem -set_serial 01 -out server-cert.pem</code>
<code>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</code>

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 : 
<code># 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</code>

Changer les permissions ? (attention aux utilisateur/groupe)
<code>chown -R root:ldap /.../.../certs/
chmod ug=r,o= /.../.../certs/server-key.pem</code>

=== Configuration du client ===

Modifier le fichier ldap.conf :
<code># 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</code>

=== Configuration du serveur ===

Modifier le fichier slapd.conf :
<code>TLS_CIPHER_SUITE         HIGH
TLSCertificateFile       /.../.../certs/server-cert.pem
TLSCertificateKeyFile    /.../.../certs/server-key.pem
TLSCACertificateFile     /.../.../certs/ca-cert.pem
TLSVerifyClient          never</code>

Exécution du démon (slapd) :
  * normal et TLS : <nowiki>le drapeau -h "ldap:///" suffira (modifier si besoin l'URL)</nowiki>
  * SSL uniquement : <nowiki>le drapeau -h "ldaps:///" conviendra</nowiki>
  * normal, TLS et SSL : <nowiki>le drapeau host comportera -h "ldap:/// ldaps:///"</nowiki>

Pour tester (une fois slapd redémarré) :
  * Connexion TLS :<code>ldapsearch -H ldap://votre_serveur_ldap -ZZ -D "cn=manager,dc=julp,dc=com" -W -x</code>
  * Connexion SSL :<code>ldapsearch -H ldaps://votre_serveur_ldap -D "cn=manager,dc=julp,dc=com" -W -x</code>

==== Commandes utiles ====

=== Réaliser une sauvegarde intégrale de l'annuaire au format LDIF ===

<code>slapcat -l dump.ldif</code>

==== ppolicy overlay (password policy) ====

==== Assurer l'unicité à l'aide de l'extension "unique overlay" ====

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 :
<code># 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)</code>

===== Annexes =====

==== Jeu de test au format LDIF ====

<code ldif># 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==</code>

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).

===== Conclusion =====

==== Épilogue ====

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), ...
julp

Outils pour utilisateurs

Outils du site

Outils de la page
