====== 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 : * 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) ===== 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 : # 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 ====== 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 : # 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. - {{ :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 : 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. ==== 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 : 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 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 : ##### 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 # ... ==== FreeBSD ==== 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-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 : {{ :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 :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://" # 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 ==== 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 : 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 ==== OpenBSD ==== 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 ==== 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 : # 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é. ===== 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) 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 === Gentoo === 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 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 : ##### 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 # ... === 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 : # 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 == Configuration de services utilisant PAM == 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 == 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) : 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 == 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 : 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. === NetBSD === == Installation et configuration générale de NSS et PAM == 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 == Configuration de services utilisant PAM == /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 == 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 == cd /usr/pkgsrc/security/PAM/ make install === 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 : # 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 $? ==== 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) : 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:// -D "cn=manager,dc=julp,dc=com" -W -x -f replicateur.ldif === 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 : # ... # 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:// binddn="cn=syncuser,dc=julp,dc=com" bindmethod=simple credentials= # Journal replogfile /var/db/openldap-slurp/replica/replog # ... === 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 : # ... # 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://" # ... === 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 :update-rc.d slurpd start PRIORITE 2 3 4 5 . stop PRIORITE 0 1 6 . * Esclave : rien à faire de plus == Gentoo == * Maître :rc-update add slurpd default * Esclave : rien à faire de plus == Les systèmes BSD == == FreeBSD == 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:///" == 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 : syncrepl rid= provider=ldap[s]://[:port] [type=refreshOnly (à intervalle régulier)|refreshAndPersist (constamment en écoute)] [interval=jj:hh:mm:ss] [retry=[ <# of retries>]+] [searchbase=] [scope=sub|one|base] [filter=] [attrs=] [attrsonly] [sizelimit=] [timelimit=] [schemachecking=on|off] [starttls=yes|critical] [bindmethod=simple|sasl] [binddn=] [saslmech=] [authcid=] [authzid=] [credentials=] [realm=] [secprops=] [logbase=] [logfilter=] [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 ===== Aller plus loin ===== ==== Chiffrer les échanges : protocoles TLS/SSL ==== === Introduction === === Création de l'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 '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 === Création du certificat === 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 === Configuration du client === 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 === Configuration du serveur === 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 ==== Commandes utiles ==== === Réaliser une sauvegarde intégrale de l'annuaire au format LDIF === slapcat -l dump.ldif ==== 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 : # 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) ===== Annexes ===== ==== Jeu de test au format 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== 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), ...