Installer 389 Directory Server sous CentOS 7

Début avril, 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 après Red Hat Enterprise Linux 8.

• Introduction
• Documentation
• Aide & Remerciements
• Prérequis
• Installation
• Configuration initiale
• Gestion des services
• Connexion à la console d’administration

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.

• OpenLDAP
• FreeIPA
• 389 Directory Server

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

J’ai sommairement testé les trois solutions libres, et 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.

$ sudo firewall-cmd --permanent --add-service=ldap
$ sudo firewall-cmd --permanent --add-service=ldaps
$ sudo firewall-cmd --reload
$ sudo firewall-cmd --list-all
internal (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp2s0
  sources: 
  services: ldap ldaps ssh
  ports: 
  protocols: 
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 

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

La dernière mise à jour de Java comporte un bug prohibitif qui empêche la console d’administration de refuser correctement. En attendant que le problème soit résolu, il faut rétrograder les paquets java-1.8.0-openjdk et java-1.8.0-openjdk-headless vers la version 1.8.0.222.b10-1.

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.

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

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

---

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.