Gestion de LetsEncrypt sous FreeBSD avec nginx et une jail

LetsEncypt est une autorité de certification utilisant une API basée sur des appels HTTP et un client côté serveur qui va générer des tokens lus par les serveurs LetsEncrypt.

Nous allons ici voir une architecture LetsEncrypt typique dans laquelle nous allons utiliser le client acme-client d’OpenBSD disponible dans les ports et les packages FreeBSD.

Installation

Dans un premier temps installez le client sur votre machine hôte (et pas votre jail web):

Continuer à lire

Postfix: support du SMTPS authentifié (SASL)

Avoir un serveur SMTP qui envoie des mails est bien, le sécuriser c’est mieux.

La législation française impose d’enregistrer les méta-données de connexion aux serveurs, que ce soit vers l’Internet ou en interne. L’authentification est alors une étape primordiale dans la configuration de notre serveur d’envoi SMTP.

Afin de sécuriser nos échanges, nous ajouterons une couche de chiffrement SSL à Postfix, évitant à des attaquants d’intercepter des mails en clair sur le réseau.

Ce tutoriel a été réalisé et testé sur des infrastructures de production en FreeBSD 9.2 et OpenBSD 5.3 Continuer à lire

SquidGuard: blacklists pour squid

Squidguard est un plugin qui se greffe sur un serveur Squid. Il permet la gestion plus poussée des ACL par le biais notamment de la gestion de blacklists compilées. SquidGuard permet également de gérer des accès horaires, des conditions plus poussées et la modification de la page par une autre page.

Installation et configuration

Installation

Pour installer SquidGuard rien de plus simple:


Sous FreeBSD: Continuer à lire

OpenLDAP

Introduction

OpenLDAP est l’annuaire libre de référence. Il intègre l’ensemble des fonctionnalités que l’on peut attendre d’un annuaire, et se base sur un système de schémas. Chaque schéma définit un ensemble d’attributs et de contraintes associées qui vont définir l’objet associé.

Un annuaire LDAP se base sur une arborescence d’objets, dont chacun est indentifié par un DN (dinstinguished name), réparti dans des unités d’organisation (OU) sous une racine (origin) Continuer à lire

PPTPD (Poptop)

Introduction

Les tunnels PPTP sont des tunnels qui sont intégrés nativement dans la plupart des OS depuis une dizaine d’années. S’appuyant sur PPP et ajoutant une couche d’authentification plus robuste voire du chiffrement, ils permettent aux utilisateurs distants de pouvoir se connecter à leur réseau d’entreprise. Continuer à lire

FreeRadius, serveur Radius OpenSource

Introduction

Freeradius est un serveur Radius libre permettant de s’authentifier. Le protocole radius permet de se connecter via un échange de paquets UDP, généralement sur le port 1812. Radius intègre également un module d’accounting, permettant par exemple de la facturation. Radius permet de s’authentifier via diverses moyens comme une authentification en clair, par adresse MAC, via base MySQL/PgSQL, protocole MSCHAPv1 et MSCHAPv2 ou encore annuaire LDAP.

Radius gère également le 802.1X avec l’authenfication via tunnel EAP (PEAP/TLS/TTLS), qui sera étudiée en fin de tutoriel. Continuer à lire

Squid: Proxy Web, Authentification, Cache et Filtrage

Introduction

Squid est un service de proxy cache web. Il permet de filtrer, mettre en cache les informations et authentifier les utilisateurs. Cette solution puissante permet de pouvoir gérer efficacement son parc et de pouvoir répondre aux attentes du code des postes et télécommunications en matière de trafic Internet.

Installation

Sous Debian:

Sous FreeBSD: Continuer à lire

OpenVPN

Introduction

OpenVPN est une solution open source de VPN tournant à la fois sous Linux, BSD, Mac et Windows. Un VPN permet d'établir un tunnel entre deux points et ainsi outrepasser certaines restrictions par exemple. Ces tunnels peuvent être en clair ou encore cryptés, compressés ou ne rediriger que certains flux. Nous allons étudier comment mettre en oeuvre de façon simple une solution openvpn. Installation

Que ce soit pour un client ou pour un serveur il suffira simplement de taper:

Sous Debian:

apt-get install openvpn

Sous FreeBSD:

pkg install openvpn
# Ou via les ports:
cd /usr/ports/security/openvpn
make install clean

