389 Directory Server as Bind 9 backend

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].

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 :

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 :

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.

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.

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]).

1.2.1 Gestion des certificats

NSS gère ses certificats à l´aide de bases BerkeleyDB [10]. La première étape est donc de créer la base de certificats pour notre instance d´annuaire. Pour simplifier les opérations, nous mettons le mot de passe de la base dans un fichier (que nous supprimerons très vite, je vous rassure).

Nous créons ensuite un certificat racine auto-signé (algorithme de chiffrement RSA avec une clé de 1024 bits) pour la mini-autorité de certification (CA : Certificate Authority) locale à notre instance. Vous avez la possibilité d´utiliser une « vraie » CA, mais c´est hors du scope de cet article ; regardez du côté de DogTag à l´occasion.

certutil vous posera 3 questions :

- Is this a CA certificate ? y

- Enter the path length constraint, enter to skip : appuyez sur Enter

- Is this a critical extension ? y

L´étape suivante est la création du certificat serveur pour notre instance de serveur d´annuaire, signé par le certificat racine.

Normalement, ce n´est pas nécessaire, mais on s'assure que tous les fichiers des bases de certificats appartiennent à l´utilisateur propriétaire des processus de notre l´instance de serveur d'annuaire (nobody).

Pour être tranquille en cas de crash de la machine et de perte irréversible du répertoire de l´instance, nous exportons nos certificats pour les stocker ailleurs. Cette étape est optionnelle si vous utilisez votre propre Infrastructure à Clé Publique (PKI : Public Key Infrastructure).

Les certificats principaux ont été générés. Nous n´avons donc plus besoin de stocker le mot de passe de la base de certificats :

1.2.2 Activation du support SSL pour l'annuaire

Comme évoqué précédemment, la configuration de l´instance d´annuaire peut se faire à chaud, car la configuration est stockée dans l´annuaire lui-même. Il en va de même pour la configuration du protocole SSL. Nous créons les fichiers /root/389ds/389ds-enableSsl.ldif et /root/389ds/389ds-addRsa.ldif ci-dessous.

Nous avons spécifié à l´instance d´annuaire que nous utilisons le protocole SSLv3 et que nous autorisons l´authentification par certificat utilisateur pour les clients (nsSSLCientAuth: allowed), bien que nous ne nous en servions pas ici. Nous avons aussi précisé la liste des algorithmes de chiffrement autorisés pour le protocole SSLv3 (nsSSL3Ciphers). Nous avons aussi désactivé la vérification du nom d´hôte dans le certificat, bien que notre exemple ne l´exige pas (je vous renvoie à la documentation pour les subtilités).

Nous avons ajouté le module de chiffrement RSA à la configuration de l´instance en lui précisant que le certificat est stocké localement (nsSSLToken) dans la base liée à l´instance, et que le certificat a pour nom « LDAP-Cert » (nsSSLPersonalitySSL).

La modification de la configuration peut maintenant se faire à chaud avec ldapmodify :

Le serveur a maintenant toutes les informations pour utiliser les certificats sauf une : le mot de passe de la base. Au prochain redémarrage du service, il vous demandera donc le mot de passe, ce qui ne vous amusera pas longtemps. 389DS offre la possibilité de stocker le mot de passe dans un fichier aux droits d´accès restreints pin.txt :

Comme nous l´avions fait pour le port 389, nous limitons l'écoute sur le port 636 (protocole LDAPS) à l'adresse IP du serveur.

Nos machines clientes doivent pouvoir vérifier l´identité du serveur LDAP qu´elles contactent via le protocole LDAPS. Pour cela, nous exportons les informations du certificat racine de la CA associée à l´instance pour pouvoir les déployer sur les machines clientes.

Et pour finir, ou presque, nous testons que la configuration fonctionne. Pour cela, nous précisons que nous utilisons le protocole SSL (-Z), le port (-p 636) et le fichier contenant la base de certificats (-P /etc/dirsrv/slapd-localdomain/cert8.db) :

Par défaut, le service iptables est démarré sur les machines à base de distribution Fedora. Je ne saurais que trop vous déconseiller de le désactiver. Donc, voici les règles à ajouter dans /etc/sysconfig/iptables :

1.3 Authentification des utilisateurs

Je sais que cette thématique est un peu hors sujet, mais c´est un bon exemple pour valider le fonctionnement de l´annuaire et un bon point de départ pour l´authentification centralisée de vos utilisateurs. Et un autre intérêt de cet exemple est que le changement de mot de passe nécessite la sécurisation de la communication par SSL, ajoutant un test grandeur nature de la configuration SSL.

1.3.1 Création des comptes utilisateurs et de groupes

Je ferai simple et rapide : un utilisateur fdupont et son groupe associé comme s´il avait été créé par Fedora en local. Le fichier /root/389ds/389ds-user_fdupont.ldif au format LDIF ci-dessous crée les entrées dans l´annuaire pour l´utilisateur et le groupe.

