MENU
  1. Accueil
  2. Windows
  3. Windows Server
  4. Erreur « Naming Information Cannot Be Located » : guide complet de dépannage Active Directory sous Windows Server

Erreur « Naming Information Cannot Be Located » : guide complet de dépannage Active Directory sous Windows Server

Windows Server

L’erreur « Naming Information Cannot Be Located » peut paralyser la gestion d’Active Directory. Cette procédure complète vous guide pour diagnostiquer et corriger la panne, de la couche réseau jusqu’aux enregistrements SRV.

Sommaire

Vue d’ensemble du problème

Lors de l’ouverture de consoles AD telles que Utilisateurs et ordinateurs Active Directory (dsa.msc) ou Sites et services Active Directory, le message d’alerte suivant apparaît :

Naming Information Cannot Be Located because:
The specified domain either does not exist or could not be contacted.

Le symptôme indique en général une rupture dans la chaîne « résolution DNS → connectivité TCP/UDP → authentification Kerberos → découverte des contrôleurs de domaine ».

Symptômes observés

  • Ouverture lente ou échec total des consoles AD.
  • Impossible d’exécuter gpupdate /force ou net view \\<DC>.
  • Événements 5719 (Netlogon), 4015 (DNS Server) ou 13508 (FRS/DFSR) dans le journal System.
  • Échec de nltest /dsgetdc:<domaine> ou Test-ComputerSecureChannel.

Causes fréquentes

  • Serveur configuré avec un DNS public ou erroné.
  • Pare‑feu intermédiaire bloquant les ports LDAP/Kerberos.
  • Canal sécurisé cassé après restauration de snapshot VMware/Hyper‑V.
  • Décalage d’horloge > 5 minutes entre le serveur et le DC.
  • Zone DNS Active Directory manquante ou endommagée.

Procédure de dépannage en neuf étapes

ÉtapeAction recommandéeObjectif
1Vérifier la connectivité réseau : ping des DC, traceroute, test VLAN, passerelleConfirmer que le trafic atteint le sous‑réseau AD
2Contrôler la configuration DNS : DNS primaire = IP d’un DC interne ; ipconfig /flushdns, /registerdnsGarantir la résolution des enregistrements SRV
3Tester la résolution SRV : nslookup _ldap._tcp.<domaine>Vérifier la publication des services LDAP/Kerberos
4Vérifier l’appartenance au domaine : nltest /dsgetdc:<domaine>S’assurer que le canal sécurisé est valide
5Synchroniser l’heure : w32tm /query /statusÉviter les rejets Kerberos liés au temps
6Analyser les journaux : sources DNS, Netlogon, LSAIdentifier un code d’erreur explicite
7Redémarrer les services liés : dnscache, NetlogonForcer une redécouverte des DC
8Auditer le pare‑feu : ports 88, 389/636, 53, 445, 135+RPC dyn.Débloquer la communication AD essentielle
9Exécuter les diagnostics AD : dcdiag /v, repadmin /replsummaryDéceler réplication ou SRV manquants

Connectivité réseau

Un simple ping -a <DC> confirme la résolution inverse ; un tracert dévoile un éventuel routage asymétrique. Sur des liaisons VPN site‑à‑site, inspectez la MTU ; des paquets fragmentés LDAP TCP 389 peuvent échouer alors que le ping passe.

Configuration DNS correcte

Sur un membre de domaine, l’UNIQUE serveur DNS configuré doit être un contrôleur de domaine (ou le serveur DNS interne auquel le DC délègue la zone AD). Évitez d’ajouter 8.8.8.8 ou 1.1.1.1 dans la carte réseau : créez plutôt un redirecteur DNS côté serveur pour la résolution internet.

Test des enregistrements SRV

Exemple de commande PowerShell :

Resolve-DnsName -Type SRV _kerberos._tcp.contoso.local

Aucun résultat ? Redémarrez Netlogon sur chaque DC ; le service republie instantanément les SRV _kerberos et _ldap.

Validation du canal sécurisé

Un nltest /sc_verify:<domaine> doit retourner Status = 0 0x0 NDIS _SUCCESS. En cas d’échec, réparez‑le par :

nltest /sc_reset:<domaine>
# ou PowerShell 7+
Test-ComputerSecureChannel -Repair -Verbose

Synchronisation temporelle

Kerberos rejette un ticket si le décalage dépasse 300 secondes. Sur un DC, assurez‑vous que la racine du domaine (PDC Emulator) pointe vers une source de temps fiable (NTP interne ou GPS). Sur un membre, fourniez simplement l’IP du DC dans w32tm /config /syncfromflags:DOMHIER.

