389 Directory Server as Bind 9 backend

GNU/Linux Magazine HS n° 045 | décembre 2009 | Fabien Dupont
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
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.
Note
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 ?

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

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

root# cd /etc/dirsrv/slapd-localdomain

root# echo 'secretPassword' > /tmp/pwdfile

root# chmod 0400 /tmp/pwdfile

root# certutil -N -d . -f /tmp/pwdfile

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.

root# certutil -S -n "CA certificate" -s "cn=CA cert,dc=localdomain" \

-x -t "CT,," -2 -m 1000 -v 120 -d . -k rsa -g 1024 -f /tmp/pwdfile

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.

root# certutil -S -n "LDAP-Cert" -s "cn=ldap.localdomain" -c "CA certificate" \

-t "u,u,u" -m 1001 -v 120 -d . -k rsa -g 1024 -f /tmp/pwdfile

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

root# chown nobody:nobody /etc/dirsrv/slapd-localdomain/*.db

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

root# pk12util -d . -o cacert.pfx -n "CA certificate"

root# pk12util -d . -o ldapcert.pfx -n "LDAP-Cert"

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 :

root# rm -f /tmp/pwdfile

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.

# /root/389ds/389ds-enableSsl.ldif

dn: cn=encryption,cn=config

changetype: modify

replace: nsSSL3

nsSSL3: on

-

replace: nsSSLClientAuth

nsSSLClientAuth: allowed

-

add: nsSSL3Ciphers

nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,+rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza,+fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha,+tls_rsa_export1024_with_des_cbc_sha,-rc4,-rc4export,-rc2,-rc2export,-des,-desede3

dn: cn=config

changetype: modify

add: nsslapd-security

nsslapd-security: on

-

replace: nsslapd-ssl-check-hostname

nsslapd-ssl-check-hostname: off

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

# /root/389ds/389ds-addRsa.ldif

dn: cn=RSA,cn=encryption,cn=config

changetype: add

objectclass: top

objectclass: nsEncryptionModule

cn: RSA

nsSSLPersonalitySSL: LDAP-Cert

nsSSLToken: internal (software)

nsSSLActivation: on

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 :

root# /usr/lib/mozldap/ldapmodify -h ldap.localdomain \

-D "cn=Directory Manager" -w - \

-f /root/389ds/389ds-enable_ssl.ldif

root# /usr/lib/mozldap/ldapmodify -a -h ldap.localdomain \

-D "cn=Directory Manager" -w - \

-f /root/389ds/389ds-addRsa.ldif

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 :

root# cat > /etc/dirsrv/slapd-localdomain/pin.txt << EOF

Internal (Software) Token: secretPassword

EOF

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

root# service dirsrv stop localdomain

root# sed -i "/^nsslapd-port:/i\

nsslapd-securelistenhost: ldap.localdomain" /etc/dirsrv/slapd-localdomain/dse.ldif

root# sed -i "/^nsslapd-port:/a\

nsslapd-secureport: 636" /etc/dirsrv/slapd-localdomain/dse.ldif

root# service dirsrv start localdomain

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.

root# cd /etc/dirsrv/slapd-localdomain

root# certutil -d . -L -n "CA certificate" -a > /etc/pki/tls/certs/cacert.asc

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) :

root# /usr/lib/mozldap/ldapsearch -Z -h ldap.localdomain -p 636 \

-P /etc/dirsrv/slapd-localdomain/cert8.db \

-D "cn=Directory Manager" -w - \

-s base -b "" '(objectclass=*)' | head

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 :

# 389DS LDAP Server : LDAP & LDAPS

-A INPUT -d 10.0.2.101 -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT

-A INPUT -d 10.0.2.101 -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT

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.

Note

Si la problématique de gestion des utilisateurs vous intéresse, je vous recommande de jeter un œil sur le projet FreeIPA [11] dont l'objectif est de fournir un outil de gestion centralisée des comptes utilisateurs/machines et de l'authentification en offrant des fonctionnalités d'audit de la politique mise en œuvre. Il s'agit là aussi d'un projet de la communauté Fedora.

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.

# /root/389ds/389ds-user_fdupont.ldif

dn: uid=fdupont,ou=People,dc=localdomain

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

objectClass: posixAccount

uid: fdupont

cn: Fabien Dupont

sn: Dupont

userPassword: test

mail: fdupont@localdomain

description: Fabien Dupont

gidnumber: 500

givenName: Fabien

