Déployer un second contrôleur de domaine et gérer les rôles FSMO pas à pas

Un domaine Active Directory à contrôleur unique est une infrastructure fragile. Une panne disque, un échec de mise à jour, un crash mémoire et c’est toute l’entreprise qui perd l’authentification : aucun utilisateur ne peut ouvrir de session, aucune GPO ne s’applique, aucune ressource partagée n’est accessible. La résilience commence avec un deuxième contrôleur de domaine, configuré pour que la chute d’un seul DC ne se voie pas côté utilisateur. Ce tutoriel installe DC02, configure la réplication, vérifie la cohérence et explique comment gérer les rôles FSMO entre les deux serveurs.

Prérequis : un DC opérationnel (cf. Promouvoir le premier contrôleur de domaine). Panorama : Windows Server 2025 et Active Directory pour PME.

Prérequis

• DC01 fonctionnel, dcdiag sans erreur, base AD saine.
• Un second serveur Windows Server 2025 installé selon la même méthode (cf. Installer Windows Server 2025 et préparer le rôle AD DS) : nom DC02, IP 10.10.0.11, DNS pointant en premier sur DC01 puis sur lui-même.
• Connectivité réseau complète entre DC01 et DC02 : LDAP 389, Kerberos 88, RPC dynamique.
• Un compte Enterprise Admin ou Domain Admin.
• Niveau attendu : intermédiaire.
• Temps estimé : 45 minutes.

Étape 1 — Préparer DC02 et le rôle AD DS

Sur DC02, vérifier la résolution DNS du domaine, condition sine qua non pour rejoindre le domaine en tant que DC :

nslookup ad.entreprise.com
Resolve-DnsName -Name '_ldap._tcp.ad.entreprise.com' -Type SRV

Le SRV doit pointer vers DC01. Si la résolution échoue, vérifier la configuration DNS de la carte réseau de DC02 — elle doit avoir DC01 en DNS primaire.

Joindre DC02 au domaine :

$cred = Get-Credential
Add-Computer -DomainName 'ad.entreprise.com' -Credential $cred -Restart -Force

Après redémarrage, ouvrir une session avec un compte Domain Admin et installer le rôle AD DS :

Install-WindowsFeature -Name AD-Domain-Services -IncludeManagementTools

Étape 2 — Promouvoir DC02 en contrôleur de domaine secondaire

Le cmdlet Install-ADDSDomainController ajoute un DC à un domaine existant. Trois paramètres clés : le domaine cible, le mot de passe DSRM (distinct de celui de DC01), et le choix d’installer aussi le rôle DNS et le Global Catalog (recommandé pour les deux).

$dsrm = ConvertTo-SecureString 'VotreMotDePasseDSRM-DC02-2026!' -AsPlainText -Force
$cred = Get-Credential -Message 'Domain Admin pour la promotion'

