MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Réutiliser l’IP d’un contrôleur de domaine : bonnes pratiques, checklists et scripts (Active Directory, Windows Server)

Réutiliser l’IP d’un contrôleur de domaine : bonnes pratiques, checklists et scripts (Active Directory, Windows Server)

Windows Server

Votre DC est tombé en panne et vous en promouvez un nouveau ? Faut‑il réutiliser l’ancienne adresse IP ou repartir sur une neuve ? Voici un guide opérationnel, orienté production, pour basculer sans interruption, avec checklists, commandes PowerShell et pièges à éviter.

Sommaire

Réutiliser ou non l’ancienne adresse IP d’un contrôleur de domaine ?

Vue d’ensemble de la question

Un contrôleur de domaine (DC) Active Directory concentre des rôles critiques : authentification Kerberos/NTLM, réplication AD, publication DNS, catalogue global, service d’heure, etc. Lorsqu’un DC tombe en panne, la tentation est forte d’attribuer au remplaçant l’ancienne adresse IP pour épargner les modifications (pare‑feu, scripts, équipements réseau qui pointent vers les DNS du DC). C’est souvent la voie la plus simple… à condition de préparer proprement la transition. L’enjeu : éviter les conflits d’adresses, les enregistrements DNS périmés, la « rémanence » d’objets AD et tout ce qui pourrait perturber l’authentification et la résolution de noms.

Réponse & solutions

ÉtapeAction recommandéePourquoi ?
1. Vérifier l’unicité de l’adresseBalayez le réseau (Nmap, Angry IP Scanner) ou consultez DHCP/DNS pour confirmer que l’IP n’est utilisée par aucun autre hôte.Évite conflits et perturbations dès la mise en ligne.
2. Nettoyer les métadonnées de l’ancien DCExécutez ntdsutil metadata cleanup ou utilisez Active Directory Sites and Services pour supprimer les traces du DC défaillant (objets NTDS Settings, enregistrements DNS SRV, etc.).Empêche des répliques fantômes ou des erreurs de réplication.
3. Mettre à jour ou purger les enregistrements DNSSupprimez les enregistrements A, AAAA et SRV associés à l’ancien DC, puis forcez leur recréation (ou laissez la mise à jour dynamique les recréer).Garantit que clients et services peuvent résoudre la nouvelle adresse sans délai.
4. Synchroniser le cache des clientsDéployez un script ipconfig /flushdns ou laissez le cache expirer naturellement ; réduisez temporairement le TTL des enregistrements AD‑intégrés si besoin.Limite les erreurs de connexion dues à des caches obsolètes.
5. Tester la connectivité & la réplicationAvant la mise en production, isolez le nouveau DC dans un VLAN de test, vérifiez dcdiag, repadmin /replsummary et la publication des enregistrements SRV.Valide l’état de santé et la visibilité réseau du nouveau DC.
6. Planifier un créneau de basculeInformez les équipes (services, scripts, applications sensibles à l’IP) et prévoyez un créneau hors‑pointe si possible.Réduit l’impact sur la production.

Prérequis et garde‑fous incontournables

  • Inventaire : listez tous les usages de l’IP du DC (résolveurs DNS sur serveurs, pare‑feu, proxies, appliances, scripts, sauvegardes, supervision, VPN, WAF, reverse proxy, solutions NAC, etc.).
  • État d’AD : au moins un autre DC sain dans chaque domaine/site pour assurer la continuité pendant la bascule. Mesurez une ligne de base (dcdiag /v, repadmin /replsummary).
  • Stratégie FSMO : identifiez le détenteur des rôles (netdom query fsmo). S’ils étaient sur le DC défaillant, préparez un seize sécurisé.
  • Backups : sauvegardes système et état du système récentes d’au moins un autre DC (évitez toute restauration non autorisée d’un DC : USN rollback !).
  • Plan DNS : TTL réduit (ex. 300 s) sur les enregistrements critiques le temps de la bascule ; nettoyage A/AAAA/SRV/PTR et scavenging configuré.
  • Sites & sous‑réseaux AD : vérifiez la cartographie des subnets. Si vous changez d’IP, le nouveau subnet doit pointer vers le bon site.
  • Sécurité : durcissement à jour (SMBv1 désactivé, NTLM restreint si possible, LAPS/gMSA), conformité journaux et rétention.
  • Virtualisation : proscrire les retours arrière de snapshots sur des DC en production. Utilisez des sauvegardes compatibles AD et la fonctionnalité VM‑GenerationID.