homedirectory: /home/fdupont

loginshell: /bin/bash

telephonenumber: +33 1 23 45 67 89

uidnumber: 500

departmentNumber: Test Environment

dn: cn=fdupont,ou=Groups,dc=localdomain

objectclass: top

objectclass: groupofuniquenames

objectClass: posixGroup

cn: fdupont

gidNumber: 500

description: Groupe de Fabien Dupont

uniqueMember: dn: uid=fdupont,ou=People,dc=localdomain

Nous injectons les données dans l´annuaire :

root# /usr/lib/mozldap/ldapmodify -a -h ldap.localdomain \

-D "cn=Directory Manager" -w - \

-f /root/389ds/389ds-user_fdupont.ldif

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

root# /usr/lib/mozldap/ldappasswd -Z -h ldap.localdomain -p 636 \

-P /etc/dirsrv/slapd-localdomain/cert8.db \

-D "cn=Directory Manager" -w - \

-S uid=fdupont,ou=People,dc=localdomain

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.

root# mkhomedir_helper fdupont

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.

root# yum install nscd nss_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.

root# authconfig --disablenis --enablecache --enableldap --enableldapauth \

--ldapserver=ldap.localdomain --ldapbasedn=dc=localdomain \

--enableldaptls --ldaploadcacert=file:///etc/pki/tls/certs/cacert.asc \

--updateall

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.

root# yum install bind-chroot bind-sdb

root# echo 'ROOTDIR="/var/named/chroot"' >> /etc/sysconfig/named

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 :

root# service dirsrv stop localdomain

root# wget http://bind9-ldap.bayour.com/dnszone-schema.txt

root# wget http://directory.fedoraproject.org/download/ol-schema-migrate.pl

root# chmod u+x /root/ol-schema-migrate.pl

root# /root/ol-schema-migrate.pl -b /root/dnszone-schema.txt > /etc/dirsrv/slapd-localdomain/schema/60dnsZone.ldif

root# service dirsrv start localdomain

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 :

# /root/389ds/389ds-bind_base.ldif

dn: ou=dns,dc=localdomain

objectClass: top

objectClass: organizationalUnit

ou: dns

description: All informations about DNS

aci: (target="ldap:///ou=dns,dc=localdomain")(version 3.0; acl "DNS Administrator"; deny(all) userdn!="ldap:///cn=dnsadmin,ou=Special Users,dc=localdomain";)

dn: cn=dnsadmin,ou=Special Users,dc=localdomain

objectClass: top

objectClass: person

cn: dnsadmin

sn: DNS Administrator

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

root# /usr/lib/mozldap/ldapmodify -a -h ldap.localdomain \

    -D "cn=Directory Manager" -w - \

    -f /root/389ds/389ds-bind_base.ldif

root# /usr/lib/mozldap/ldappasswd -Z -h localdomain -p 636 \

    -P /etc/dirsrv/slapd-localdomain/cert8.db

    -D "cn=Directory Manager" -w - \

    -s "dnsPassword" "cn=dnsadmin,ou=Special Users,dc=localdomain"

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) :

options {

    listen-on port 53 { 127.0.0.1; 10.0.2.102; };

    listen-on-v6 port 53 { none; };

    directory       "/var/named";

    dump-file       "/var/named/data/cache_dump.db";

    statistics-file "/var/named/data/named_stats.txt";

    memstatistics-file "/var/named/data/named_mem_stats.txt";

    allow-query     { localhost; 10.0.2.0/24; };

    recursion yes;

};

logging {

    channel default_debug {

        file "data/named.run";

        severity dynamic;

    };

};

zone "." IN {

    type hint;

    file "named.ca";

};

// Zone pour le domaine localdomain

zone "localdomain" {

    type master;

    database "ldap ldap://10.0.2.101/ou=localdomain,ou=dns,dc=localdomain????!bindname=cn=dnsadmin%2cou=Special%20Users%2cdc=localdomain,!x-bindpw=dnsPassword,x-tls 172800";

};

// Zone reverse pour 10.0.2.0/24

zone "2.0.10.in-addr.arpa" {

    type master;

    database "ldap ldap://10.0.2.101/ou=2.0.10.in-addr.arpa,ou=dns,dc=localdomain????!bindname=cn=dnsadmin%2cou=Special%20Users%2cdc=localdomain,!x-bindpw=dnsPassword,x-tls 172800";

};

include "/etc/named.rfc1912.zones";

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.

