Vous changez de domaine AD de example.com vers test.com. Ce guide opérationnel couvre les deux options (migration inter-forêts avec ADMT ou renommage avec rendom), la transition DNS, les outils, les tests et les écueils pour réussir la bascule sans interruption.
Sommaire
Migration d’Active Directory (AD) et de DNS vers un nouveau nom de domaine
Vue d’ensemble de la question
L’entreprise doit remplacer son domaine example.com par test.com et recherche :
- des guides pour migrer Active Directory et ses zones DNS ;
- les étapes concrètes et les outils nécessaires ;
- les avantages, limites et éventuels écueils de la démarche.
Deux approches possibles
Il existe deux stratégies éprouvées pour changer le nom d’un domaine Active Directory : renommer le domaine existant (rendom) ou migrer vers un nouveau domaine/forêt (ADMT). Le choix dépend de votre périmètre applicatif, des contraintes de continuité de service et des technologies présentes (Exchange, hybridation Microsoft 365/Entra ID, etc.).
| Critère | Renommage du domaine (rendom) | Nouvelle forêt + migration (ADMT) |
|---|---|---|
| Principe | On garde la même forêt et les mêmes objets, seul le FQDN change. | On crée un domaine/forêt neufs puis on migre comptes, postes et ressources. |
| Interop/applications | Exige une compatibilité stricte. Certains produits ne supportent pas le renommage (ex. environnements Exchange 2016+). | Très compatible : on reconstruit proprement et on traite au cas par cas les dépendances. |
| Complexité | Techniquement délicat : impacts sur GPO, SPN, certificats, DFS, scripts, chemins UNC. | Projet plus long, mais contrôlable par phases (coexistence, pilote, vague par vague). |
| Retour arrière | Possible mais étroit, nécessite des sauvegardes et un plan précis. | Simple : on maintient l’ancien domaine en parallèle tant que nécessaire. |
| Quand choisir ? | Petit périmètre, pas d’apps incompatibles, nécessité de conserver l’unicité. | Environnements hétérogènes, remise à plat souhaitée, besoin d’hygiène AD. |
Synthèse des étapes
| Étape | Objectif | Actions clés / Outils |
|---|---|---|
| Sauvegarder l’environnement actuel | Pouvoir revenir en arrière en cas d’échec | Windows Server Backup (état du système/AD + SYSVOL) ; export des zones DNS (DNS Manager / dnscmd). |
| Préparer le nouveau domaine | Créer l’infrastructure cible | Installer le rôle AD DS ; promouvoir en contrôleur de domaine via Server Manager ou PowerShell ; choisir le niveau fonctionnel. |
| Créer une relation d’approbation (Trust) | Faciliter la coexistence et la migration progressive | Dans Active Directory Domains and Trusts : trust bidirectionnel (externe ou forêt) temporaire. |
| Migrer les objets | Déplacer comptes, groupes, PC et SIDHistory | ADMT 3.2 + SQL Express ; commencer par un pilote, puis vagues successives. |
| Tester et valider | Vérifier authentification, GPO, accès aux ressources | Contrôles de connexion, imprimantes, applications métier, scripts d’ouverture de session. |
| Mettre à jour DNS | Assurer la résolution pour le nouveau domaine | Créer les zones test.com, ajuster redirecteurs et enregistrements SRV, supprimer l’ancien après validation. |
| Nettoyer et décommissionner | Retirer l’ancien domaine en toute sécurité | Tomber les trusts, rétrograder les anciens DC, supprimer zones DNS et métadonnées. |
Procédure détaillée – Nouvelle forêt + ADMT
Pré-requis et hygiène AD
- Contrôles santé :
dcdiag /e /c /v,repadmin /replsummary,repadmin /showrepl *. - Vérifier que SYSVOL réplique via DFSR (FRS obsolète). Réparer avant tout projet.
- Inventorier GPO, scripts, DFS Namespaces, chemins UNC, SPN, UPN, partages, imprimantes.
- Bloquer les changements (freeze) pendant la bascule : pas de création de GPO/OU non planifiée.
Sauvegarder l’environnement source
Effectuez au minimum :
- Sauvegarde état du système de chaque DC.
- Sauvegarde SYSVOL (DFSR) + export des GPO.
- Export DNS des zones AD-intégrées.
wkcmds (exemples)
wbadmin start systemstatebackup -backuptarget:E: -quiet
dnscmd /zoneexport example.com example.com.dns
# Export GPO
Backup-GPO -All -Path "E:\Backups\GPO"
Créer le domaine cible test.com
Sur un serveur Windows Server neuf (durci, patché, IP fixe, pointant vers lui-même comme DNS primaire) :
# Installation des rôles AD DS et DNS
Install-WindowsFeature AD-Domain-Services,DNS -IncludeManagementTools
# Création d'une nouvelle forêt
Install-ADDSForest -DomainName "test.com" -DomainNetbiosName "TEST" -InstallDNS `
-SafeModeAdministratorPassword (Read-Host "DSRM password" -AsSecureString) -Force - Configurer NTP : le PDC Emulator de la nouvelle forêt doit être source de temps fiable (
w32tm). - Définir le site AD et les sous-réseaux (Active Directory Sites and Services).
- Ajoutez un deuxième DC pour la résilience (réplication, DNS, catalogue global).
Configurer la résolution DNS entre domaines
La cohabitation impose une résolution bidirectionnelle des noms :
- Créer des redirecteurs conditionnels de
test.comvers les DNS d’example.comet inversement. - Ouvrir le trafic nécessaire (TCP/UDP 53, RPC, LDAP/LDAPS, Kerberos, etc.) entre DC/DNS.
# Exemple côté test.com
Add-DnsServerConditionalForwarderZone -Name "example.com" -MasterServers 10.10.10.10,10.10.10.11 -ReplicationScope Forest
# Et côté example.com (symétrique)
Créer une relation d’approbation
Un trust bidirectionnel (forêt↔forêt ou externe) simplifie les accès durant la migration.
# Exemple avec netdom (à exécuter avec comptes ayant les droits des deux côtés)
netdom trust test.com /domain:example.com /add /twoway /passwordt:* /passwordo:*
# Optionnel selon le scénario : autoriser la migration de SIDHistory et lever le filtrage SID
netdom trust test.com /domain:example.com /EnableSIDHistory:Yes /Quarantine:No
Préparer ADMT 3.2
- Installer ADMT 3.2 dans le domaine cible (idéalement sur un serveur membre dédié).
- Installer SQL Server Express local pour la base ADMT.
- Créer un compte de service pour ADMT (admin source et cible) et configurer le droit Migrate SID History.
- Déployer l’Agent ADMT sur les postes/serveurs pendant la migration des ordinateurs.
Migrer comptes et groupes
- Migrer groupes (global → universel si nécessaire) pour préserver les appartenances.
- Migrer utilisateurs avec SIDHistory, mots de passe, et profil utilisateur (translation de profil).
- Configurer les UPN avec suffixe
@test.comet rediriger l’authentification.
# Exemples utiles côté cible
Get-ADUser -Filter * -SearchBase "OU=Migrated,DC=test,DC=com" |
Set-ADUser -UserPrincipalName {$_.SamAccountName + "@test.com"}
# Lister/contrôler les SPN (pour services applicatifs)
setspn -Q */example.com Migrer ordinateurs et serveurs
- Procéder par lots : pilote (5–10 machines), puis vagues (par site, par BU).
- ADMT gère la rejonction au nouveau domaine et la translation de profil s’il est local.
- Prévoir des fenêtres hors production pour les serveurs et vérifier services/agents après redémarrage.
Ressources et ACL
Grâce au SIDHistory, l’accès continue à fonctionner. Mais pour assainir :
- Re-ACL les partages/NTFS avec les nouveaux SIDs (
icacls/Set-Acl), puis supprimer progressivement les SIDs hérités. - Mettre à jour DFS Namespaces (chemins
\\test.com\...), et vérifier DFSR. - Adapter scripts, tâches planifiées, et chaînes de connexion (SQL, IIS, LDAP binds).
Mettre à jour DNS et suffixes
- Créer la zone
test.comintégrée AD et valider les enregistrements SRV (_msdcs). - DHCP : mettre à jour les Options 006 (serveurs DNS) et 015 (suffixe DNS), et si utilisé 119 (liste de suffixes).
- GPO : définir la Primary DNS Suffix et la DNS Suffix Search List pour les clients.
# Contrôles DNS
nslookup -type=SRV _ldap._tcp.dc._msdcs.test.com
nltest /dsgetdc:test.com
Tests et validation
| Périmètre | Vérifications | Commandes/indicateurs |
|---|---|---|
| Authentification | Logon utilisateurs, verrouillage, stratégie de mots de passe | klist purge, whoami /all |
| GPO | Application côté ordinateur/utilisateur, absence d’erreurs 1058/1030 | gpresult /h, Get-GPOReport |
| DNS | Résolution interne, SRV, latence | dcdiag /test:dns, Resolve-DnsName |
| Réseau | Firewall inter-domaines, ports Kerberos/LDAP | PortQry, pare-feu |
| Ressources | Accès partages/imprimantes/applications | Logs applicatifs, event viewer |
Nettoyage et décommissionnement
- Vérifier qu’aucun compte/serveur ne s’authentifie encore sur
example.com(auditer DC source). - Rompre les trusts, rétrograder les anciens DC (Server Manager ou PowerShell ci‑dessous).
- Supprimer les zones DNS
example.com, nettoyer les métadonnées AD.
# Rétrogradation d'un DC moderne
Uninstall-ADDSDomainController -DemoteOperationMasterRole:$true -LocalAdministratorPassword (Read-Host -AsSecureString) -Force
Procédure détaillée – Renommage de domaine avec rendom
Quand privilégier cette option ?
- Une seule forêt (et idéalement un seul domaine) avec périmètre maîtrisé.
- Pas de produits non supportés par le renommage (par ex. environnements Exchange 2016+).
- Niveaux fonctionnels suffisants (Windows Server 2008 R2 ou plus récents).
Étapes clés
- Contrôles préalables :
dcdiag,repadmin, santé DNS, pas d’erreurs DFSR. - Générer la configuration :
rendom /list(produitdomainlist.xml), éditerexample.com→test.com(et NetBIOSEXAMPLE→TESTsi souhaité). - Valider la vue :
rendom /showforest. - Uploader et préparer :
rendom /upload,rendom /prepare. - Exécuter le renommage :
rendom /execute(redémarrage automatique des DC). - Réparer GPO :
gpfixup /olddns:example.com /newdns:test.cometgpfixup /oldnb:EXAMPLE /newnb:TEST. - Actualiser DNS : renommer la zone AD-intégrée, vérifier
_msdcs, nettoyer les vieux enregistrements. - SPN & certificats : rechercher
setspn -Q */example.com, réinscrire si nécessaire ; reconfigurer vos modèles/autorités si l’URL de CDP/AIA contient l’ancien FQDN. - Fin de procédure :
rendom /end, puis contrôles de santé, sauvegardes.
Plan DNS robuste pendant la transition
- Coexister proprement : conserver
example.comactif jusqu’à la fin des migrations, avec conditional forwarders bidirectionnels. - Tester _ldap._tcp.dc._msdcs et la découverte DC via
nltest. - Éviter les « split-brain DNS » non maîtrisés : centraliser les enregistrements critiques côté AD.
- Documenter/mettre à jour les zones inverses, enregistrements statiques (A/CNAME), politiques DNSSEC si utilisées.
Sécurité, identités et certificats
- UPN : basculer les suffixes vers
@test.com(et ajouter un suffixe alternatif si des apps nécessitent encore@example.com). - SPN : rechercher et corriger les SPN incluant l’ancien FQDN (IIS/HTTP, MSSQLSvc, LDAP, CIFS, etc.).
- gMSA : régénérer les comptes gMSA si le KDS root key est recréé dans la nouvelle forêt.
- PKI interne (AD CS) : si CDP/AIA pointent sur
http://pki.example.com/..., republier soustest.com, reconfigurer les modèles et autoenrollment GPO. - NTFS/partages : audit et nettoyage des SIDs orphelins après migration.
Outils recommandés
- ADMT 3.2 (migration comptes, groupes, postes, SIDHistory).
- rendom, gpfixup (renommage de domaine et réparation GPO).
- RSAT/PowerShell (
ActiveDirectory,DnsServer,GroupPolicy). - dcdiag, repadmin, nltest, PortQry.
- dnscmd / DNS Manager (export/gestion zones).
Pièges fréquents et comment les éviter
- Applications non supportées : valider explicitement le renommage (rendom) pour chaque produit. En cas de doute, privilégier la migration inter-forêts.
- Scripts/GPO « codés en dur » : chemins UNC, lecteurs mappés, paramètres de déploiement logiciel pointant vers
\\example.com\.... - DFS : oublis de mise à jour des cibles/espaces de noms, ou de redéclaration des referrals.
- DNS : forwarders unidirectionnels provoquant des erreurs d’auth Kerberos entre forêts.
- Profils utilisateurs : translation incomplète (roaming/local). Tester la continuité des profils.
- SPN dupliqués : résolus avant bascule (
setspn -X), sinon échecs Kerberos. - FRS encore présent : migrer à DFSR avant toute opération.
Vérifications techniques utiles
# Rôles FSMO
netdom query fsmo
Get-ADForest | Select SchemaMaster,DomainNamingMaster
Get-ADDomain | Select PDCEmulator,RIDMaster,InfrastructureMaster
# Santé AD / réplication
dcdiag /e /c /v /f:dcdiag.txt
repadmin /replsummary
repadmin /showrepl *
# Découverte DC
nltest /dsgetdc:test.com
klist purge && klist
# DNS SRV & A
Resolve-DnsName _ldap._tcp.dc._msdcs.test.com -Type SRV
Resolve-DnsName dc1.test.com -Type A Plan de projet type
| Phase | Livrables | Conseils |
|---|---|---|
| Évaluation et design | AT/risques, matrice compatibilité apps, décision rendom vs ADMT | Impliquer sécurité et propriétaires d’applis dès le départ. |
| Préparation | Backups, durcissement, nouveau domaine test.com, trust, DNS | Automatiser PowerShell, définir critères de sortie/entrée de phase. |
| Pilote | 10–30 utilisateurs/PC, 1–2 applis critiques | Mettre en place un canal de support dédié. |
| Déploiement | Vagues par site, re-ACL, mise à jour GPO/DFS | Fenêtres de maintenance, communication claire aux utilisateurs. |
| Stabilisation | Monitoring, correction des écarts, documentation finale | Auditer les SIDs orphelins et supprimer SIDHistory quand tout est propre. |
| Décommissionnement | Rétrogradation DC, suppression zones DNS, fin des trusts | Conserver l’ancienne infra hors ligne pendant ~30 jours avant destruction. |
Cas particuliers et bonnes pratiques
- Messagerie et services tiers : Exchange, SharePoint, Skype/Teams nécessitent des plans spécifiques ou une hybridation. Si ces charges existent, la migration inter‑forêts est souvent plus sûre que le renommage.
- Impression : re-publier les imprimantes dans le nouveau domaine, ou déployer des connexions via GPO ciblées par groupe de sécurité migré.
- Inventaire et CM : SCCM/ConfigMgr, Intune, EDR : prévoir la réinscription/retargeting si le nom de domaine est présent dans les boundaries ou URLs d’accès.
- Accès distant/VPN : scripts de VPN, NRPT (DirectAccess), portails applicatifs : mettre à jour les FQDN.
Plan de retour arrière
| Scénario | Retour arrière | Points de vigilance |
|---|---|---|
| Migration inter-forêts (ADMT) | Conserver le trust et les sauvegardes ; rebasculer les comptes/PC vers example.com et restaurer GPO/ACL si besoin. | Bien tracer les lots migrés et les ACL modifiées. |
| Renommage (rendom) | Procédure rendom /rollback si étape critique échoue, sinon restauration état système. | Fenêtre courte, tester en pré‑prod impérativement. |
Checklist opérationnelle
- Backups AD/SYSVOL/DNS vérifiées (restaurations testées).
- Deux DC par forêt, santé
dcdiag/repadminverte. - Trust bidirectionnel et résolution DNS dans les deux sens.
- Pilote validé (auth, GPO, impressions, applis).
- Plan de communication et FAQ utilisateurs.
- Plan de retour arrière documenté.
Informations complémentaires utiles
- Renommage de domaine : si le domaine reste dans la même forêt et que les conditions (Windows Server 2008 R2 + niveau fonctionnel min. 2008) sont remplies, l’outil rendom peut parfois suffire ; il évite la création d’un second domaine, mais reste délicat (pas supporté pour les environnements Exchange 2016+).
- Certificats & SPN : prévoir la mise à jour des certificats internes (AD CS), SPN et fichiers de configuration d’applications (SQL, IIS, LDAP bindings).
- Fichiers DFS, GPO, scripts : vérifier les chemins UNC codés en dur et les GPO qui contiennent l’ancien FQDN.
- Messagerie & services tiers : pour Exchange, SharePoint, Skype/Teams, un plan de migration ou d’hybridation spécifique est nécessaire.
- Sécurité : après migration, passer en revue les ACL NTFS/Share pour éliminer les SID orphelins de l’ancien domaine.
- Plan de retour arrière : garder les sauvegardes AD + DNS au minimum jusqu’à validation complète (souvent 30 jours).
- Option « nouvel environnement » : si l’infrastructure est petite ou qu’un lifting global est prévu, monter un domaine neuf puis migrer uniquement les données peut être plus fiable que l’ADMT.
Exemples de commandes prêtes à l’emploi
# Export des zones DNS et sauvegarde
dnscmd /zoneexport example.com example.com.dns
dnscmd /zoneexport _msdcs.example.com _msdcs.example.com.dns
# Création zone test.com intégrée AD (via GUI ou PowerShell)
Add-DnsServerPrimaryZone -Name "test.com" -ReplicationScope Forest -DynamicUpdate Secure
# DHCP (à ajuster côté serveur DHCP)
# Option 006 : liste des DNS
# Option 015 : suffixe DNS = test.com
# Option 119 : liste de suffixes = test.com,example.com
# UPN suffixes
Get-ADForest | Set-ADForest -UPNSuffixes @{Add="test.com"}
# Remontée des doublons SPN
setspn -X
# GPO - export & audit
Backup-GPO -All -Path "E:\Backups\GPO"
Get-GPOReport -All -ReportType Html -Path "E:\Backups\GPO\GpoReport.html" FAQ rapide
Faut-il garder le SIDHistory ? Oui pendant la coexistence, pour ne pas casser les accès. Une fois les ACL réécrites et stabilisées, vous pouvez purger les anciens SIDs.
Peut-on renommer le NetBIOS en même temps ? Oui avec rendom, mais cela augmente le risque : validez l’impact sur scripts et partages.
Que faire pour Microsoft 365/Entra ID ? Ajouter et vérifier test.com comme nouveau domaine, mettre à jour les UPN et reconfigurer AAD Connect si nécessaire (hors périmètre détaillé ici).
Quid des postes hors domaine ? Traiter via VPN/MDM, prévoir des GPO ou scripts de rejonction, et des comptes locaux de secours.
Conclusion
Changer de nom de domaine AD/DNS de example.com vers test.com est un chantier d’infrastructure qui exige méthode et discipline. Deux voies s’offrent à vous : le renommage, rapide mais risqué si vous avez des applications sensibles, et la migration inter‑forêts avec ADMT, plus longue mais plus robuste. Quel que soit le choix, les clés d’une bascule réussie sont : des sauvegardes testées, une préparation DNS et des trusts propres, des pilotes représentatifs, un suivi méticuleux des GPO/ACL/SPN, et un nettoyage final (SID orphelins, vieux enregistrements DNS) avant le retrait contrôlé de l’ancien domaine.