389 Directory ServerDébut 2019, j’ai rédigé une série d’articles sur la mise en place d’une authentification centralisée (SSO ou Single Sign-On) basée sur NIS (Network Information Service) et NFS (Network File System). Cette configuration avec un os dans le nez s’avère certes robuste et fiable au quotidien, mais elle n’est pas sécurisée, car les données d’authentification des utilisateurs transitent en clair dans le réseau local. C’est d’ailleurs une des raisons pour lesquelles Red Hat a décidé de ne plus supporter NIS dans les versions futures.

Introduction

Une configuration SSO sécurisée passe nécessairement par l’utilisation d’un annuaire LDAP (Lightweight Directory Access Protocol). Dans ce domaine, le monde de l’Open Source offre une série de solutions concurrentes.

Notons au passage que dans l’univers propriétaire, Microsoft Active Directory est l’implémentation la plus populaire de LDAP.

Ces dernières semaines, j’ai abondamment testé les trois solutions libres. J’ai retenu 389 Directory Server, qui est à Red Hat Directory Server ce que CentOS est à Red Hat Enterprise Linux.

389 Directory Server a passé quelques années dans le monde commercial chez Netscape avant de faire son retour sur la scène de l’Open Source. C’est une solution robuste et éprouvée, et qui dispose d’une documentation professionnelle digne de ce nom. Non content de cela, elle est relativement simple à mettre en oeuvre et vous évite d’aller mettre les mains dans le cambouis du protocole LDAP.

Cet article décrit donc en détail l’installation et la configuration de 389 Directory Server sur un serveur CentOS 7. Cette machine hébergera les informations d’identification des utilisateurs de notre réseau local.

Documentation

Je disais que la documentation de 389 Directory Server était très professionnelle. Selon le Code du Grand Troupeau de Chats qui stipule que les choses ne doivent jamais être bien claires dans le monde de l’Open Source, la documentation n’est pas immédiatement utilisable telle quelle et nécessite quelques mises en gardes liminaires.

  • Le site officiel du projet arbore certes un document Quick Start, mais qui ne fonctionne pas sous CentOS, car cette distribution utilise la version précédente avec des commandes différentes.
  • Une mention peu visible sur le site du projet préconise l’utilisation de la documentation de Red Hat Directory Server 10.
  • La principale différence entre RHDS et 389 DS, c’est le nom des paquets (redhat-ds vs. 389-ds) et des commandes (redhat-ds-console vs. 389-console).

La documentation fournie par Red Hat est excellente et exhaustive. Comprenez par là qu’elle explique très bien les choses sur plusieurs centaines de pages. Par moments, on a l’impression de chercher la recette d’une sauce bolognese et de se retrouver à faire des études de biochimie alimentaire. En fin de compte, je me suis surtout servi des documents suivants.

  • RHDS Installation Guide chapitres 1 à 3.
  • RHDS Administration Guide chapitres 1 et 9.

Aide & Remerciements

La liste de diffusion 389-users@lists.fedoraproject.org est sans doute la meilleure adresse pour trouver de l’aide.

Je tiens à remercier les personnes suivantes pour leur gentillesse et leur aide précieuse lors de mes expérimentations.

  • Marc Muehlfeld (Red Hat)
  • William Brown (SUSE)

Prérequis

Ouvrir les ports 389 (LDAP) et 636 (LDAPS) en TCP dans le pare-feu.

J’utilise SELinux en mode renforcé, mais cela ne nécessite aucune configuration particulière.

La configuration DNS du serveur doit être correcte.

$ host amandine.microlinux.lan
amandine.microlinux.lan has address 192.168.2.5
$ host 192.168.2.5
5.2.168.192.in-addr.arpa domain name pointer amandine.microlinux.lan.

Éditer /etc/sysctl.conf et ajouter les paramètres suivants.

net.ipv4.tcp_keepalive_time = 300
net.ipv4.ip_local_port_range = 1024 65000
fs.file-max = 64000

Éditer /etc/profile et ajouter une ligne à la fin.

unset i
unset -f pathmunge
ulimit -n 8192

Si la machine n’est pas assez performante, il se peut que l’on se retrouve avec ce message d’erreur à la prochaine connexion.

Last login: Tue Aug 27 08:00:13 2019 from alphamule.microlinux.lan -bash:
ulimit: open files : cannot modify limit: Operation not permitted

Dans ce cas, on peut réduire la valeur.

unset i
unset -f pathmunge
ulimit -n 4096

Éditer /etc/pam.d/login et ajouter une ligne à la fin.