Comparatif rapide

CritèreRéutiliser l’IPNouvelle IP
Effort de mise à jourFaible (peu ou pas de changements côté clients/équipements)Élevé (DNS des clients, pare‑feu, scripts, sondes, appliances)
Risque de conflitConflit possible si l’ancien hôte remonte ou si ARP/DNS est obsolèteFaible si planifié (mais risque d’oubli de références)
Traçabilité / auditHistorique IP moins clairMeilleure séparation des périodes
Time‑to‑restoreRapidePlus long
Impact sites ADInchangéImpacts si l’IP bascule de subnet/site

Runbook détaillé — réutiliser l’ancienne IP (scénario conseillé)

  1. Démotion propre si possible : si l’ancien DC est encore joignable, exécutez une dcpromo inverse (ou Uninstall-ADDSDomainController) pour le retirer proprement. Sinon, passez au nettoyage de métadonnées.
  2. Nettoyage de métadonnées (DC irrécupérable) : ntdsutil metadata cleanup connections connect to server <DC_sain> quit select operation target list domains select domain <NomDomaine> list sites select site <NomSite> list servers in site select server <AncienDC> quit remove selected server quit Supprimez aussi le compte d’ordinateur du DC dans « Ordinateurs » (ou Domain Controllers) et l’objet NTDS Settings dans Sites and Services.
  3. DNS : purge des enregistrements liés à l’ancien DC : A/AAAA, PTR et SRV (_ldap._tcp, _kerberos._tcp, _gc._tcp, _kpasswd._tcp) dans les zones AD‑intégrées (_msdcs, zone du domaine, zones reverse). Exemple PowerShell : # Exemple: suppression des enregistrements A dans la zone de domaine Get-DnsServerResourceRecord -ZoneName "exemple.local" -Name "AncienDC" | Remove-DnsServerResourceRecord -ZoneName "exemple.local" -Force
  4. Vérifier l’unicité de l’IP :
    • Depuis un poste d’admin dans le même VLAN : arp -a | find "<IP>" (doit être absent avant attribution).
    • Ping ciblé : Test-NetConnection <IP> -Port 389, -Port 445, -Port 53 (doit échouer avant bascule).
    • Contrôlez DHCP : aucun bail actif sur cette IP.
  5. Promouvoir le nouveau serveur en DC (avec une IP temporaire si nécessaire) : Install-WindowsFeature AD-Domain-Services, DNS -IncludeManagementTools Install-ADDSDomainController -DomainName "exemple.local" -InstallDNS -NoGlobalCatalog:$false Attendez une réplication complète et vérifiez la santé (dcdiag, repadmin /showrepl).
  6. Arrêt du nouveau DC et configuration de l’IP : attribuez l’ancienne IP à la carte réseau (masque, passerelle, DNS). Redémarrez.
  7. Gratuitous ARP / caches : au redémarrage, Windows envoie des ARP gratuits. Accélérez la convergence en redémarrant la NIC ou en vidant les caches ARP sur équipements critiques (routeurs, pare‑feu) si possible.
  8. Forcer l’enregistrement DNS : ipconfig /registerdns nltest /dsregdns
  9. Validation poussée : dcdiag /e /v dcdiag /test:DNS /DnsBasic repadmin /replsummary repadmin /showrepl * /csv > repl.csv nltest /dsgetdc:exemple.local netdom query fsmo w32tm /query /status Contrôlez que les enregistrements SRV pointent vers le nouveau DC à la bonne IP, que le GC est publié si requis et qu’aucune erreur Kerberos (KRB_AP_ERR_MODIFIED) n’apparaît.
  10. Rôle PDC et service d’heure (si bascule FSMO) : # Exemple de saisie des FSMO si l'ancien DC est perdu Move-ADDirectoryServerOperationMasterRole -Identity NouveauDC ` -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force # NTP sur le PDC w32tm /config /manualpeerlist:"time.example.net,0x8" /syncfromflags:manual /update w32tm /resync
  11. Post‑bascule (GPO / clients) : poussez ipconfig /flushdns via script de démarrage/connexion ou attendez l’expiration des TTL. Vérifiez les services dépendants (IIS, SQL, appliances) qui référencent l’IP du DNS/DC.

