389 Directory Server as ISC DHCP backend

Magazine
Marque
GNU/Linux Magazine
Numéro
123
Mois de parution
janvier 2010


Résumé

Dans mon précédent article, nous avions vu comment utiliser le serveur d'annuaire 389 Directory Server (389DS) pour stocker les données d'un serveur DNS. Nous gérons aussi nos comptes utilisateurs dans cet annuaire LDAP. Nous disposons donc d'une infrastructure dont une part non négligeable des données administratives sont stockées dans un annuaire. Et nous pouvons aller au-delà : stockons nos données DHCP dans un annuaire. Cet article se propose donc de vous montrer la marche à suivre pour le faire avec 389DS, dans la foulée du serveur DNS.


Body

Dans un article sur Cobbler [1], j'avais abordé le fait que nous construisions une CMDB (Configuration Management DataBase) en stockant les informations des machines dans Cobbler. Il est tout à fait envisageable d'imaginer que Cobbler « sérialise » ses données dans un annuaire (l'API permet d'ailleurs d'écrire un « sérialiseur »). Dès lors, Cobbler n'aurait plus besoin d'utiliser son mécanisme de templates pour gérer les services DHCP et DNS. Au passage, la sauvegarde des données de l'annuaire sauvegarderait aussi les données des services DNS, DHCP et Cobbler (pour partie), simplifiant la politique de sauvegarde. Nous retrouverions d'ailleurs un comportement assez proche... d'Active Directory, les outils de manipulation en moins.

Mais trêve de divagations... Je pars du principe que vous savez configurer le service DHCP via ses fichiers de configuration habituels. Nous partirons donc d'un exemple de configuration classique que nous migrerons dans l'annuaire LDAP.

Pour cet article, je ne repasserai pas sur la configuration de 389DS puisque nous l'avons réalisée dans l'article précédent sur le DNS. Je rappelle juste quelques points utiles. Le serveur d'annuaire écoute à l'adresse 10.0.2.101 et son suffixe LDAP est dc=localdomain. Ceux qui viennent de lire l'article précédent auront une impression de déjà vu : c'est normal, c'est du copier/coller ; ne réinventons pas la roue ! ;)

1. Configuration de base de ISC DHCP

Dans un premier temps, nous installons le package dhcp (yum install dhcp), nous configurons le serveur DHCP de manière classique, via le fichier /etc/dhcp/dhcpd.conf ci-dessous.

authoritative;

ddns-update-style none;

default-lease-time 259200;

max-lease-time 259200;

subnet 10.0.2.0 netmask 255.255.255.0 {

    option broadcast-address 10.0.2.255;

    option routers 10.0.2.2;

    option domain-name "localdomain";

    option domain-name-servers ns.localdomain;

    deny unknown-clients;

    

    host client01 {

        hardware ethernet 08:00:27:d5:08:08;

fixed-address 10.0.2.201;

    }

}

J'ai volontairement pris un exemple particulièrement simple :

- Un seul réseau 10.0.2.0/24 dont l'adresse de broadcast est 10.0.2.255, le routeur 10.0.2.2, le nom de domaine localdomain et le serveur DNS ns.localdomain. Les informations DNS correspondent au service que nous avons configuré dans le précédent article.

- Les clients non renseignés dans la configuration ne recevront pas de bail DHCP (deny unknown-clients).

- Un seul client dont l'adresse MAC est 08:00:27:d5:08:08 et auquel nous attribuons l'adresse IP 10.0.2.201.

Il suffit de démarrer et d'activer le service comme suit :

service dhcpd start

chkconfig dhcpd on

Voici la règle à ajouter dans /etc/sysconfig/iptables pour que le firewall accepte les requêtes :

# DHCP Server

-A INPUT -p udp --dport 67 -j ACCEPT

Pour valider le fonctionnement du serveur DHCP, il faut vérifier dans /var/log/messages que le client se voit bien offrir un bail et sur le client que la configuration réseau s'effectue bien.

2. Migration des données dans l'annuaire LDAP

Maintenant que notre service est fonctionnel, je vous propose d'entrer dans le vif du sujet.

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

Pour que l'annuaire puisse accueillir nos données, nous devons lui en fournir la description au travers d'un schéma spécifique. Nous commençons donc par télécharger et installer ce schéma.

root# service dirsrv stop localdomain

root# urlgrabber http://www.lunytune.net/old/dhcp.schema.gz

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

root# gunzip dhcp.schema.gz

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

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

root# service dirsrv start localdomain

Nous avons arrêté le service d’annuaire, puis téléchargé le schéma (dhcp.schema) et le script de conversion (ol-schema-migrate.pl), 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 DHCP.

Nous créons une arborescence spécifique pour stocker les données DHCP, directement sous la racine de l’annuaire, ainsi qu’un utilisateur spécifique au service DHCP. 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=dhcpadmin,ou=Special Users,dc=localdomain puisse consulter les données. Cet utilisateur sera utilisé par dhcpd pour obtenir les données DHCP. Nous créons donc le fichier LDIF /root/389ds/389ds-dhcp_base.ldif comme suit :

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

dn: ou=dhcp,dc=localdomain

objectClass: top

objectClass: organizationalUnit

ou: dhcp

description: All informations about DHCP

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

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

objectClass: top

objectClass: person

cn: dhcpadmin

sn: DHCP Administrator

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

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

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

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

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

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

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

-s "dhcpPassword" "cn=dhcpadmin,ou=Special Users,dc=localdomain"

2.2 Déclaration du service

Le début du fichier /etc/dhcp/dhcpd.conf contient les options du service DHCP, précisant entre autres choses la durée des baux... Nous reprenons donc ces informations et les transformons en attributs d'un objet de classe dhcpService. Cet objet référence le serveur DHCP via l'attribut dhcpPrimaryDN, serveur qui est ensuite déclaré sous la forme d'un objet de classe dhcpServer référençant à son tour le service associé (je sais, c'est un peu redondant...). Notez cependant que le nom du serveur doit être celui renvoyé par hostname (ici lilith.localdomain), sans quoi le service ne démarrera pas.

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

