Dans un effort de consolidation de la gestion de configuration au sein d´une équipe d´ingénierie système, je me suis penché sur le cas du service DNS. Et plus particulièrement sur la possibilité de stocker ses données au sein d´un annuaire LDAP. En effet, en y réfléchissant quelques instants, les données d’un service DNS sont principalement une liste de correspondance entre des noms de machines et son adresse IP ; ce qui ressemble fortement à un annuaire téléphonique : des noms en face de numéros de téléphone. Et donc, je me suis lancé dans l´expérimentation avec le serveur Bind 9 et l´annuaire 389 Directory Server. Je vous livre ici les résultats.

Objectif(s)

Installer et déployer un service DNS (Domain Name System, système de noms de domaine) reposant sur un annuaire LDAP. Cette pratique, qui peut paraître atypique, est pourtant parfaitement logique. Lightweight Directory Access Protocol ou LDAP est un protocole permettant l’interrogation et la modification des services d’annuaire. Or, quoi de plus normal que d’utiliser un annuaire et un protocole standardisé pour stocker des correspondances nom/IP comme c’est le cas pour un DNS ?

outil(s) utilisé(s)

Bind pour Berkeley Internet Name Domain est le serveur DNS le plus utilisé sur internet et donc forcément avec les systèmes de type UNIX. Bind est, de fait, un standard pour la mise en œuvre de ce genre de solutions, même si d’autres projets lui font concurrence ces dernières années. La première version de Bind a été conçue sur la base de 4.3BSD en 1988. 389 Directory Server est un serveur LDAP initialement développé par Red Hat par le projet communautaire Fedora. Il s’agit donc d’une solution identique au produit Red Hat Directory Server. Le choix de cet annuaire suggère donc l’utilisation de Fedora Core 11 dans un but de moindre effort. Pour la réalisation de cet article, je me suis appuyé sur une distribution Fedora Core 11 (Leonidas) [1] fraîchement installée avec le minimum de packages (en gros le groupe Core). Et comme nous sommes dans le monde Fedora, j´ai choisi le serveur d´annuaire proposé par la communauté Fedora : 389 Directory Server [2]. Pour le serveur DNS, je suis resté sur le très classique, et efficace, Bind 9 [3].

Note
Dans la suite de l´article, je parlerai de plusieurs produits issus des communautés Fedora et Mozilla. N´y voyez pas un quelconque prosélytisme de ma part, ni le signal d´une chasse au troll des montagnes. Plusieurs produits commerciaux de la société RedHat sont basés sur ces produits communautaires et je travaille en environnement RedHat. Et je ne touche pas le moindre euro de leur part ;)

Pour notre exemple, l´architecture est relativement simple et je me passerai de schéma. Nous aurons 3 machines dans le même réseau 10.0.2.0/24 (les plus rusés auront reconnu le réseau par défaut de VirtualBox) : le serveur LDAP (10.0.2.101), le serveur DNS (10.0.2.102) et une machine cliente (10.0.2.15). Pour se simplifier la vie, l´adressage est statique. Côté nommage, le réseau sera purement interne et aura pour suffixe localdomain.

1 389 Directory Server

Pour l´histoire, 389 Directory Server (389DS) est le nouveau nom de Fedora Directory Server, projet développé par la communauté Fedora à partir du code source de Netscape Directory Server, racheté en 2004, puis libéré par RedHat. Il est aussi la base du produit commercial RedHat Directory Server. Cet article reste donc facilement transposable au monde " professionnel " (aucun troll à chercher dans cette phrase) via les produits commerciaux de RedHat. Quelques aspects différencient 389DS du serveur OpenLDAP, plus connu et répandu dans la communauté open source : ● La configuration (à quelques exceptions près) est stockée dans l´annuaire lui-même. Il est dès lors possible d´appliquer des changements de configuration à partir d’un fichier LDIF sans redémarrer le serveur. ● Le serveur gère la réplication multi-maître. Un changement apporté sur l´un des maîtres est répercuté sur les autres. Cela permet de mettre en redondance le serveur maître en quelques lignes de configuration. Une politique d’intégrité des données peut être mise en œuvre pour limiter les risques de collision. ● Le serveur fournit un ensemble de composants complémentaires pour l´administration en mode web, la synchronisation des groupes et utilisateurs avec Active Directory... Je n´utiliserai que la brique de base, l´annuaire LDAP lui-même, pour cet article. De nombreux howtos sont disponibles dans la documentation du projet [4].