Analyse des journaux

Filtrez le journal System sur Netlogon (EID 5719 = échec de session sécurisée) et LSA (EID 40960/40961 = défaillance d’authentification Kerberos). Le journal DNS Server affiche un EID 4000/4015 si le service ne peut pas charger la zone intégrée AD.

Redémarrage des services clefs

Pour obliger un membre de domaine à se réinscrire dans DNS :

Stop-Service dnscache,netlogon -Force
Start-Service netlogon
Start-Service dnscache

Inspection du pare‑feu

  • LDAP / TCP 389 : découverte AD et liens de confiance.
  • Kerberos / UDP 88 : authentification.
  • RPC : ouverture dynamique 49152‑65535 après appel de epmapper / TCP 135.

Un utilitaire tel que Test-NetConnection -Port 389 -ComputerName <DC> accélère la vérification.

Diagnostics avancés

Sur un DC, exécutez :

dcdiag /test:diag /v /f:c:\dcdiag.txt
repadmin /replsum
repadmin /showobjmeta <DC> <DN>

Ces rapports mettent en évidence un manque de réplication, un USN qui stagne ou un KRBTGT non renouvelé.

Bonnes pratiques DNS pour Active Directory

  • Sur un contrôleur de domaine, renseignez comme DNS primaire sa propre adresse IPv4, et comme DNS secondaire un autre DC du site.
  • Gravitez vos DC autour de la fonction DNSSEC si et seulement si l’intégralité de la forêt la supporte.
  • Placez les enregistrements PTR de chaque DC dans la zone reverse ; les opérations de réplication se fiabilisent.
  • Mettez en place une surveillance SCOM, Zabbix ou Prometheus sur _ldap._tcp et _kerberos._tcp.

Réinitialisation du canal sécurisé après restauration de VM

Une restauration « rapid clone » d’une machine virtuelle plus vieille que 30 jours peut engendrer un mismatch d’authentification. La stratégie ResetPasswordInterval, définie à 30 jours par défaut, force le changement du mot de passe machine ; si la VM restaurée possède un mot de passe obsolète, les paquets Kerberos échouent.

Exécutez sur la VM restaurée :

nltest /sc_change_pwd /domain:<domaine>

ou, plus simplement, Test-ComputerSecureChannel -Repair.

Réenregistrement des enregistrements SRV

  1. Redémarrez Netlogon sur chaque DC.
  2. Lancez ipconfig /registerdns sur tous les hôtes critiques.
  3. Vérifiez que les dossiers _tcp et _udp dans la zone _msdcs.<domaine> contiennent au moins un enregistrement pour chaque DC.
  4. Purgez les doublons avec dnscmd /EnumRecords puis /AgeAllRecords.

Scénarios spécifiques

Multi‑sites AD

Déclarez chaque sous‑réseau IP dans Sites et services Active Directory. Sinon, un serveur distant pourrait interroger un DC du siège via un lien WAN saturé et déclencher l’erreur.

Serveur qui est lui‑même DC

Veillez à ne jamais configurer un DNS externe dans la carte réseau d’un DC. Un seul paramètre incorrect suffit à supprimer les enregistrements SRV lors d’un redémarrage Netlogon.

Exigence de double pile IPv4/IPv6

Si l’IPv6 est activée dans l’ensemble de la forêt, désactivez‑la uniquement via la clé de registre DisabledComponents ; la décoche dans les propriétés de la carte peut entraîner une résolution d’adresses incomplète.

Prévention à long terme

  • Automatisez un test quotidien nltest /sc_query:<domaine> pour chaque membre dans un script de monitoring.
  • Programme : rapport hebdomadaire dcdiag /c + repadmin /replsum.
  • Documentez et validez vos pare‑feu à chaque changement d’architecture réseau ; conservez une matrice des ports AD.
  • Maintenez les DC à jour (correctifs cumulés Windows Server + mises à jour du schéma).
  • Évitez les snapshots prolongés sur les DC ; préférez la sauvegarde Azure Backup, Veeam ou DPM qui gèrent l’état SYSVOL.

Conclusion

Dans 90 % des cas, l’erreur « Naming Information Cannot Be Located » provient d’un DNS mal aiguillé ou d’un canal sécurisé rompu. En appliquant la séquence de vérifications précédente — réseau, DNS, SRV, canal sécurisé, horloge et pare‑feu — la liaison au domaine est restaurée sans réinstallation du serveur. Documentez chaque correctif et implémentez une surveillance proactive pour prévenir toute récidive.

Windows Server
Sommaire