dn: cn=localdomain,ou=dhcp,dc=localdomain

cn: localdomain

objectClass: top

objectClass: dhcpService

dhcpPrimaryDN: cn=lilith.localdomain,ou=dhcp,dc=localdomain

dhcpStatements: ddns-update-style none

dhcpStatements: default-lease-time 14400

dhcpStatements: max-lease-time 14400

dhcpStatements: authoritative

dn: cn=lilith.localdomain,ou=dhcp,dc=localdomain

cn: lilith.localdomain

objectClass: top

objectClass: dhcpServer

dhcpServiceDN: cn=localdomain,ou=dhcp,dc=localdomain

L'injection se fait toujours via ldapmodify :

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

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

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

2.3 Déclaration du réseau 10.0.2.0/24

Pour pouvoir déclarer des hôtes, nous devons les associer à un sous-réseau. Pour cela, nous créons une entrée de classe dhcpSubnet et qui reprend les attributs du sous-réseau que nous avons déclaré en début d'article :

- le masque de sous-réseau est 255.255.255.0 (attribut dhcpNetMask sous sa forme abrégée) ;

- l'adresse de broadcast (10.0.2.255), l'adresse IP du routeur par défaut (10.0.2.2), le nom de domaine (localdomain) et le serveur DNS (ns.localdomain) sous la forme d'attribut dhcpOption.

Cela donne le fichier LDIF /root/389ds/389ds-dhcp_10.0.2.0.ldif qui suit :

# /root/389ds/389ds-dhcp_10.0.2.0.ldif

dn: cn=10.0.2.0,cn=networks,cn=localdomain,ou=dhcp,dc=localdomain

cn: 10.0.2.0

objectClass: top

objectClass: dhcpSubnet

objectClass: dhcpOptions

dhcpNetMask: 24

dhcpOption: broadcast-address 10.0.2.255

dhcpOption: routers 10.0.2.2

dhcpOption: domain-name "localdomain"

dhcpOption: domain-name-servers ns.localdomain

L'injection se fait toujours via ldapmodify :

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

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

-f /root/389ds/389ds-dhcp_10.0.2.0.ldif

2.4 Déclaration du client