session    include      system-auth
session    include      postlogin
-session   optional     pam_ck_connector.so
session   required    /usr/lib64/security/pam_limits.so

Redémarrer le serveur.

Installation

Le paquet 389-ds-base est fourni par les dépôts officiels de CentOS. C’est le « minimum syndical » de 389 Directory Server. Pour travailler confortablement, il vaut mieux installer la console d’administration fournie par le dépôt EPEL. Le métapaquet 389-ds installe une configuration complète et cohérente.

$ sudo yum install 389-ds

Si l’on travaille sur un serveur sans système graphique, on pourra installer le paquet suivant pour exporter la console graphique via SSH.

$ sudo yum install xorg-x11-xauth

Configuration initiale

Le script setup-ds-admin.pl permet de configurer le serveur assez confortablement. Si vous avez déjà mis en place un serveur OpenLDAP en éditant une floppée de fichiers *.ldif, vous apprécierez sans doute. Notez que si vous appuyez simplement sur [Entrée], le script acceptera la valeur entre crochets proposée par défaut.

$ sudo setup-ds-admin.pl
...
Would you like to continue with set up? [yes]: yes

Le script vérifie si le système de base remplit bien toutes les conditions requises.

389 Directory Server system tuning analysis version 14-JULY-2016.
NOTICE : System is x86_64-unknown-linux3.10.0-957.27.2.el7.x86_64 (2 processors).
Would you like to continue? [yes]: yes

389 Directory Server offre trois formules pour configurer l’installation de base, avec des degrés de granularité variables.

  1. Express
  2. Typical
  3. Custom

Nous allons opter pour la méthode proposée par défaut.

Choose a setup type [2]: 2

Ici, nous devons impérativement renseigner le nom d’hôte pleinement qualifié (FQDN) du serveur. Notons que c’est normalement le seul point où nous n’utilisons pas la valeur proposée par défaut.

Computer name [amandine]: amandine.microlinux.lan

L’installation de 389 Directory Server crée un utilisateur système dirsrv et un groupe système correspondant.

System User [dirsrv]: dirsrv
System Group [dirsrv]: dirsrv

Pour l’instant, nous n’utilisons qu’un seul serveur pour notre annuaire, et nous n’avons donc pas besoin de configurer la réplication entre machines.

Do you want to register this software with an existing
configuration directory server? [no]: no

L’installation crée deux administrateurs qui n’ont pas exactement le même rôle. Sans trop rentrer dans les détails, l’administrateur admin possède tous les droits sur l’installation.

administrator ID [admin]: admin
Password: ********
Password (confirm): ********

La configuration du serveur LDAP est elle-même stockée dans un annuaire LDAP, mais le serveur doit savoir dans quel domaine il doit la ranger. Acceptez simplement le choix par défaut.

Administration Domain [microlinux.lan]: microlinux.lan

Le serveur LDAP utilise le port 389 par défaut.

Directory server network port [389]: 389

Notre installation est identifiée par le nom d’hôte simple par défaut.

Directory server identifier [amandine]: amandine

La prochaine question concerne l’organisation de notre DIT (Directory Information Tree). Le choix par défaut convient très bien.

Suffix [dc=microlinux, dc=lan]: dc=microlinux,dc=lan

Le deuxième administrateur de notre installation, c’est le Directory Manager. Ses droits sont quelque peu restreints par rapport à l’administrateur admin. En revanche, c’est cette identité-là que nous allons utiliser au quotidien pour administrer notre annuaire.

Directory Manager DN [cn=Directory Manager]: cn=Directory Manager
Password: ********
Password (confirm): ********

Dans la configuration par défaut, la console d’administration utilise le port 9830.

Administration port [9830]: 9830

Il ne reste qu’à confirmer par yes pour enregistrer toutes les modifications.

Are you ready to set up your servers? [yes]: yes

Le script se charge de configurer l’ensemble des composants de l’installation. Le déroulement de toutes ces opérations est enregistré dans un journal /tmp/setupXXXXXX.log. Ce n’est pas une mauvaise idée de jeter un oeil dedans pour voir si tout s’est bien déroulé.

The admin server was successfully started.
Admin server was successfully created, configured, and started.
Exiting . . .
Log file is '/tmp/setupDqEvhO.log'

Vérifier sommairement si la base LDAP est correctement configurée.

$ ldapsearch -x -b "dc=microlinux,dc=lan"
# extended LDIF
#
# LDAPv3
# base <dc=microlinux,dc=lan> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# microlinux.lan
dn: dc=microlinux,dc=lan
objectClass: top
objectClass: domain
dc: microlinux