Nous injectons les données dans l´annuaire :

Nous positionnons le mot de passe de l´utilisateur que nous venons de créer :

Nous créons le répertoire HOME de l'utilisateur. Cette opération est à prévoir dans votre workflow de gestion des utilisateurs. Nous utilisons le programme utilisé par le module PAM mkhomedir pour la création automatique des HOME lors de l'authentification des utilisateurs ; nous aurions d'ailleurs pu laisser cette tâche à PAM.

1.3.2 Configuration de l'authentification PAM/LDAP

Pour que nos utilisateurs puissent se connecter au système, nous devons dire à PAM (Pluggable Authentication Module) de se connecter au serveur d´annuaire LDAP pour authentifier les utilisateurs. Au passage, nous modifions la configuration de nsswitch pour qu´il obtienne les informations sur les utilisateurs et les groupes par l´annuaire.

Mais, avant de lancer la configuration, nous devons installer deux packages supplémentaires : nscd, un démon qui gère un cache des données de nom et qui limite donc le volume de communications avec l´annuaire, et nss_ldap qui permet au service de gestion des noms (géré par /etc/nsswitch.conf) de s´interfacer avec un annuaire LDAP.

Manuellement, la configuration se fait en modifiant les fichiers suivants : /etc/nsswitch.conf, /etc/ldap.conf, /etc/openldap.conf, /etc/pam.d/system-auth et /etc/sysconfg/authconfig. Bref, beaucoup de manipulations de fichiers et de syntaxes à connaître. Nous allons donc faire appel à un petit utilitaire fourni par la distribution Fedora : authconfig [12]. En une ligne de commande, nous sommes sûrs que la configuration sera bonne, y compris si la liste des fichiers à modifier évolue.

Nous avons donc dit à authconfig que nous souhaitons :

- désactiver l´utilisation du protocole NIS (--disablenis) ;

- utiliser le démon de cache des données (--enablecache) ;

- utiliser un annuaire LDAP (--enableldap --enableldapauth) ;

- le serveur d´annuaire LDAP est ldap.localdomain ;

- le DN servant de base à la recherche est dc=localdomain ;

- la connexion nécessite l´utilisation de TLS (--enableldaptls)

- le certificat de la CA est disponible à l´URL file:///etc/pki/tls/certs/cacert.asc (je vous laisse explorer les possibilités de diffusion sur les clients) ;

- mettre à jour l´ensemble des fichiers de configuration (--updateall).

Nous pouvons tester assez simplement le résultat en nous connectant à la machine avec l´utilisateur que nous avons créé précédemment.

2. Installation de Bind 9 avec le backend LDAP

Maintenant que notre serveur d´annuaire est fonctionnel, nous pouvons passer à la seconde phase de notre projet : intégrer les données de notre serveur DNS à base de Bind 9 dans l´annuaire. Pour cela, nous utiliserons l´extension Simple DataBase (SDB) de Bind 9 pour laquelle il existe un backend LDAP [13] (des backends existent aussi pour MySQL et PostgreSQL).

Nous commençons par simplement installer Bind 9, et plus particulièrement la version chrootée, ainsi que l'extension SDB, disponibles sous forme de package RPM.

2.1 Intégration du schéma et arborescence de base

Pour pouvoir ajouter les données DNS à notre annuaire, nous devons expliciter la structure de ces données via un schéma. Celui-ci est disponible sur le site du projet de backend LDAP pour Bind 9 (URL ci-dessous), mais dans un format prévu pour OpenLDAP et qui n´est pas directement compréhensible par 389DS. Mais, heureusement, un convertisseur existe :

Nous avons arrêté le service d´annuaire, puis téléchargé le schéma (dnszone-schema.txt) et le script de conversion (ol-schema-migrate.pl) et installé la version convertie du schéma dans le répertoire où sont installés les schémas de notre instance d´annuaire (/etc/dirsrv/slapd-localdomain/schema), et nous avons redémarré le service. Notre instance d´annuaire sait maintenant traiter des données DNS.

