Après une migration d’un domaine depuis un Samba DC vers Windows Server, vos utilisateurs ne peuvent plus ouvrir de session dès que les postes pointent le DNS vers le DC 2016 ? Voici un plan d’action complet pour rétablir l’authentification et préparer sereinement l’arrivée de Windows Server 2022.
Contexte et symptôme après migration
Scénario typique : les rôles FSMO ont d’abord été transférés de Samba vers un Windows Server 2008 R2, puis basculés vers un Windows Server 2016. À partir du moment où les stations clientes (Windows) utilisent le DC 2016 comme DNS principal, les ouvertures de session échouent (impossibilité d’obtenir un ticket Kerberos ou de localiser un contrôleur). Les diagnostics dcdiag rapportent que « aucun PDC Emulator n’est trouvé » alors que ce même serveur détient officiellement le rôle PDC.
Dans 90 % des cas, la cause est un enregistrement DNS manquant/erroné, une réplication Active Directory défaillante, un SYSVOL non publié ou une synchronisation horaire incorrecte. Le reste du guide vous propose une méthode éprouvée, pas à pas, pour revenir à un état sain, valider votre DC 2016 comme point d’entrée, puis introduire proprement des DC 2022.
Check‑list de diagnostic prioritaire
Commencez par ce « quick‑win ». Si toutes les lignes passent au vert, 80 % du problème est derrière vous.
| Action | Commande / où regarder | Résultat attendu |
|---|---|---|
| Le DC 2016 se référence lui‑même en DNS primaire | Propriétés IPv4 du NIC | DNS 1 = l’IP du DC 2016, DNS 2 = un autre DC |
| Enregistrements SRV présents | Resolve-DnsName -Type SRV _ldap._tcp.[domaine] | Le DC 2016 apparaît comme cible SRV |
| Réplication AD OK | repadmin /replsummary | Colonnes « Fails » à 0 |
| SYSVOL et NETLOGON partagés | net share sur le DC 2016 | Partages SYSVOL et NETLOGON visibles |
| Global Catalog activé | « Sites et services AD » > NTDS Settings | La case « Global Catalog » est cochée |
| Heure correcte | w32tm /query /status | PDC Emulator synchronisé sur une source NTP fiable |
| Découverte du PDC côté client | nltest /dsgetdc:[domaine] /PDC | Retourne le DC 2016 |
Causes probables et contrôles détaillés
| Catégorie | Points de contrôle |
|---|---|
| DNS | Le DC 2016 doit utiliser son propre service DNS comme primaire, et un autre DC comme secondaire. Vérifiez les enregistrements SRV (_ldap._tcp, _kerberos._tcp, _gc._tcp, _kpasswd._tcp), y compris sous _msdcs.[domaine]. nslookup et Resolve-DnsName doivent résoudre _ldap._tcp.dc._msdcs.[domaine] vers le DC 2016. Forcer un ré‑enregistrement : ipconfig /registerdns puis nltest /dsregdns. |
| Réplication AD / DFSR | repadmin /showrepl et repadmin /replsummary doivent remonter 0 échec. Pour SYSVOL, DFSR doit être à l’état final : dfsrmig /getglobalstate → Eliminated. Évitez toute alerte USN rollback, lingering objects, ou erreurs 2213 (DFSR). |
| Rôles FSMO | netdom query fsmo doit montrer tous les rôles sur le même DC (celui prévu). Validez dans les consoles « Operations Masters » (RID, PDC, Infrastructure, Schema, Domain‑naming). |
| Synchronisation horaire | Le PDC Emulator du domaine racine synchronise son heure sur une source NTP externe fiable (ex. pool.ntp.org). Les autres DC et les postes utilisent la hiérarchie AD (NT5DS) ou pointent vers le PDC. |
| Services AD | Le DC 2016 est Global Catalog et publie correctement SYSVOL & NETLOGON (test : \\dc2016\sysvol). Le service Active Directory Web Services (ADWS) fonctionne (port 9389, utile pour certaines consoles). |
| Pare‑feu / Réseau | Ports ouverts : 53 (DNS), 88 (Kerberos), 123 (NTP), 135 (RPC), 389/636 (LDAP/LDAPS), 445 (SMB), 3268/3269 (GC), 464 (kpasswd), 5722 (DFSR), RPC dynamiques 49152–65535. Absence d’inspection SSL/NTLM/Kerberos par un équipement réseau intermédiaire. |
| Promotion / Démotion | En dernier recours : démoter proprement le DC 2016 puis le re‑promouvoir, et rebasculer les rôles FSMO. |
Procédure de remise en service recommandée
DNS d’abord : réparer et publier
- Dans la console DNS du DC 2016, vérifiez que la zone de votre domaine est intégrée à Active Directory et que les mises à jour dynamiques sont sécurisées uniquement.
- Assurez‑vous que la zone
_msdcs.[domaine]existe et se réplique au bon périmètre (forêt en général). - Sur le DC 2016 :
ipconfig /flushdns ipconfig /registerdns nltest /dsregdns dcdiag /test:RegisterInDNS /v - Testez les SRV :
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.[domaine] Resolve-DnsName -Type SRV _kerberos._tcp.[domaine] nslookup -type=SRV _gc._tcp.[domaine]Les réponses doivent inclure le FQDN du DC 2016 avec l’IP correcte.
Valider et corriger la réplication AD/DFSR
repadmin /syncall /AdeP
repadmin /replsummary
repadmin /showrepl *Toutes les colonnes « Fails » doivent être à 0. Pour SYSVOL, vérifiez que la migration DFSR est complète :
dfsrmig /getglobalstate
dfsrmig /getmigrationstateSi l’état n’est pas Eliminated, achevez la migration (préparation, redirection, élimination). Assurez‑vous qu’aucun ancien DC n’empêche la convergence.
Resynchroniser l’heure (NTP)
Sur le PDC Emulator (idéalement votre DC 2016 à ce stade) :
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
w32tm /resync /force
w32tm /query /statusSur les autres DC :
w32tm /config /syncfromflags:domhier /update
w32tm /resyncVérifier les rôles FSMO et l’annonce PDC
netdom query fsmo
dcdiag /test:AdvertisingLe test Advertising doit confirmer que le DC 2016 annonce PDC/GC correctement. Si besoin, transférez/assignez les rôles depuis un autre DC stable, attendez la réplication, puis revenez au DC 2016.
Services AD et publications
- Console « Sites et services Active Directory » > NTDS Settings > cochez Global Catalog.
- Vérifiez les partages :
net shareOn doit voirSYSVOLetNETLOGON. Test côté client :dir \\dc2016\sysvol dir \\dc2016\netlogon
Tester avant de repointer les clients
- Sur un poste pilote : DNS primaire → DC 2016, secondaire → autre DC.
- Redémarrez, puis lancez :
nltest /dsgetdc:[domaine] nltest /dsgetdc:[domaine] /PDC klist purge && gpupdate /force - Ouvrez une session avec un compte standard et accédez à
\\dc2016\sysvol.
Quand et comment re‑promouvoir/démoter un DC 2016
Si, malgré tout, le DC 2016 reste instable et qu’une courte interruption est acceptable :
- Démotion contrôlée depuis le Gestionnaire de serveur (ou PowerShell) en gardant les métadonnées propres.
- Vérifiez la santé du domaine (réplication, DNS, SYSVOL) sur les autres DC.
- Promotion du serveur 2016 au rôle de contrôleur de domaine.
- Transférez les FSMO une fois qu’il est sain et que
dcdiag/repadminsont au vert.
Important : ne démotez jamais le dernier DC d’un domaine, et assurez‑vous que la migration SYSVOL en DFSR est réellement finalisée.
Introduire des DC Windows Server 2022 (après stabilisation)
- Pré‑requis : santé AD (réplication, DNS, DFSR), niveau fonctionnel du domaine/forêt compatible, sauvegarde d’État Système récente.
- Promouvez un premier DC 2022 (DNS+GC), laissez la réplication converger.
- Transférez progressivement les rôles FSMO vers ce DC 2022 quand vous êtes prêt.
- Validez (tests client,
dcdiag,repadmin, SRV DNS). - Ajoutez un second DC 2022 pour la redondance (DNS/GC), puis planifiez la retraite des anciens DC (2008 R2/2016) une fois la stabilité confirmée.
Scénarios d’échec fréquents et corrections rapides
| Symptôme | Cause probable | Correction |
|---|---|---|
« Aucun PDC Emulator trouvé » dans dcdiag | SRV manquants, Netlogon non enregistré, DNS secondaire externe | nltest /dsregdns, forcer ipconfig /registerdns, corriger DNS primaire=DC 2016 |
| Connexion lente/impossible après reboot | DNS AD‑intégré non chargé (événement 4013), latence de réplication | Attendre la réplication, vérifier Event Viewer DNS & NTDS, corriger réplication |
| Erreur Kerberos KRB_AP_ERR_MODIFIED | SPN dupliqué, vieux enregistrement A/ PTR | Nettoyer les SPN (setspn -X), purger anciens enregistrements DNS |
| DFSR 2213 / SYSVOL non partagé | Récupération DFSR bloquée après arrêt brutal | Débloquer la récupération covalente puis dfsrdiag pour surveiller la reprise |
| Clients « hors domaine » | Heure > 5 min d’écart, NTP absent | Reconfigurer W32Time comme ci‑dessus, vérifier le pare‑feu UDP 123 |
Tableau de ports à autoriser (rappel)
| Service | Ports | Commentaires |
|---|---|---|
| DNS | TCP/UDP 53 | Résolution noms, enregistrements SRV |
| Kerberos | TCP/UDP 88, TCP/UDP 464 | Auth & kpasswd |
| LDAP/LDAPS | TCP 389 / 636 | Annuaire & sécurisé |
| SMB | TCP 445 | SYSVOL/NETLOGON |
| RPC | TCP 135 + 49152–65535 | Endpoint Mapper + RPC dynamiques |
| Global Catalog | TCP 3268 / 3269 | Requêtes GC |
| DFSR | TCP 5722 | Réplication SYSVOL (DFSR) |
| NTP | UDP 123 | Heure |
| AD Web Services | TCP 9389 | Consoles modernes/PowerShell |
Jeux de commandes utiles (copier‑coller)
Contrôles DNS & SRV
ipconfig /all
ipconfig /flushdns
ipconfig /registerdns
nltest /dsregdns
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.[domaine]
Resolve-DnsName -Type SRV _kerberos._tcp.[domaine] Réplication & santé AD
dcdiag /c /v
repadmin /showrepl *
repadmin /replsummary
repadmin /syncall /AdeP
FSMO & rôles
netdom query fsmo
powershell: Get-ADDomain | fl PDCEmulator,RIDMaster,InfrastructureMaster
powershell: Get-ADForest | fl SchemaMaster,DomainNamingMaster
Heure & NTP
w32tm /query /status
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org" /syncfromflags:manual /reliable:yes /update
w32tm /resync /force
Tests côté client
nltest /dsgetdc:[domaine]
nltest /dsgetdc:[domaine] /PDC
klist purge
gpupdate /force
Bonnes pratiques spécifiques à un contexte Samba → Windows
- Nettoyez les restes : enregistrements DNS orphelins (anciens DC Samba), objets de site non utilisés, connecteurs de réplication superflus.
- Consolidez le site AD où résident FSMO et GC afin d’éviter la latence lors des authentifications Kerberos.
- Surveillez quotidiennement via une tâche planifiée :
dcdiag /cetrepadmin /replsummaryavec export CSV. - Sauvegarde État Système avant toute bascule FSMO, migration DFSR, ou retrait d’un DC.
Journalisation et événements à connaître
| Journal | Événements utiles | Interprétation |
|---|---|---|
| Directory Service | 1311, 1865, 2042, 2087 | Problèmes de réplication, source introuvable, latence excessive |
| DFS Replication | 2213, 2212, 4012 | Récupération bloquée, backlog important |
| DNS Server | 4013, 4521 | Zones AD non chargées au démarrage, base corrompue |
| System | 5719 (Netlogon) | Client/serveur ne trouve aucun DC |
| Kerberos | 4, 14 | Erreurs d’intégrité de ticket, décalage horaire |
Procédure de validation finale avant bascule massive
- Échantillon de postes pilotes sur chaque site, DNS primaire = DC 2016, secondaire = autre DC.
- Vérification de l’ouverture de session, accès aux partages, GPO appliquées (
gpresult /r). - Test d’une boîte à outils :
nltest,klist,whoami /all,nslookup. - Surveillance 24–48 h des journaux et des compteurs (latence DFSR, erreurs Kerberos, événements DNS 4013).
- Mise à jour de la documentation (DFLR/FFLR, DC en production, schéma, périmètres de réplication DNS).
FAQ express
Faut‑il absolument que DFSR soit à « Eliminated » avant d’ajouter un DC récent ?
Oui, finalisez la migration SYSVOL vers DFSR pour éviter des incohérences de scripts/GPO et simplifier le support des versions ultérieures de Windows Server.
Dois‑je configurer un DNS externe sur le DC 2016 ?
Non. Les DC pointent vers des DNS AD‑intégrés (eux‑mêmes). Les résolutions publiques passent via redirecteurs/forwarders.
Mes clients échouent encore alors que le DC 2016 est sain ?
Vérifiez caches DNS côté clients (ipconfig /flushdns), supprimez d’anciens enregistrements A/PTR, purge des tickets (klist purge), et assurez‑vous que les GPO n’imposent pas un DNS tiers.
Documents Microsoft utiles (titres)
- AD DS: Best Practices for DNS
- How to Configure DFSR Migration to the ‘Eliminated’ State
- Troubleshooting AD Replication Error 1722 (The RPC server is unavailable)
Résumé opérationnel
En réparant d’abord la couche DNS (auto‑référence, enregistrements SRV, publication Netlogon), puis en confirmant la réplication AD/DFSR et la synchronisation horaire, votre DC 2016 reprend correctement son rôle de PDC Emulator et vos clients s’authentifient sans erreur. Une fois stabilisé, introduisez vos DC 2022, transférez les FSMO, et retirez progressivement les anciens contrôleurs. Cette approche limite les interruptions, fiabilise l’annuaire et prépare les évolutions futures.