Nous voici maintenant à l'essentiel : la déclaration de l'hôte ! Nous créons là aussi un fichier LDIF qui déclare une entrée de classe dhcpHost, dont l'adresse MAC est 08:00:27:d5:08:08 (attribut dhcpHWAddress) et l'adresse IP 10.0.2.201 (attribut de type dhcpStatements).

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

dn: cn=client01,cn=networks,cn=localdomain,ou=dhcp,dc=localdomain

cn: client01

objectClass: top

objectClass: dhcpHost

dhcpHWAddress: ethernet 08:00:27:d5:08:08

dhcpStatements: fixed-address 10.0.2.201

Nous l'injectons avec l'inépuisable ldapmodify

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

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

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

Nous allons pouvoir passer à la configuration du service dhcpd.

3. Bascule du service DHCP sur le backend LDAP

Et comme d'habitude, la dernière étape est la plus simple. Nous devons indiquer au serveur DHCP où trouver sa configuration et ses données. Le fichier /etc/dhcp/dhcpd.conf devient donc :

ldap-server "ldap.localdomain";

ldap-port 389;

ldap-username "cn=dhcpadmin,ou=Special Users,dc=localdomain";

ldap-password "dhcpPassword";

ldap-base-dn "ou=dhcp,dc=localdomain";

ldap-method dynamic;

Le serveur LDAP écoute à l'adresse ldap.localdomain (ldap-server) sur le port 389 (ldap-port). Pour se connecter à l'annuaire, le serveur DHCP utilise le compte cn=dhcpadmin,ou=Special Users,dc=localdomain (ldap-username) avec le mot de passe défini précédemment (ldap-password). Les données sont stockées dans la branche ou=dhcp,dc=localdomain (ldap-base-dn). Ce qui est important ici est que nous utilisons la méthode dynamic qui lit les données dans l'annuaire à chaque requête, évitant ainsi de redémarrer le service DHCP pour prendre en compte les modifications ; la méthode static réduit la charge sur le serveur LDAP, mais réduit aussi l'intérêt d'utiliser un annuaire.

Le redémarrage du service (service dhcpd restart) permet d'utiliser les nouveaux paramètres. Et c'est le dernier redémarrage que vous aurez à faire, grâce à l'utilisation de la méthode dynamic.

Vous disposez donc maintenant d'une solution centralisée pour gérer l'Identité au sein de votre organisation. Vos utilisateurs sont authentifiés via PAM/LDAP, leurs certificats sont exportés dans l'annuaire si vous avez une PKI. Vos machines sont renseignées dans les services DNS et DHCP avec le backend LDAP, et elles sont déployées et configurées grâce à Cobbler et Puppet. Bien entendu, maintenir tout ceci à jour nécessite du travail, mais vous écrirez rapidement vos propres outils. Vous pouvez aussi regarder du côté de produits libres tels que FreeIPA [2] qui s'occupe de toutes ces fonctions de manière totalement intégrée.

Références

[1] GNU/Linux Magazine France, Juillet-Août 2009

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

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

 



Article rédigé par

Par le(s) même(s) auteur(s)

Virtualisation basée sur les LinuX Containers, aka LXC

Magazine
Marque
GNU/Linux Magazine
Numéro
159
Mois de parution
avril 2013
Spécialité(s)
Résumé
Cet article a pour objectif de vous présenter la technologie de virtualisation LXC [0.1]. Le terme de virtualisation n'est d'ailleurs pas vraiment adapté, car il n'y a pas de création de machine virtuelle en tant que telle. La page d'accueil du projet dit que LXC est parfois décrit comme « chroot gonflé aux stéroïdes », ce qui colle bien à l'esprit du projet. Au cours des prochaines pages, nous aborderons l'installation des outils LXC, la création d'un conteneur très simple à base de Busybox, puis un conteneur plus riche basé sur CentOS 6 et nous survolerons les aspects sécurité et intégration avec Libvirt.

Architecture DNS sécurisée