Il faut absolument choisir l'option suivante lors de la configuration du port:

[*] PKCS11   Use security/pkcs11-helper

Configuration du serveur

Configuration préliminaire

Le dossier de configuration d'OpenVPN n'existe pas par défaut, nous allons le créer.

Sous Debian

mkdir -p /etc/openvpn

Sous FreeBSD

mkdir -p /usr/local/etc/openvpn/

Configuration des clés SSL

Un paquetage de scripts est disponible lors de l'installation d'OpenSSL, nous allons l'utiliser pour générer l'ensemble des clés de chiffrement.

Sous Linux:

cd /usr/share/doc/openvpn/examples/easy-rsa/2.0

Sous FreeBSD:

cd /usr/local/share/doc/openvpn/easy-rsa/2.0
chmod +x *

Le fichier vars permet de spécifier des options SSL de génération de clés, je vous suggère de l'ouvrir et de modifier les champs appropriés (KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, ...)

vi ./vars

Sous FreeBSD, il faudra utiliser bash/zsh afin que la commande export fonctionne, ainsi que la prochaine commande.

Ensuite nous allons exécuter ce fichier afin de garder la configuration dans l'environnement actuel

. ./vars

Afin de préparer la distribution des clés un petit script bien pratique permet de nettoyer toutes les données:

./clean-all

et maintenant nous allons générer les clés du serveur (diffle-hellman et le CA):

./build-ca
./build-server-key servername (ou build-key-server servername)
./build-dh

Configuration du serveur (mode tun)

Copiez les fichiers keys/ca.crt, keys/server.crt et keys/server.key dans ce dossier.

Nous allons maintenant décompresser le fichier de configuration d'exemple.

Sous Debian:

gunzip /usr/share/doc/openvpn/examples/sample-config-files/server.tar.gz
cp server.conf /etc/openvpn/server.conf
vi /etc/openvpn/server.conf

Sous FreeBSD:

cp /usr/local/share/doc/openvpn/sample-config-files/server.conf /usr/local/etc/openvpn/server.conf
vi /usr/local/etc/openvpn/openvpn.conf

Nous allons pouvoir désormais configurer openvpn. Commencez par éditer les lignes suivantes:

port 443
proto tcp

Ces règles permettront d'outrepasser la plupart des sécurités non intelligentes et ainsi de se connecter partout via le tunnel. Vous pouvez aussi spécifier le protocole UDP afin de gagner en rapidité mais il n'est pas dit que votre tunnel marche partout.

Modifiez la règle suivant afin de spécifier votre plage d'adresses locales:

server 10.1.4.0 255.255.255.0

Celle-ci définira le range 10.1.4.0/24 comme étant celui où sont l'ensemble des clients. Il est fortement conseillé d'utiliser des plages d'adresses IP non routables sur Internet (contenues dans 10.0.0.0/8, 172.16.0.0/16, 192.168.0.0/16 par exemple).

Maintenant nous allons nous intéresser au routage, la chose la plus importante. Chaque directive route enverra au client une commande lui imposant d'ajouter une route vers le tunnel VPN. Nous allons tout d'abord router comme il se doit le flux du VPN vers celui-ci

route 10.1.4.0 255.255.255.0

Ensuite, si vous souhaitez rediriger l'ensemble du trafic vers le tunnel, entrez simplement la commande suivante:

push "redirect-gateway def1"

Si vous ne souhaitez pas rediriger tout le trafic mais seulement certaines routes, utilisez plutôt le push route.

push route 8.8.0.0 255.255.0.0
push route 15.14.6.0 255.255.255.0

Lorsque vous serrez dans le tunnel VPN vous ne pourrez plus contacter votre DNS local, une directive permet de modifier votre DNS tant que la connexion est active.

push "dhcp-option DNS 147.56.36.197"

Voici deux options intéressantes en terme de gestion de clients. La première permet que les clients VPN se voient entre eux et la seconde permet d'autoriser plusieurs personnes à utiliser le même certificat (si non activé la seconde connexion sera rejetée)

client-to-client
duplicate-cn

Pour terminer gérons les logs:

log         /var/log/openvpn.log
log-append  /var/log/openvpn.log

Vous pouvez désormais lancer le service

service openvpn start

Il ne reste plus qu'à configurer le NAT et le routage.

