Active Directory, DNS et DHCP redondants

Rendre l'annuaire, le DNS et le DHCP redondants, c'est installer au moins deux serveurs pour chacun de ces services et faire en sorte que les clients utilisent automatiquement le second quand le premier ne répond plus. Ces trois services sont les dépendances de presque tout le reste : sans DNS, plus aucun nom ne se résout ; sans annuaire, plus personne ne s'authentifie ; sans DHCP, les nouveaux postes n'obtiennent plus d'adresse. Ce chapitre montre comment doubler les contrôleurs de domaine Active Directory, le DNS sous Windows et sous Linux, et le DHCP avec le basculement de Windows Server.

Trois services, trois façons de tomber

Les pannes de ces services ne se voient pas toutes au même moment, ce qui piège les débutants :

Une panne de DHCP peut donc passer inaperçue pendant des heures, jusqu'à ce qu'un visiteur ou un poste neuf ne puisse pas se connecter. C'est une raison de plus pour superviser chaque service, pas seulement les serveurs.

Deux contrôleurs de domaine

Active Directory est multi-maître : chaque contrôleur de domaine (DC) détient une copie modifiable de l'annuaire, et les modifications faites sur l'un sont répliquées vers les autres. Dans un même site, la réplication se déclenche par notification quelques secondes après une modification ; entre deux sites, elle suit la planification du lien de site (toutes les 180 minutes par défaut, réglable). Les postes trouvent les contrôleurs grâce à des enregistrements DNS de type SRV (par exemple _ldap._tcp.dc._msdcs.ravelle.lan) et choisissent un DC de leur site : si l'un ne répond plus, ils en utilisent un autre, sans configuration particulière.

Ajouter le second contrôleur. Sur SRV-AD2, un Windows Server membre du domaine :

Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
Install-ADDSDomainController -DomainName "ravelle.lan" -InstallDns `
    -SiteName "Siege" -Credential (Get-Credential "RAVELLE\admin-lina")

La commande demande le mot de passe du mode de restauration des services d'annuaire, installe le DNS, fait de SRV-AD2 un catalogue global (c'est le comportement par défaut), réplique l'annuaire depuis SRV-AD1, puis redémarre le serveur. Le cours Windows Server détaille l'installation du premier contrôleur.

Vérifier la réplication.

repadmin /replsummary                 # synthèse : aucun échec, des deltas de quelques minutes
repadmin /showrepl                    # détail par partenaire et par partition
dcdiag /test:replications             # « a réussi le test Replications »
Get-ADDomainController -Filter * | Select-Object Name, IPv4Address, IsGlobalCatalog

Les rôles FSMO. Cinq opérations d'Active Directory ne peuvent pas être multi-maîtres : elles sont confiées à un seul contrôleur, le détenteur du rôle.

netdom query fsmo dit qui détient quoi. Avant une maintenance de SRV-AD1, on transfère ses rôles proprement ; si SRV-AD1 est définitivement perdu, on les saisit sur SRV-AD2 :

# Transfert planifié (SRV-AD1 est en service)
Move-ADDirectoryServerOperationMasterRole -Identity "SRV-AD2" -OperationMasterRole PDCEmulator, RIDMaster
# Saisie, si SRV-AD1 ne reviendra jamais
Move-ADDirectoryServerOperationMasterRole -Identity "SRV-AD2" -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster, SchemaMaster, DomainNamingMaster -Force

L'heure, une dépendance cachée. L'authentification Kerberos échoue quand l'horloge d'un poste s'écarte de plus de cinq minutes de celle du contrôleur. Dans un domaine, les postes et les serveurs se synchronisent sur la hiérarchie des DC, et l'émulateur PDC du domaine racine se synchronise sur une source NTP externe fiable. Si les rôles changent de serveur, cette configuration doit suivre. w32tm /query /status affiche la source de temps d'une machine.

Pour une agence sans personnel informatique, un contrôleur de domaine en lecture seule (RODC) garde une copie locale de l'annuaire, non modifiable : les ouvertures de session continuent si le VPN tombe, sans exposer un DC complet dans un local peu protégé.

Un DNS qui survit à la panne d'un serveur

Côté serveurs Windows. Les zones intégrées à Active Directory sont stockées dans l'annuaire et répliquées avec lui. Chaque contrôleur de domaine qui porte le rôle DNS est serveur principal de la zone : on peut modifier un enregistrement sur n'importe lequel, et la modification arrive sur l'autre par la réplication de l'annuaire. Rien d'autre à configurer pour avoir deux serveurs DNS identiques.

Côté clients, c'est là que tout se joue : un poste qui ne connaît qu'un serveur DNS n'utilisera jamais le second.

• Les postes reçoivent les deux adresses par l'option DHCP 006 (serveurs DNS) : 10.10.20.10 et 10.10.20.11. Un poste interroge d'abord le premier, puis le second si le premier ne répond pas dans le délai (environ une seconde sous Windows).
• Chaque contrôleur utilise l'autre comme serveur DNS préféré, et sa propre adresse de bouclage (127.0.0.1) comme serveur auxiliaire : c'est la recommandation de Microsoft, qui évite qu'un DC redémarré attende indéfiniment son propre service DNS.
• Les serveurs Linux listent les deux serveurs dans leur configuration de résolution. Dans /etc/resolv.conf, une ligne options timeout:1 attempts:2 réduit le délai avant de passer au second.

Côté serveurs Linux (BIND). Sans Active Directory, on monte un serveur principal, où l'on modifie la zone, et un ou plusieurs serveurs secondaires, qui en reçoivent une copie par transfert de zone. Le principal prévient les secondaires à chaque modification (message NOTIFY), et les secondaires vérifient le numéro de série de la zone pour savoir s'ils doivent la recharger. Sur le secondaire, dans /etc/bind/named.conf.local :

zone "ravelle.lan" {
    type secondary;
    primaries { 10.10.20.10; };
    file "/var/cache/bind/db.ravelle.lan";
};

Et sur le principal, la zone n'autorise le transfert qu'aux secondaires (allow-transfer { 10.10.20.11; };) : un transfert de zone ouvert à tous livrerait la liste complète des machines de l'organisation. N'oublie pas d'incrémenter le numéro de série du SOA à chaque modification : sinon, les secondaires gardent l'ancienne version. Le cours services réseau détaille la configuration de BIND.

Le basculement DHCP sous Windows Server

Le basculement DHCP (DHCP failover) associe deux serveurs DHCP Windows qui partagent, pour une ou plusieurs étendues, la même base de baux : chacun sait quelles adresses l'autre a distribuées. Si l'un tombe, l'autre continue de distribuer et de renouveler les baux de toute l'étendue. Deux modes existent :

Les paramètres à connaître :

• le MCLT (Maximum Client Lead Time, 1 heure par défaut) : la durée maximale dont un serveur peut prolonger un bail au-delà de ce que son partenaire connaît. Il fixe aussi le délai avant qu'un serveur s'approprie toute l'étendue quand son partenaire est déclaré hors service ;
• le passage automatique à l'état « partenaire hors service » (state switchover interval) : sans lui, un serveur qui ne joint plus son partenaire reste dans l'état « communication interrompue », où il ne peut distribuer que sa part d'adresses libres. Avec lui, il considère le partenaire comme hors service au bout du délai choisi, puis, après le MCLT, distribue toute l'étendue ;
• le secret partagé, qui authentifie les messages entre les deux serveurs (sur le port TCP 647).

La configuration sur SRV-AD1, pour l'étendue du VLAN 10 :

Add-DhcpServerv4Failover -ComputerName "SRV-AD1" -Name "AD1-AD2" -PartnerServer "SRV-AD2" `
    -ScopeId 10.10.10.0 -LoadBalancePercent 50 -MaxClientLeadTime 01:00:00 `
    -AutoStateTransition $true -StateSwitchInterval 00:45:00 `
    -SharedSecret "Un-Secret-Partage-Long"