Magazine
Marque
GNU/Linux Magazine
Numéro
154
Mois de parution
novembre 2012
Spécialité(s)
Résumé
Pierre angulaire de l'infrastructure réseau, le service DNS est la cible de nombreuses attaques. Certains veulent le faire taire (déni de service), d'autres le faire mentir (empoisonnement de cache) ou s'appuyer sur lui pour attaquer d'autres serveurs DNS (récursivité mal configurée). Lorsque vous mettez en place ce service, vous avez à votre disposition plusieurs mécanismes qui limitent les risques face aux méchants pirates de l'Internet. Cet article vous guidera dans l'installation d'une architecture DNS multiniveau et implémentant DNSSEC.

Cluster basé sur Red Hat Cluster Suite

Magazine
Marque
GNU/Linux Magazine
Numéro
133
Mois de parution
décembre 2010
Résumé

Dans une production informatique, certains services sont particulièrement critiques. Pour assurer la disponibilité de ces services, nous avons à notre disposition les technologies de cluster. Cet article présente la mise en place d'un cluster à trois nœuds pour héberger les services critiques de notre infrastructure : nous passerons en revue la clusterisation aussi bien de LVM que des services.

Les derniers articles Premiums

Les derniers articles Premium

PostgreSQL au centre de votre SI avec PostgREST

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Dans un système d’information, il devient de plus en plus important d’avoir la possibilité d’échanger des données entre applications. Ce passage au stade de l’interopérabilité est généralement confié à des services web autorisant la mise en œuvre d’un couplage faible entre composants. C’est justement ce que permet de faire PostgREST pour les bases de données PostgreSQL.

La place de l’Intelligence Artificielle dans les entreprises

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

L’intelligence artificielle est en train de redéfinir le paysage professionnel. De l’automatisation des tâches répétitives à la cybersécurité, en passant par l’analyse des données, l’IA s’immisce dans tous les aspects de l’entreprise moderne. Toutefois, cette révolution technologique soulève des questions éthiques et sociétales, notamment sur l’avenir des emplois. Cet article se penche sur l’évolution de l’IA, ses applications variées, et les enjeux qu’elle engendre dans le monde du travail.

Petit guide d’outils open source pour le télétravail

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Ah le Covid ! Si en cette période de nombreux cas resurgissent, ce n’est rien comparé aux vagues que nous avons connues en 2020 et 2021. Ce fléau a contraint une large partie de la population à faire ce que tout le monde connaît sous le nom de télétravail. Nous avons dû changer nos habitudes et avons dû apprendre à utiliser de nombreux outils collaboratifs, de visioconférence, etc., dont tout le monde n’était pas habitué. Dans cet article, nous passons en revue quelques outils open source utiles pour le travail à la maison. En effet, pour les adeptes du costume en haut et du pyjama en bas, la communauté open source s’est démenée pour proposer des alternatives aux outils propriétaires et payants.

Sécurisez vos applications web : comment Symfony vous protège des menaces courantes

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Les frameworks tels que Symfony ont bouleversé le développement web en apportant une structure solide et des outils performants. Malgré ces qualités, nous pouvons découvrir d’innombrables vulnérabilités. Cet article met le doigt sur les failles de sécurité les plus fréquentes qui affectent même les environnements les plus robustes. De l’injection de requêtes à distance à l’exécution de scripts malveillants, découvrez comment ces failles peuvent mettre en péril vos applications et, surtout, comment vous en prémunir.

Les listes de lecture

9 article(s) - ajoutée le 01/07/2020
Vous désirez apprendre le langage Python, mais ne savez pas trop par où commencer ? Cette liste de lecture vous permettra de faire vos premiers pas en découvrant l'écosystème de Python et en écrivant de petits scripts.
11 article(s) - ajoutée le 01/07/2020
La base de tout programme effectuant une tâche un tant soit peu complexe est un algorithme, une méthode permettant de manipuler des données pour obtenir un résultat attendu. Dans cette liste, vous pourrez découvrir quelques spécimens d'algorithmes.
10 article(s) - ajoutée le 01/07/2020
À quoi bon se targuer de posséder des pétaoctets de données si l'on est incapable d'analyser ces dernières ? Cette liste vous aidera à "faire parler" vos données.
Voir les 65 listes de lecture

Abonnez-vous maintenant

et profitez de tous les contenus en illimité

Je découvre les offres

Déjà abonné ? Connectez-vous