1.1 Installation et configuration de base

Sur une distribution Fedora, on peut s´attendre à ce que le logiciel soit packagé et donc accessible par une simple commande yum. Rassurez-vous, c´est le cas ! La preuve ci-dessous :

root# yum install 389-ds-base

Le package est installé et a mis à notre disposition les binaires pour la configuration dans l’arborescence système, ainsi que les binaires basés sur les bibliothèques LDAP développées par la communauté Mozilla [5] dans /usr/lib/mozldap, les fichiers de configuration dans /etc/dirsrv et les logs dans /var/log/dirsrv. Nous avons installé l´environnement nécessaire au fonctionnement de 389DS. Il est temps d´appuyer sur le contact pour entendre ronronner le moteur. Pour cela, il faut régler les paramètres de notre instance via le script /usr/sbin/setup-ds.pl. Ce script a la bonne idée de pouvoir prendre un fichier de configuration en paramètre pour automatiser l´installation. Je l´utilise donc avec le fichier /root/389ds/389ds-install.inf qui suit :

[General] FullMachineName=         ldap.localdomain SuiteSpotUserID=         nobody SuiteSpotGroup=          nobody [slapd] ServerPort=              389 ServerIdentifier=        localdomain Suffix=                  dc=localdomain RootDN=                  cn=Directory Manager RootDNPwd=               ldapPassword

Ce fichier ne doit être accessible en lecture qu’à root, et éventuellement supprimé après l’installation, car il contient le mot de passe d’administration de l’annuaire. L´installation se lance avec la commande ci-dessous. En cas de réussite de la configuration, l´instance d´annuaire configurée est démarrée automatiquement.

root# /usr/sbin/setup-ds.pl —silent —file=/root/389ds/389ds-installation.inf

Preuve supplémentaire de la collusion de 389DS avec sa version commerciale, la documentation d´un certain nombre de commandes est disponible dans la documentation du produit RedHat [6]. Entre autres, vous y trouverez les paramètres possibles pour le fichier utilisé par /usr/sbin/setup-ds.pl (à la section 5.5 de l’Installation Guide). Par défaut, et aucun paramètre n´est fourni dans la documentation pour changer cela, le service démarre en écoute sur toutes les adresses IP du serveur et ce n´est pas forcément ce que nous voulons. Pour cela, il faut que le serveur connaisse son adresse IP et que 389DS sache sur quelle adresse écouter. Le premier point est réglé en ajoutant une ligne dans /etc/hosts, le second en ajoutant une ligne dans /etc/dirsrv/slapd-localdomain/dse.ldif (créé lors de l´installation de l’instance). Cela nécessite l´arrêt du service, mais c´est plutôt compréhensible.

root# service dirsrv stop localdomain root# echo "10.0.2.101    ldap.localdomain ldap" >> /etc/hosts root# sed -i "/^nsslapd-port:/i\ nsslapd-listenhost: ldap.localdomain" /etc/dirsrv/slapd-localdomain/dse.ldif root# service dirsrv start localdomain ; chkconfig dirsrv on

1.2 Configuration SSL

Pour la gestion de la sécurité réseau, 389DS s´appuie sur les outils du projet Network Security Services (NSS), maintenu par la communauté Mozilla [7]. Cette suite fournit des outils de gestion des certificats, lesquels sont la base d´un autre produit, en association avec 389DS, DogTag PKI [8] développé par la communauté Fedora, et dont le pendant commercial est RedHat Certificate System. Et, une fois encore, la documentation est mixte Fedora/RedHat ([9] et chapitre 12 de l’Administration Guide [6]).