Install-ADDSDomainController `
  -DomainName 'ad.entreprise.com' `
  -InstallDns:$true `
  -NoGlobalCatalog:$false `
  -Credential $cred `
  -SafeModeAdministratorPassword $dsrm `
  -SiteName 'Default-First-Site-Name' `
  -DatabasePath 'C:\Windows\NTDS' `
  -SysvolPath 'C:\Windows\SYSVOL' `
  -LogPath 'C:\Windows\NTDS' `
  -NoRebootOnCompletion:$false `
  -Force:$true

L’exécution prend 15 à 20 minutes. PowerShell affiche la création de la base, la réplication initiale depuis DC01, l’installation des services Kerberos, le partage SYSVOL. À la fin, redémarrage automatique. DC02 devient un DC complet répliquant avec DC01.

Étape 3 — Vérifier la réplication initiale

Immédiatement après le redémarrage, vérifier l’état de la réplication :

repadmin /replsummary
repadmin /showrepl
Get-ADReplicationPartnerMetadata -Target DC02

repadmin /replsummary donne un tableau de bord : aucune erreur ne doit apparaître. repadmin /showrepl détaille chaque partition (Schema, Configuration, Domain) et chaque partenaire. Une mention was successful sur chaque ligne, avec une heure récente, indique que la réplication tourne correctement.

Vérifier également côté annuaire :

Get-ADDomainController -Filter *
Get-ADComputer -Identity DC02 -Properties OperatingSystem, OperatingSystemVersion

DC01 et DC02 doivent tous deux apparaître, avec OS Windows Server 2025.

Étape 4 — Configurer DNS sur DC02

DC02 hérite automatiquement de la zone DNS ad.entreprise.com par la réplication AD. Mais ses propres paramètres serveur DNS (forwarders, scavenging) ne sont pas répliqués automatiquement — il faut les configurer comme sur DC01 :

Set-DnsServerForwarder -IPAddress 1.1.1.1, 1.0.0.1 -UseRootHint $false
Set-DnsServerScavenging -ScavengingState $true -ScavengingInterval 7.00:00:00 -ApplyOnAllZones

Ajuster la résolution DNS de la carte réseau de DC02 pour que le DNS primaire soit désormais lui-même (127.0.0.1) et le secondaire DC01 (10.10.0.10). De même, mettre à jour DC01 pour que son DNS secondaire soit DC02. La règle générale : un DC interroge son propre DNS en premier, et un pair en secondaire.

# Sur DC01
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses 127.0.0.1, 10.10.0.11

# Sur DC02
Set-DnsClientServerAddress -InterfaceAlias 'Ethernet' -ServerAddresses 127.0.0.1, 10.10.0.10

Aparté — La topologie de réplication AD en clair

Active Directory ne réplique pas en mode étoile (un maître, des esclaves) mais en multi-maître : tous les DC sont équivalents pour la plupart des opérations, chacun peut accepter une modification, et le service KCC (Knowledge Consistency Checker) calcule automatiquement la topologie de réplication la plus efficace entre les DC d’un site et entre sites distants.

Dans un site, la réplication est immédiate : un changement effectué sur DC02 (par exemple un mot de passe utilisateur) est répliqué sur DC01 en moins de 15 secondes (intervalle notify par défaut). Entre sites, la réplication est planifiée selon les paramètres du Site Link — par défaut 180 minutes, configurable de 15 minutes à plusieurs heures selon la bande passante disponible.

La résolution des conflits suit une règle déterministe : si DC01 et DC02 reçoivent une modification incompatible du même attribut en même temps, le timestamp le plus récent gagne, et en cas d’égalité parfaite, le GUID de l’origine sert d’arbitre. Cette propriété permet à AD de continuer à fonctionner même si la communication entre DC est intermittente — tout finit par converger.

Pour une PME mono-site avec deux DC dans le même LAN, on n’a presque jamais à toucher à la topologie : le KCC fait son travail. Sur les déploiements multi-sites (bureau Paris + bureau Lyon reliés en VPN), on définit des sites AD, on les associe à des subnets, et on configure les Site Links pour optimiser le trafic.

Étape 5 — Comprendre les rôles FSMO et leur emplacement

Les cinq rôles FSMO restent par défaut sur DC01. Quelques rappels utiles avant tout transfert :

• Schema Master et Domain Naming Master sont uniques par forêt. Très peu sollicités, on les laisse sur le DC le plus stable, typiquement DC01.
• PDC Emulator est le plus critique au quotidien. Toute panne du PDC est immédiatement visible (changements de mot de passe lents, désynchronisation d’horloge). Hébergeable sur n’importe quel DC, mais on le place sur le DC le mieux dimensionné.
• RID Master distribue les pools de RID aux autres DC. Une indisponibilité est silencieuse jusqu’à épuisement du pool local.
• Infrastructure Master gère les références inter-domaines. En forêt mono-domaine, il n’a aucun travail réel. À ne pas mettre sur un DC porteur du Global Catalog dans une forêt multi-domaines, sans importance ici.

Lister la répartition actuelle :

netdom query fsmo
Get-ADForest | Select-Object SchemaMaster, DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator, RIDMaster, InfrastructureMaster

Sur une PME mono-domaine avec deux DC, on peut soit tout laisser sur DC01 (simple), soit répartir : Schema/Naming/PDC sur DC01, RID/Infrastructure sur DC02. La seconde option n’apporte qu’un faible gain de résilience — on retient la simplicité.

Étape 6 — Transférer un FSMO si nécessaire

Quand on souhaite déplacer un rôle FSMO (planification de maintenance sur DC01, mise hors service planifiée), on utilise Move-ADDirectoryServerOperationMasterRole. Le transfert est immédiat et propre, sans interruption de service :

Move-ADDirectoryServerOperationMasterRole -Identity DC02 `
  -OperationMasterRole PDCEmulator -Confirm:$false

Vérifier ensuite que le PDC Emulator est bien sur DC02 :

netdom query fsmo

Quand DC01 est de nouveau disponible, on peut transférer dans l’autre sens avec la même commande. La saisie (seize) — opération à utiliser uniquement quand le DC porteur est définitivement perdu — se fait avec ntdsutil et impose ensuite de purger les références à l’ancien DC (metadata cleanup).

Étape 7 — Tester la résilience par arrêt contrôlé

Un seul moyen de prouver que la redondance fonctionne : éteindre l’un des deux DC et vérifier que tout continue. Procéder en heures creuses, un poste de test sous la main.

# Sur DC01
Stop-Computer -Force

Pendant l’arrêt, sur un poste client : ouvrir une session avec un compte AD, vérifier que les GPO s’appliquent, créer un nouveau compte utilisateur depuis ADUC (qui s’exécute désormais contre DC02), naviguer un partage de fichiers protégé par AD. Tout doit fonctionner sans dégradation visible.

Redémarrer DC01 et observer la réplication remonter :

# Sur DC01 redémarré
Start-Service NTDS
repadmin /syncall /AdeP

La synchronisation se fait en quelques secondes. Le compte utilisateur créé pendant l’arrêt de DC01 est désormais présent dans la base de DC01.

Étape 8 — Configurer le monitoring de réplication permanent

Sans monitoring, une rupture de réplication peut rester invisible des semaines. Le script suivant lance une vérification quotidienne et envoie un mail si une erreur apparaît :