Nous créons une arborescence spécifique pour stocker les données DNS, directement sous la racine de l´annuaire, ainsi qu´un utilisateur spécifique au service DNS. Nous souhaitons limiter les droits sur la consultation des données : nous ajoutons donc une ACI (Access Control Instruction) à l´annuaire pour que seul l´utilisateur cn=dnsadmin,ou=Special Users,dc=localdomain puisse consulter les données (je vous renvoie au chapitre 6 de l'Administration Guide [6] pour le fonctionnement des ACI). Cet utilisateur sera utilisé par Bind pour obtenir les données DNS. Nous créons donc le fichier LDIF /root/389ds/389ds-bind_base.ldif comme suit :

Nous ajoutons ces données à l´annuaire et positionnons le mot de passe pour l´utilisateur qui gère les données DNS :

2.2 Configuration de Bind 9

Nous pouvons passer à la configuration du serveur DNS. Cela se fait au travers de l'habituel fichier /etc/named.conf. Dans notre exemple, nous gérons l´espace de nommage de la zone localdomain sur le réseau 10.0.2.0/24, ce qui donne le fichier suivant (j´ai supprimé les sections DNSSEC créées par le package RPM, car ce n´est pas l´objet de l´article) :

Les sections intéressantes sont celles qui définissent les zones : nous utilisons le backend database au lieu du classique file. Nous lui précisons ensuite que nous passons par le protocole LDAP avec les paramètres suivants :

- l'URL de recherche : ldap://10.0.2.101/ou=localdomain,ou=dns,dc=localdomain???? ;

- le login de connexion : !bindname=... ;

- le mot de passe de connexion : !x-bindpw=... ;

- la connexion doit utiliser le protocole TLS : x-tls ;

- le TTL pour les entrées n´ayant pas d´attribut dNSTTL : 172800.

Si vous avez été un peu trop rapide et avez tenté de démarrer Bind, vous constaterez qu´il renvoie des erreurs et que les logs dans /var/log/messages indiquent qu´il n´y a pas de SOA pour les zones localdomain et 2.0.10.in-addr.arpa. Ceci est complètement normal, la branche de l´annuaire est vide, et nous allons y remédier dés maintenant.

2.3 Arborescence pour nos zones DNS

Dans un premier temps, nous créons l´arborescence minimale et les SOA. Pour cela, le fichier LDIF ci-dessous crée une entrée de type organizationalUnit par domaine : elle est le point d´entrée de l´arborescence de l´annuaire pour chaque domaine et contient au moins une entrée de type dNSZone dont l´attribut relativeDomainName est le nom du domaine géré, et une entrée de type dNSZone dont l´attribut relativeDomainName est @ et qui correspond au SOA du domaine.

L'injection se fait toujours via ldapmodify :

Il ne nous reste plus qu´à créer les enregistrements en tant que tels. Une fois encore, un simple fichier au format LDIF fera l´affaire. Nous créerons ici le minimum : les serveurs DNS et SMTP (indiqués dans le SOA) et le serveur LDAP. Le provisionning de l´annuaire est une procédure assez simplement scriptable et adaptable à votre environnement système, alors laissez aller votre imagination...

ldapmodify toujours à l'œuvre :

2.4 Finalisation

Nous avons alimenté notre annuaire avec les données DNS, configuré le service Bind pour qu´il utilise un annuaire LDAP comme source de données, limité l´accès à ces données à un utilisateur dédié. La dernière étape est probablement la plus simple : démarrer le service. Pourtant, un petit écueil reste à éviter : par défaut, le service named (Bind 9) est configuré pour démarrer avant le service dirsrv (389DS), empêchant Bind d´accéder aux données dans l´annuaire. Nous modifions donc l´ordre de démarrage de named avant de le démarrer :

De la même façon que nous avions ouvert les ports 389 et 686 sur le serveur LDAP, nous devons ouvrir le port 53 pour que le serveur DNS soit accessible des autres machines. Il suffit d´ajouter les lignes suivantes à /etc/sysconfig/iptables et redémarrer le service iptables :

Et le moment de vérité est arrivé : notre serveur DNS fonctionne-t-il comme attendu ? Vous me direz que ça dépend de moi et de l´attention que j´ai apportée à la relecture de l´article... Mais, hors coquille, en configurant le serveur de nom dans /etc/resolv.conf, les commandes suivantes devraient fournir les bonnes valeurs :

Et voilà ! Vous avez maintenant un serveur DNS pleinement fonctionnel et vos données sont stockées dans votre annuaire. Vous pouvez dorénavant mettre à jour vos données sans recharger named (sauf si vous ajoutez des zones). Et vous n'avez plus que les données de l'annuaire et /etc/named.conf à sauvegarder. Amusez-vous bien...

Remerciements

Je tiens à remercier Hamza Mokhtari et Sébastien Bonnegent pour leur talent de relecteur et leur amitié.

Références

[1] http://fedoraproject.org/

[2] http://directory.fedoraproject.org/

[3] https://www.isc.org/software/bind/

[4] http://directory.fedoraproject.org/wiki/Documentation#Howtos

[5] https://wiki.mozilla.org/LDAP_C_SDK

[6] http://www.redhat.com/docs/manuals/dir-server/

[7] http://www.mozilla.org/projects/security/pki/nss/

[8] http://pki.fedoraproject.org/

[9] http://directory.fedoraproject.org/wiki/Howto:SSL

[10] http://www.oracle.com/database/berkeley-db/index.html

[11] http://freeipa.org/page/Main_Page

[12] http://fedorahosted.org/authconfig/

[13] http://bind9-ldap.bayour.com/