# /root/389ds/389ds-bind_structure.ldif

dn: ou=localdomain,ou=dns,dc=localdomain

objectClass: top

objectClass: organizationalUnit

ou: localdomain

description: All informations about localdomain zone

dn: zoneName=localdomain,ou=localdomain,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: localdomain

relativeDomainName: localdomain

dn: relativeDomainName=@,ou=localdomain,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: localdomain

relativeDomainName: @

dNSTTL: 3600

dNSClass: IN

sOARecord: ns.localdomain. dnsadmin.localdomain. 2006112801 8H 2H 1W 1D

nSRecord: ns.localdomain.

mXRecord: 10 smtp.localdomain.

aRecord: 10.0.2.102

tXTRecord: Zone_Principale_localdomain

dn: ou=2.0.10.in-addr.arpa,ou=dns,dc=localdomain

objectClass: top

objectClass: organizationalUnit

ou: 2.0.10.in-addr.arpa

description: All informations about 2.0.10.in-addr.arpa zone

dn: zoneName=2.0.10.in-addr.arpa,ou=2.0.10.in-addr.arpa,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: 2.0.10.in-addr.arpa

relativeDomainName: 2.0.10.in-addr.arpa

dn: relativeDomainName=@,ou=2.0.10.in-addr.arpa,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: 2.0.10.in-addr.arpa

relativeDomainName: @

dNSTTL: 3600

dNSClass: IN

sOARecord: ns.localdomain. dnsadmin.localdomain. 2006112801 8H 2H 1W 1D

nSRecord: ns.localdomain.

mXRecord: 10 smtp.localdomain.

tXTRecord: Zone_Principale_2.0.10.in-addr.arpa

L'injection se fait toujours via ldapmodify :

root# /usr/lib/mozldap/ldapmodify -a -h ldap.localdomain \

 -D "cn=Directory Manager" -w - \

 -f /root/389ds/389ds-bind_structure.ldif

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

# /root/389ds/389ds-bind_data.ldif

dn: relativeDomainName=ldap,ou=localdomain,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: localdomain

relativeDomainName: ldap

dNSTTL: 1800

dNSClass: IN

aRecord: 10.0.2.101

tXTRecord: Serveur_Ldap

dn: relativeDomainName=ns,ou=localdomain,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: localdomain

relativeDomainName: ns

dNSTTL: 1800

dNSClass: IN

aRecord: 10.0.2.102

tXTRecord: Serveur_Dns

dn: relativeDomainName=smtp,ou=localdomain,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: localdomain

relativeDomainName: smtp

dNSTTL: 1800

dNSClass: IN

aRecord: 10.0.2.103

tXTRecord: Serveur_Smtp

dn: relativeDomainName=103,ou=2.0.10.in-addr.arpa,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: 2.0.10.in-addr.arpa

relativeDomainName: 103

pTRRecord: smtp.localdomain.

tXTRecord: Serveur_Smtp

dn: relativeDomainName=102,ou=2.0.10.in-addr.arpa,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: 2.0.10.in-addr.arpa

relativeDomainName: 102

pTRRecord: ns.localdomain.

tXTRecord: Serveur_Dns

dn: relativeDomainName=101,ou=2.0.10.in-addr.arpa,ou=dns,dc=localdomain

objectClass: top

objectClass: dNSZone

zoneName: 2.0.10.in-addr.arpa

relativeDomainName: 101

pTRRecord: ldap.localdomain.

tXTRecord: Serveur_Ldap

ldapmodify toujours à l'œuvre :

root# /usr/lib/mozldap/ldapmodify -a -h ldap.localdomain \

 -D "cn=Directory Manager" -w - \

 -f /root/389ds/389ds-bind_data.ldif

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 :

root# sed -i "/^# chkconfig: /s/: .*/: - 21 79/" /etc/init.d/named

root# service named start ; chkconfig named on

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 :

# Bind9 DNS Server

-A INPUT -d 10.0.2.102 -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT

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 :

root# cat > /etc/resolv.conf << EOF

search localdomain

nameserver 10.0.2.102

EOF

root# nslookup smtp.localdomain

Server:         10.0.2.102

Address:        10.0.2.102#53

Name:   smtp.localdomain

Address: 10.0.2.103

root# nslookup 10.0.2.103

Server:         10.0.2.102

Address:        10.0.2.102#53

103.2.0.10.in-addr.arpa name = smtp.localdomain.

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/