# C:\Admin\check-replication.ps1
$result = repadmin /replsummary 2>&1
if ($LASTEXITCODE -ne 0 -or $result -match 'failures' -or $result -match 'fail') {
  Send-MailMessage -To 'admin@entreprise.com' -From 'noreply@entreprise.com' `
    -Subject 'AD Replication ERROR' -Body ($result -join "`n") `
    -SmtpServer 'smtp.office365.com' -Port 587 -UseSsl `
    -Credential (Import-CliXml C:\Admin\smtp.cred)
}

Planifier la tâche dans le Task Scheduler chaque jour à 7h. Si le service est en place, une dégradation est détectée avant ouverture des bureaux.

Étape 9 — Préparer la procédure de bascule en urgence

Documenter à froid les commandes à exécuter quand DC01 tombe définitivement. Le document de procédure doit être imprimé ET accessible offline (PDF sur clé USB), pas seulement sur un wiki interne qui peut être inaccessible pendant la panne.

Procédure type :

1. Vérifier que DC02 répond : Test-NetConnection DC02 -Port 389.
2. Saisir les FSMO sur DC02 : ntdsutil "role" connections "connect to server DC02" quit "seize naming master" "seize schema master" "seize pdc" "seize rid master" "seize infrastructure master" quit quit.
3. Vérifier : netdom query fsmo doit montrer DC02 partout.
4. Nettoyer les références à DC01 dans AD : ntdsutil "metadata cleanup".
5. Promouvoir un nouveau DC03 ASAP pour restaurer la redondance.

Étape 10 — Comprendre le mode RODC pour les sites distants

Le Read-Only Domain Controller (RODC) est une variante de DC introduite avec Windows Server 2008, particulièrement utile pour les bureaux distants où la sécurité physique est moins maîtrisée. Un RODC héberge une copie de l’annuaire mais ne stocke aucun secret par défaut : les hashs de mot de passe ne sont pas répliqués, sauf pour des utilisateurs explicitement autorisés (Allowed RODC Password Replication Group).

Si un bureau distant a un RODC volé, l’attaquant ne peut pas extraire les hashs de l’entreprise : il n’aurait que ceux des utilisateurs du bureau distant. La compromission est limitée et réparable en supprimant le compte RODC dans AD, ce qui invalide tous les hashs dérivés.

Pour une PME mono-site, le RODC n’a pas d’intérêt. Pour une PME avec un site distant (filiale, atelier), il devient pertinent : on déploie un RODC au lieu d’un DC complet, on autorise la réplication des hashs uniquement pour les comptes du site, et on garde la base secrète centralisée au siège.

La promotion d’un RODC se fait via :

Install-ADDSDomainController -DomainName 'ad.entreprise.com' `
  -ReadOnlyReplica -SiteName 'Filiale-Lyon' `
  -Credential (Get-Credential) `
  -SafeModeAdministratorPassword (Read-Host -AsSecureString) `
  -Force

Étape 11 — Vérifier le Global Catalog

Un Global Catalog héberge une copie partielle de toutes les partitions de la forêt. Il est nécessaire pour l’ouverture de session universelle (recherche d’appartenances aux groupes universels) et pour les recherches Active Directory globales. Sur une PME mono-domaine, on en a au moins deux pour la résilience.

Get-ADDomainController -Filter * | Select-Object Name, IsGlobalCatalog, Site

DC01 et DC02 doivent tous deux avoir IsGlobalCatalog: True. La présence de plusieurs GC dans la forêt apporte trois avantages : ouverture de session plus rapide pour les utilisateurs (recherche locale des groupes universels au lieu d’une requête réseau lointaine), résilience en cas de panne d’un GC, et meilleure répartition de la charge des recherches LDAP globales émises par les applications. Sur une PME mono-site, on garde donc tous les DC en GC sans surcoût opérationnel — la base est de toute façon répliquée intégralement entre les deux serveurs. Sur une infrastructure multi-sites, on peut au contraire désactiver le GC sur certains DC distants pour économiser la bande passante WAN, au prix d’une dégradation des ouvertures de session locales. Si DC02 ne l’a pas reçu lors de la promotion : Set-ADObject -Identity '...NTDS Settings,...' -Replace @{options=1} ou plus simple via ADSI Edit.

Erreurs fréquentes

Vérification finale

Vous disposez maintenant d’un domaine Active Directory à deux contrôleurs de domaine répliquant correctement, chacun Global Catalog et DNS, FSMO sur DC01, monitoring de réplication quotidien, procédure de bascule documentée. La panne d’un DC n’arrête plus l’entreprise.

Pour aller plus loin, la suite logique est sauvegarder et restaurer Active Directory — la redondance protège contre les pannes matérielles, pas contre la corruption logique. Pour le panorama : Windows Server 2025 et Active Directory pour PME.

Ressources officielles

• Install-ADDSDomainController — Microsoft Learn PowerShell
• FSMO roles and recovery — Microsoft Learn
• Troubleshoot AD replication with dcdiag — Microsoft Learn
• Move-ADDirectoryServerOperationMasterRole — Microsoft Learn