Sous Linux, tapez les deux commandes suivantes, que je vous recommande de mettre dans le fichier /etc/rc.local afin qu'au redémarrage vous ne perdiez pas les règles:

echo "1" > /proc/sys/net/ipv4/conf/all/forwarding
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Sous FreeBSD, activez tout d'abord le routage et Packet Filter pour les prochains démarrages en ajoutant les lignes suivantes au fichier /etc/rc.conf:

gateway_enable="YES"
pf_enable="YES"

Puis activez les pour la configuration actuelle:

sysctl net.inet.ip.forwarding=1
pfctl -e

Configuration du client

Chaque client OpenVPN est défini par une clé SSL.Pour créer une clé SSL pour un client, il suffit d'aller dans le répertoire de easy-rsa et taper

./build-key name

Cela va générer un fichier .key et un fichier .crt qu'il faudra placer dans le dossier openVPN qui va bien. En ce qui concerne le fichier de configuration, vous en trouverez un ici: /usr/share/doc/openvpn/examples/sample-config-files/client.conf à vous de personnaliser le port et le serveur ainsi que le nom des certificats.

Attention, le client doit être lancé en root ou administrateur windows afin de pouvoir modifier les règles de routage. Authentification via LDAP

On va aller plus loin en poussant cette fois-ci vers l'authentification LDAP. Ceci permet de n'utiliser qu'un certificat unique et ainsi d'identifier les utilisateurs via votre annuaire favori.

Installez tout d'abord le paquet openvpn-auth-ldap.

Sous Debian:

apt-get install openvpn-auth-ldap

Sous FreeBSD:

pkg install openvpn-auth-ldap
# Ou via les ports
cd /usr/ports/security/openvpn-auth-ldap
make install clean

Créez un fichier nommé auth-ldap.conf dans le dossier /etc/openvpn et éditez les options afin de vous connecter sur votre annuaire

<LDAP>
      # LDAP server URL
      URL             ldap://ldap.domain.tld

      # Bind DN (If your LDAP server doesn't support anonymous binds)
      # BindDN                uid=Manager,ou=People,dc=example,dc=com

      # Bind Password
      # Password      SecretPassword

      # Network timeout (in seconds)
      Timeout         15

      # Enable Start TLS
      TLSEnable       no
  </LDAP>

  <Authorization>
      # Base DN
      BaseDN          "ou=people,dc=domain,dc=tld"

      # User Search Filter
      SearchFilter    "(uid=%u)"

      # Require Group Membership
      RequireGroup    false

      # Add non-group members to a PF table (disabled)
      #PFTable        ips_vpn_users
  </Authorization>

</LDAP>

Vous pouvez filtrer suivant le groupe ou encore via un filtre LDAP classique les utilisateurs.

On va ensuite binder le module sur le serveur OpenVPN en ajoutant la ligne suivante dans le fichier server.conf:

plugin /usr/lib/openvpn/openvpn-auth-ldap.so /etc/openvpn/auth/auth-ldap.conf

Vous pouvez désormais redémarrer le service. Pour que les clients soient invités à entrer leurs identifiants LDAP, il faut ajouter la directive suivante dans leur configuration.

auth-user-pass

Sans cette directive les clients ne pourront pas se loguer.

Samba + Active Directory

Introduction

Un serveur samba est un partage de fichiers de type Windows. Dans un environnement hétérogène régi par un contrôleur de domaine Active Directory il peut être utile de stocker les profils, documents et lecteurs réseaux sur des serveurs Linux. Nous allons voir comment configurer un serveur Linux pour faire serveur de fichiers Windows. Installation

3 méta packages sont nécessaires pour créer ce serveur de fichiers

apt-get install samba winbind acl libpam-mkhomedir

Configuration de winbind

Pour configurer le login via winbind éditez le fichier /etc/nsswitch.conf de la façon suivante :

passwd:         compat winbind
group:          compat winbind
shadow:         compat winbind
hosts:          files dns
networks:       files
protocols:      db files
services:       db files
ethers:         db files
rpc:            db files
netgroup:       nis

Création automatique de répertoire personnel

Afin que chaque utilisateur aie directement un homedir dès son premier login, il faut configurer le pam pour utiliser le module mkhomedir. Editez le fichier /etc/pam.d/common-account. Si la ligne suivante n'y est pas ajoutez la.

session    required     /lib/security/pam_mkhomedir.so skel=/etc/skel umask=0022