Get-DhcpServerv4Failover -ComputerName "SRV-AD1"

La commande crée l'étendue sur SRV-AD2 et y recopie sa configuration. Pour un mode serveur de secours, on remplace -LoadBalancePercent 50 par -ServerRole Active -ReservePercent 5.

Le relais DHCP doit connaître les deux serveurs. Les postes du VLAN 10 ne sont pas dans le même réseau que les serveurs : c'est le relais DHCP du pare-feu (ou la commande ip helper-address d'un routeur Cisco) qui transmet leurs demandes. Il doit les envoyer aux deux serveurs. Un relais configuré vers SRV-AD1 seulement rend le basculement inutile : quand SRV-AD1 tombe, plus aucune demande n'arrive à SRV-AD2.

Avant le basculement : l'étendue fractionnée. Avant Windows Server 2012, on répartissait une étendue entre deux serveurs qui ne se parlaient pas, selon la règle des 80/20 : le premier distribue 80 % des adresses, le second les 20 % restants, sans chevauchement. Pour la plage .50 à .200 (151 adresses), cela donne .50 à .170 (121 adresses) sur le premier serveur et .171 à .200 (30 adresses) sur le second. La méthode marche encore avec deux serveurs DHCP Linux indépendants, mais le second ne peut pas renouveler les baux du premier, et sa petite plage peut s'épuiser pendant une longue panne.

Le DHCP redondant sous Linux

Le serveur ISC DHCP, longtemps standard sous Linux, n'est plus maintenu par son éditeur depuis la fin de 2022, et Debian 13 le marque comme obsolète. Son successeur, Kea (version 2.6 dans Debian 13), gère la haute disponibilité par deux bibliothèques d'extension (hooks) : libdhcp_lease_cmds.so, qui permet de manipuler les baux à distance, et libdhcp_ha.so, qui fait dialoguer les deux serveurs. Kea propose trois modes : équilibrage de charge, serveur de secours (hot-standby), et sauvegarde passive (un serveur actif qui envoie simplement ses baux à un ou plusieurs serveurs de secours). Les deux serveurs se surveillent mutuellement, et le survivant reprend toute l'étendue, comme sous Windows. À défaut, l'étendue fractionnée reste une solution simple.

Tester la redondance de ces services

Un test convaincant arrête le service, puis prouve que les clients continuent de travailler. Avec SRV-AD1 arrêté (ou ses services NTDS, DNS et DHCPServer stoppés) :

Exercices