Runbook — attribuer une nouvelle IP (alternative)

  1. Effectuez les mêmes étapes de nettoyage que ci‑dessus (métadonnées, DNS).
  2. Attribuez une IP différente et mettez à jour :
    • Résolveurs DNS des serveurs/clients (GPO, DHCP option 006).
    • Règles de pare‑feu et listes d’accès (ACL) réseau.
    • Supervision, sauvegardes, proxies, SSO, intégrations SIEM.
  3. Contrôlez la cartographie Sites & Services (subnet → site) si le nouveau sous‑réseau diffère.
  4. Validez comme dans le scénario précédent (dcdiag, repadmin, nltest).

DNS : opérations précises et scripts utiles

Un basculement propre dépend à 80 % d’un DNS net. Concentrez‑vous sur :

  • Zone du domaine : enregistrements A/AAAA du DC (NomDC.domaine), alias éventuels.
  • Zone _msdcs : SRV et enregistrements par GUID.
  • Zones reverse : PTR correspondant à l’IP réutilisée.
  • SRV critiques : _ldap._tcp.dc._msdcs, _kerberos._tcp, _kpasswd._tcp, _gc._tcp (si GC).
Type d’enregistrementOùAction
A / AAAAZone du domaineSupprimer si pointe vers l’ancienne IP, recréer vers la nouvelle (ou laisser Netlogon les recréer).
SRV_msdcs & zone du domainePurger ceux de l’ancien DC, forcer la republication (nltest /dsregdns).
PTRZone reverseMettre à jour pour refléter la nouvelle cartographie IP → nom.
TTLToutes zones AD‑intégréesRéduire temporairement (ex. 300 s) en amont, remettre à la valeur nominale après stabilisation.

Exemple PowerShell : liste des SRV pour contrôle rapide :

Get-DnsServerResourceRecord -ZoneName "_msdcs.exemple.local" |
  Where-Object {$_.RecordType -eq "SRV"} |
  Select-Object HostName, @{n="Cible";e={$_.RecordData.DomainName}}, @{n="Port";e={$_.RecordData.Port}}

FSMO, catalogue global et services connexes

  • FSMO : si l’ancien DC détenait des rôles, effectuez un seize (voir plus haut) uniquement s’il ne reviendra jamais en ligne. Après saisie, ne rallumez pas l’ancien DC sans l’isoler.
  • GC : si le DC remplaçant doit être GC, cochez l’option durant l’installation ou via Sites and Services. Vérifiez _gc._tcp côté DNS.
  • W32Time : le PDC du domaine doit se synchroniser sur une source fiable. Les membres se synchroniseront ensuite sur le domaine.
  • Certificats/AD CS : si l’ancien DC hébergeait aussi une AC, adaptez CRL/CDP/AIA (chemins HTTP/LDAP), ce qui milite souvent pour réutiliser l’IP afin d’éviter la mise à jour des points de distribution.

Sécurité et conformité : profiter de la recréation

  • Désactivez SMBv1 : Set-SmbServerConfiguration -EnableSMB1Protocol $false -Force.
  • Durcissez NTLM (si votre parc le permet), forcez LDAP Signing/Channel Binding.
  • Activez LAPS et utilisez des gMSA pour les services.
  • Réinitialisez le mot de passe DSRM et documentez‑le dans un coffre.
  • Journalisez et conservez les Event Logs Directory Service, DNS Server, System pendant la fenêtre de bascule.

Vérifications post‑bascule (Go/No‑Go)

  • DNS : dcdiag /test:DNS sans erreur, nslookup -type=SRV _ldap._tcp.dc._msdcs.exemple.local renvoie uniquement le nouveau DC.
  • Réplication : repadmin /replsummary taux d’échec à 0 %; la latence reste sous votre SLO.
  • Authentification : connexions utilisateurs et GPO appliquées (contrôler gpresult /r sur un client).
  • Service d’heure : dérive < 2 s entre DC (selon vos seuils).
  • Applications : tests de bout en bout (IIS/SharePoint/SQL/ERP) et supervision au vert.

Scénarios particuliers et conseils supplémentaires

Réutilisation de l’ancienne IP

  • Idéale si de nombreux scripts, règles de pare‑feu ou services externes référencent l’IP fixe.
  • Sûre uniquement si aucune autre machine ne répond sur cette adresse et si les métadonnées obsolètes ont été purgées.
  • Pensez aux caches ARP sur certains équipements qui persistent plus longtemps : un redémarrage d’interface peut accélérer la convergence.