Le dossier /etc/skel contient les fichiers de base que vous souhaitez voir dans le répertoire de l'utilisateur à sa création Configuration de samba

Ouvrez maintenant le fichier /etc/samba/smb.conf. Nous allons l'intégrer au domaine AD existant en modifiant les paramètres suivants:

[global]
   workgroup = DOMAIN
# nom court de votre serveur AD
   password server = activedirectory
# domaine
   realm = DOMAIN.TLD
# nom du serveur de fichiers
   netbios name = hera-bis
# cohérence samba - AD
   security = domain
   encrypt passwords = true
   passdb backend = tdbsam
   obey pam restrictions = yes
   unix password sync = yes
# Spécifications AD
   idmap uid = 10000-20000
   idmap gid = 10000-20000
# On créé des homedir dans le répertoire /dta/homes/<username>
   template shell = /bin/bash
   template homedir = /data/homes/%U
   winbind enum groups = yes
   winbind enum users = yes
   winbind use default domain = yes
   prefered master = no
# quota disque
   max disk size = 10000

# Répertoires homes de l'utilisateur avec des droits corrects
[homes]
comment = Home Directories
browseable = no
writeable = yes
guest ok = no
directory mask = 2700
create mode = 0664
# conserver les droits Posix Windows
store dos attributes = yes
# les fichiers Linux commençant avec un . seront des fichiers cachés
hide dot files = yes
nt acl support = no

Enregistrement dans le domaine

On va joindre tout d'abord le domaine afin d'être reconnu du serveur Active Directory, entrez les identifiants d'un administrateur du domaine.

net ads join -U Administrateur%password

Afin de ne pas perdre la connectivité au domaine, rajoutez également la ligne suivante dans /etc/crontab

*/5 *   * * * root net ads join -U Administrateur%password

On va également rajouter dans le fichier /etc/rc.local la commande afin qu'elle soit effectuée au démarrage du serveur

net ads join -U Administrateur%password

Note: le fichier /etc/rc.local n'existe plus sur systemd. Il faut passer par une unit en mode oneshot

Lancement des services

Lancez maintenant les services

service samba start && service winbind start

Vous pouvez vérifiez que le domaine est joignable et lister les utilisateurs avec la commande wbinfo -u, et les groupes avec la commande wbinfo -g.

Votre serveur de fichiers samba est désormais relié à votre annuaire ActiveDirectory.

Syslog-ng

Introduction

Les logs sont l'élément essentiel de toute administration de systèmes et de réseaux. Ils permettent d'obtenir des informations concernant l'état des services, les diverses échecs, pannes, informations de comportement, qu'ont décidé de rendre visible les développeurs. Dans le monde Linux, les logs sont nettement plus poussés que dans le monde Windows. Ils sont le point clé de la compréhension de tout service.

Les logs sont stockés conventionnellement dans un dossier bien spécifique: /var/log, où ils sont répartis dans diverses fichiers/répertoires. La gestion des logs est effectuée par un démon que l'on appelle le syslog, par exemple rsyslog (par défaut sous Debian), syslog (version basique sur openSuse et redhat, ou encore syslog-ng.

Certains fichiers de logs sont des clés de voûte de la compréhension du comportement du système. Il s'agit de /var/log/syslog, qui contient les informations sur les services tournant sur la machine, de auth.log qui recence tous les problèmes d'authentification (PAM, SSH, ...) ou encore de kern.log qui correspond aux messages provenant du noyau linux. Les services ont également un log propre qui est généralement un fichier ou un ensemble de fichiers contenu dans un répertoire du nom du service.

Les logs ont généralement des niveaux de sévérité (DEBUG, INFO, WARN, CRIT, ...) qui correspondent au niveau de séverité du message qu'il fournit.

Conformément à la loi du 23 janvier 2006 du code des postes et communications électroniques (vous pourrez le lire ici), les administrateurs et ingénieurs systèmes ont pour obligation de garder une trace écrite non altérée des connections et des utilisations de leur réseau par les employés de l'entreprise dont ils ont la charge. Ces logs doivent être stockés sur un serveur extérieur, en théorie un serveur sur lequel vous n'aurez jamais la main, mais en partique c'est quasiment impossible, qui sera chargé de centraliser l'ensemble des logs de connexion et de navigation de vos utilisateurs. En cas d'enquête judiciaire, si une attaque de type terroriste ou contre la nation est véhiculée via votre réseau, vous devez avoir ses logs sous peine d'être sanctionnées.