# Directory Administrators, microlinux.lan
dn: cn=Directory Administrators,dc=microlinux,dc=lan
objectClass: top
objectClass: groupofuniquenames
cn: Directory Administrators
uniqueMember: cn=Directory Manager

# Groups, microlinux.lan
dn: ou=Groups,dc=microlinux,dc=lan
objectClass: top
objectClass: organizationalunit
ou: Groups

# People, microlinux.lan
dn: ou=People,dc=microlinux,dc=lan
objectClass: top
objectClass: organizationalunit
ou: People
...

Gestion des services

389 Directory Server est essentiellement constitué de deux services.

  • dirsrv.target : le serveur d’annuaires à proprement parler
  • dirsrv-admin : le serveur d’administration

Les deux services ont été lancés par la procédure de configuration initiale. Pour la suite, il suffit de définir leur lancement au démarrage de la machine.

$ sudo systemctl enable dirsrv.target
$ sudo systemctl enable dirsrv-admin

Connexion à la console d’administration

En temps normal, un serveur Linux est dépourvu de tout environnement graphique. Or, la console d’administration de 389 Directory Server nécessite un affichage graphique. Dans ce cas, on a deux possibilités.

  1. Installer un gestionnaire de fenêtres léger sur le serveur.
  2. Déporter l’affichage X11 avec SSH.

Si l’on dispose d’un environnement graphique, on peut lancer la console directement.

$ 389-console

Sous WindowMaker, faites un clic droit sur le bureau, cliquez sur Exécuter dans le menu, tapez 389-console et cliquez sur OK.

Autrement, on peut l’ouvrir depuis un poste de travail Linux du réseau local. Ici, l’utilisateur microlinux se connecte à 389 Directory Server installé sur la machine 192.168.2.5.

$ ssh -X microlinux@192.168.2.5 /usr/bin/389-console -a http://192.168.2.5:9830

La fenêtre d’identification du serveur vous demande de fournir quelques renseignements.

  • User ID : cn=Directory Manager.
  • Password : le mot de passe défini pour l’administrateur Directory Manager.
  • Administration URL : http://<ip_serveur>:9830 ou http://localhost:9830 si vous travaillez directement sur le serveur.

389 Directory Server

Si tout se passe bien, la fenêtre d’accueil de la console d’administration s’affiche.

389 Directory Server

Dans notre prochain article, nous traiterons en détail l’ajout des utilisateurs à notre annuaire LDAP.


7 commentaires

Mickael · 30 août 2019 à 19 h 15 min

As-tu tester Samba4 sous CentOS?
Merci pour tes articles toujours aussi intéressants.

    kikinovak · 30 août 2019 à 20 h 07 min

    Oui, il y a trois semaines environ. Et j’ai même écrit un article détaillé sur Samba.

      Mickael · 30 août 2019 à 23 h 13 min

      Oui j’ai vu 🙂 Je voulais dire SAMBA4 en mode Active Directory.

        kikinovak · 30 août 2019 à 23 h 29 min

        Je pense sincèrement que c’est le genre de configuration qui mène droit à l’alcoolisme. :o)

        Plus sérieusement, je pense que pour faire de l’Active Directory, la meilleure solution c’est Active Directory.

        Ceci étant dit, les réseaux que j’administre sont 100 % Linux, donc 389 DS + TLS + NFS c’est le top.

gnulux · 1 septembre 2019 à 18 h 13 min

Hello , très bon article merci pour ces notes.
J’ai moi même déployé la solution 389DS en entreprise pour du SSO avec keycloak, cela fonctionne à merveille.
Pour activeDirectory , un plugin existe dans 389DS , « Pam PassThrought » , cela permet d’authentifier sur 389ds des comptes utilisateurs présent sur l’AD.

Cependant, juste une question concernant les paramètres Kernel ci-dessous que tu précise.
net.ipv4.ip_local_port_range = 1024 65000
Pour moi ce paramètre n’a pas d’influence sur le comportement du serveur 389ds .
Il s’agirait plutôt d’un parametre à positionner coté client non ? .

    kikinovak · 1 septembre 2019 à 18 h 31 min

    En ce qui concerne Active Directory, je ne peux pas dire, vu que je ne l’utilise pas du tout au quotidien.

    Pour les paramètres kernel, une discussion est en cours sur la mailing list de 389 DS.

    Un gentil bonjour de la garrigue gardoise.

A French-Language Guide to Installing 389 DS on CentOS 7 – LDAP.com · 30 août 2019 à 16 h 53 min

[…] French-language Linux site Microlinux has posted a new blog post about installing the 389 Directory Server on Cent OS 7. In a message sent to the 389-users mailing […]

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.