Attribution d’une nouvelle IP

  • Préférable si vous devez conserver une trace légale de l’ancienne IP ou isoler les causes de panne.
  • Oblige à mettre à jour manuellement toutes les références (scripts, pare‑feu, monitoring, appliances).
  • Vérifiez la cartographie site/subnet dans AD pour éviter une localisation de site erronée.

DHCP vs IP statique

  • Les DC sont traditionnellement en IP statique pour la stabilité.
  • Un bail DHCP réservé peut fonctionner, mais ajoute une dépendance au serveur DHCP et complique les bascules non planifiées.

Surveillance post‑bascule

  • Surveillez les journaux Directory Service, DNS Server et System pour détecter d’éventuelles erreurs « KRBTGT », « KDC », enregistrements SRV manquants ou duplications d’SPN (setspn -X).
  • Vérifiez que les rôles FSMO ont été correctement transférés ou saisis si l’ancien DC les détenait.

Pièges fréquents (et comment les éviter)

  • Objets fantômes : un serveur supprimé uniquement de « Computers » mais pas de Sites and Services reste présent dans la topologie de réplication. Toujours faire un metadata cleanup.
  • SRV résiduels : un _ldap._tcp pointant sur une IP morte fait échouer des jointures de domaine et la découverte de DC. Purgez puis nltest /dsregdns.
  • ARP obsolète : en cas de réutilisation de l’IP, un équipement L3 peut continuer à envoyer au MAC de l’ancien DC. Basculez/renouvelez l’interface, ou purgez l’entrée ARP sur l’équipement.
  • Snapshots de VM : restaurer un DC via snapshot non autorisé entraîne des risques d’USN rollback. Toujours utiliser des sauvegardes AD‑aware.
  • Confusion PDC/NTP : après saisie FSMO, reconfigurez W32Time sur le nouveau PDC immédiatement.

FAQ rapide

« Kerberos dépend‑il de l’IP ? » Pas directement : Kerberos s’appuie sur les SPN associés aux noms (FQDN/NetBIOS). C’est le DNS qui doit être fiable. Une IP réutilisée est transparente si les enregistrements A/SRV sont corrects.

« Faut‑il forcer un flush DNS sur tout le parc ? » Utile, mais pas toujours indispensable si vous avez réduit le TTL en amont. Privilégiez un flush sur les serveurs critiques et laissez le reste expirer naturellement.

« Puis‑je renommer le nouveau DC avec l’ancien nom ? » Oui, c’est courant et recommandé pour limiter l’impact, à condition d’avoir correctement supprimé l’ancien objet d’ordinateur et ses traces dans AD/DNS.

« Et les RODC ? » Même logique : nettoyez l’objet RODC, les secrets stockés localement, puis republiez les SRV. Testez la remontée de mots de passe si la topologie l’exige.

Checklist opérationnelle imprimable

PhaseContrôlesOK
AvantInventaire des dépendances IP, TTL DNS réduit, backup OK, autre DC sain, rôles FSMO identifiés 
Nettoyagentdsutil exécuté, objets NTDS supprimés, SRV/A/PTR purgés 
PromotionInstallation ADDS/DNS, GC si requis, dcdiag sans erreur 
Bascule IPAncienne IP libre, ARP convergé, ipconfig /registerdns exécuté 
Validationrepadmin /replsummary OK, nltest /dsgetdc OK, événements propres 
AprèsTTL remis nominal, supervision ajustée, documentation ITSM mise à jour 

Conclusion

Réutiliser l’ancienne adresse IP d’un contrôleur de domaine est une stratégie fiable et pragmatique à condition d’en garantir l’unicité, de nettoyer rigoureusement les métadonnées de l’ancien DC et de remettre à plat les enregistrements DNS avant la mise en production. Dans les environnements fortement scriptés ou segmentés, cette approche minimise l’onde de choc. À l’inverse, si vos contraintes d’audit, d’investigation ou de sécurité imposent la conservation d’un historique IP strict, attribuez une nouvelle adresse, adaptez la cartographie des sites et documentez précisément chaque changement dans vos procédures ITSM.

Astuce finale : pour éliminer la dépendance à une IP à l’avenir, privilégiez des noms (CNAME « ldap », « gc », « kdc ») ou des mécanismes de découverte standard (SRV) dans vos scripts et vos équipements. Ainsi, la prochaine bascule sera encore plus simple.

Windows Server
Active Directory PowerShell DNS Windows Server Contrôleur de domaine Réplication AD
Sommaire