Les logs doivent être conservés durant 1 an glissant au maximum. Ceux-ci sont consultable à volonté durant cette période mais n'auront de valeur juridique pour l'entreprise que durant les 6 mois suivant l'action enregistrée. Les logs ne peuvent être demandés aux divers services informatique de force sans l'accord d'un juge assermenté.

Cette problématique juridique, nous conduit donc sur ce tutoriel. Comment mettre en oeuvre un serveur de logs sécurisé respectant l'ensemble des conditions légales permettant à votre entreprise d'être "sur les rails". Serveur de logs Installation

Nous allons ici utiliser le paquet syslog-ng pour sa puissance et le paquet logrotate pour la fonction de glissement des logs.

apt-get install syslog-ng logrotate

Configuration des logs glissants

Nous allons tout d'abord configurer le glissement. Ouvrez le fichier /etc/logrotate.conf

monthly
rotate 12
create

/var/log/* {
    monthly
    rotate 12
    create 640 root adm
    compress
}

include /etc/logrotate.d

Ce fichier de configuration définit le logrotate tous les ans, avec création du fichier une fois supprimé au bout d'un an. La section /var/log/* définit des droit particulier sur les fichiers de ce répertoire. La directive enrichie create permet de définit les droits et propriétaires du fichier. La directive compress définit la compression du fichier une fois la taille de celui-ci trop grande.

Vous trouverez également dans le dossier logrotate.d des scripts particuliers à chaque service qu'il faudra reconfigurer pour faire perdurer 1 an.

Configuration du serveur de logs

Configurons maintenant le service syslog-ng. Ouvrez le fichier /etc/syslog-ng/syslog-ng.conf et supprimez l'ensemble du contenu pour refaire une configuration au propre

options { long_hostnames(on); flush_lines(0); use_dns(no); use_fqdn(no);
        owner("root"); group("adm"); perm(0640); stats_freq(0);
        bad_hostname("^gconfd$");
};

source s_src { unix-dgram("/dev/log"); internal();
           file("/proc/kmsg" program_override("kernel"));
};

source s_net { udp(port(65001)); };

destination net_auth{ file("/ARCHIVED-LOGS/$HOST/$YEAR/$MONTH/$DAY/auth.log" create_dirs(yes)); };
destination local_logs{ file("/var/log/syslog" create_dirs(yes)); };

filter f_debug { match("debug"); }
filter f_auth { not filter(f_debug); };

log { source(s_net); filter(f_auth); destination(net_auth);};
log { source(s_src); destination(local_logs);};

Les options en début de fichier permettent de définit l'utilisation des noms DNS des machines, le propriétaire des fichiers de logs et les permissions associées à celui ci.

Les logs avec syslog-ng sont managés par 3 catégories spécifiques:

  • La source

La source est l'endroit d'où proviennent les logs. Dans le cas de s_src il s'agit des logs de la machine. Nous les enverrons ici vers le syslog classique. Pour s_net, ces logs seront archivés et reçus sur le port 65001 qu'écoutera le serveur de logs. Il est conseillé d'utiliser UDP pour gagner du temps au vu du nombre d'entrées qui vont transiter sur le réseau.

  • La destination

La destination définit le lieu où vont être écrits les logs. Ici nous utilisons des variables syslog-ng afin de répartir les logs dans des répertoires correspondant à des machines, puis par année, mois, jour. L'option create_dirs doit être positionnée à yes afin d'éviter à avoir à créer les dossiers soit même à la main chaque jour.

  • Le filtre

Le filtre va permettre de pouvoir interragir avec le log pour le classer de façon plus précise. Notre filtre f_auth va vérifier que le log est bien un log d'authentification qui n'est pas un log de debug pour le mettre dans auth.log. La directive match permet de définir le filtre à vrai si la chaîne est trouvée dans le log et est très pratique, par exemple pour apache afin de séparer les diverses erreurs HTTP.

Pour terminer, la directive log va prendre une ou plusieurs sources, filtrée ou non par un ou plusieurs filtres et l'envoyer vers une ou plusieurs destinations.

La puissance du syslog-ng réside dans la hiérarchisation logique de vos logs. Avec ces 3 éléments vous avez de quoi logguer de façon efficace vos serveurs. Vous pouvez bien entendu écouter plus de ports pour pouvoir hiérarchiser vos logs encore plus efficacement en définissant quel service utilisera quel port.

Maintenant étudions le comportement niveau client.

Configuration côté client

Sur vos switches CISCO, Dell... la manipulation est très simple

logging 10.0.0.250

Le paquet sera envoyé en UDP sur le port 514

Maintenant étudions sur les machines Linux, installez le paquet syslog-ng s'il n'y est pas puis ouvrez le fichier /etc/syslog-ng/syslog-ng.conf

options { long_hostnames(off); flush_lines(0); use_dns(no); use_fqdn(no);
        owner("root"); group("adm"); perm(0640); stats_freq(0);
        bad_hostname("^gconfd$");
};

source s_src { unix-dgram("/dev/log"); internal();
           file("/proc/kmsg" program_override("kernel"));
};
source s_apache2 { file("/var/log/apache2/access.log"); };

destination log_server {udp("serveurdelogs.lan" port(65001)); };
destination log_local_server { file("/var/log/local_syslog };
destination log_local_apache { file("/var/log/apache2/local_access.log};

log { source(s_src); destination(log_server); destination(log_local_server)};
log { source(s_apache2); destination(log_server); destination(log_local_apache)};

Les directives sont similaires à celles du serveur de log, seul changement, la destination est un serveur en UDP sur le port 65001 comme le définit la directive:

udp("serveurdelogs.lan" port(65001));

Nous stockons une copie en local pour la simplicité d'utilisation, de surcroît, mais avec un nom différent. Pourquoi un nom différent ? Si vous ne faîtes pas ceci vous allez engendrer une boucle infinie de lecture écriture qui va saturer l'ensemble de la place disponible sur votre disque dur en moins de 10 minutes.

Et on termine par le redémarrage du service

service syslog-ng restart

Vous savez désormais manipuler le syslog-ng et stocker vos logs de manière centralisée.

PAM+LDAP

Introduction

Les annuaires sont de nos jours de plus en plus utilisés afin de centraliser les informations et l'identification des utilisateurs. Que ce soit un ActiveDirectory (Microsoft) ou un OpenLDAP, il est souvent nécessaire de pouvoir permettre aux équipements de se connecter dessus.

Dans certains établissements, les DSI ont choisi d'authentifier les utilisateurs des machines via leur annuaire. Pour les utilisateurs Windows, il suffira simplement d'utiliser un ActiveDirectory, coûteux et pratique, mais les utilisateurs Linux se retrouvent de côté.

Nous allons vous montrer dans ce tutoriel comment permettre à votre machine Linux (client ou serveur) d'autoriser l'authentification LDAP via le PAM.

Installation

Afin d'installer l'authentification ldap nous allons utiliser le gestionnaire de paquets

apt-get install libpam-ldap libpam-cracklib libpam-mkhomedir

Le paquet libpam-mkhomedir permettra de créer les répertoires utilisateurs au premier login. Configuration

Ouvrez le fichier /etc/nssswitch.conf et vérifiez que les champs passwd, group et shadow renseignent bien le mot-clé ldap.

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

L'ordre des mots clés signifie que pam va tout d'abord chercher l'utilisateur dans les fichiers puis sur le serveur LDAP.

Nous allons maintenant configurer la connexion LDAP. Ouvrez (ou créez) le fichier /etc/libnss-ldap.conf et configurez comme ci-dessous:

host ldapserver # nom de l'host
uri ldap://ldap.domain.tld # uri de LDAP
ldap_version 3
binddn cn=ldap,dc=domain,dc=tld
bindpw myldappwd
rootbinddn cn=ldap,ou=read-only,dc=domain,dc=tld
port 389
bind_policy soft # booter le service meme si certaines erreurs de connexion
pam_filter objectclass=* # filtre les entrées qui peuvent utiliser le PAM

Le mot de passe de l'utilisateur LDAP n'est pas indiqué. Les concepteurs de la solution ont choisi de le déporter dans le fichier Si vous avez lu, l/etc/libnss-ldap.secret.

Ouvrez donc le fichier et renseignez le mot de passe. N'oubliez pas de retirer l'accès en lecture aux utilisateurs non sollicités. Application de la configuration

service slapd restart

Vos utilisateurs peuvent désormais se connecter en login LDAP sur vos machines linux.