Cuando un servidor Windows arroja el mensaje «Naming Information Cannot Be Located», la funcionalidad de Active Directory (AD) y los servicios que dependen de él quedan en riesgo inmediato. A continuación encontrarás un procedimiento exhaustivo —técnico pero accesible— para diagnosticar y resolver la incidencia, minimizando el tiempo de inactividad y reduciendo el riesgo de recurrencia.
Causas habituales del mensaje «Naming Information Cannot Be Located»
El error indica que el servidor no puede localizar los datos de nomenclatura del directorio, normalmente debido a que:
- La resolución DNS falla o devuelve datos obsoletos.
- Existe un aislamiento de red (interfaces, ruteo, VLAN, firewall).
- El canal seguro de la cuenta de equipo se ha roto.
- Hay un desfase horario superior a 5 min entre el equipo y el DC.
- Los servicios clave (Netlogon, Cliente DNS) se corrompen o permanecen en estado no operativo.
- Problemas internos en los DC: replicación, zonas DNS integradas en AD, o sobrecarga de recursos.
Paso a paso para la remediación
Comprobar la conectividad de red
Antes de profundizar en AD, confirma que la pila de red funciona:
- Inspecciona cables, puertos del switch y luces de enlace.
- Ejecución rápida:
ping <IP_DC> tracert <IP_DC> Get-NetIPAddress Get-NetRoute -DestinationPrefix <subred_DC>El objetivo es identificar latencias anómalas, pérdidas de paquetes o rutas inexistentes. - Verifica que no existan NIC teaming o configuraciones de ruteo estático que envíen el tráfico por la interfaz equivocada.
Revisar la configuración DNS
Active Directory se apoya de forma crítica en DNS. Un cambio de IP en un DC que no se replique en los registros SRV disparará este error.
- Apunta siempre los adaptadores del servidor a los DC como servidores DNS preferido y alternativo. Evita 8.8.8.8 u otros públicos en el adaptador principal.
- Renueva la cache local:
ipconfig /flushdns ipconfig /registerdns - Comprueba que el servicio DNS del DC responde:
nslookup server <IP_DC> ldap.tcp.dc._msdcs.<dominio> - Revisa la zona
_msdcs. Si faltan SRV, recréalos o fuerza el registro connetdiag /fixodcdiag /fix.
Validar la relación con Active Directory
La cuenta de equipo mantiene un canal seguro con el DC. Si los hashes se descuadran, la autenticación Kerberos fallará y el error aparecerá.
- Ejecuta:
nltest /sc_verify:<dominio>Un resultado STATUSACCESSDENIED sugiere que el canal seguro está roto. - Para restablecerlo sin salir del dominio:
netdom reset <servidor> /domain:<dominio> - Sincroniza la hora inmediatamente:
w32tm /config /syncfromflags:domhier /update w32tm /resync /nowait - Verifica que el servidor aparezca en la OU Computers o en la OU prevista; de lo contrario, muévelo y replica.
Analizar los registros de eventos
Los visores de eventos son la «caja negra» que narra qué ha sucedido:
- En Registro de Windows → Sistema filtra por origenes Netlogon, DNS Client Events, Kerberos.
- En Registro de Windows → Servicio de directorio revisa avisos de replicación y errores de base de datos Jet.
- Anota códigos de evento frecuentes:
5719Netlogon: No se estableció sesión de confianza.4000/4007DNS: Fallo al registrar el host.5KDC: Hora de reloj fuera de tolerancia.
Probar la resolución de nombres
Un solo registro SRV extraviado basta para inutilizar el descubrimiento de DC.
- Verifica SRV esenciales:
Resolve-DnsName ldap.tcp.dc._msdcs.<dominio> -Type SRV Resolve-DnsName kerberos.tcp.dc._msdcs.<dominio> -Type SRV - Asegúrate de que cada DC devuelva su FQDN correcto y la IP esperada en el registro A.
- Comprueba también alias CNAME de los DC si existen nombres «amigables» (ej. dc01).
Reiniciar servicios clave
Los servicios de red se comportan como «traductores». Un dato corrupto en caché puede perpetuar el error aunque el problema original haya sido corregido.
- Purga la caché DNS local:
Stop-Service -Name dnscache Start-Service -Name dnscache - Restablece Netlogon:
Stop-Service -Name Netlogon Start-Service -Name Netlogon - Alternativamente, reinicia sólo la pila TCP/IP:
netsh int ip reset Restart-Computer
Verificar reglas de firewall
El filtrado suele pasar desapercibido en entornos con equipos multi-sede o DMZ. Asegúrate de que los puertos requeridos estén abiertos.
| Puerto | Protocolo | Servicio |
|---|---|---|
| 53 | TCP/UDP | DNS |
| 88 | TCP/UDP | Kerberos |
| 135 | TCP | RPC Endpoint Mapper |
| 389 | TCP/UDP | LDAP |
| 445 | TCP | SMB (SysVol, Netlogon) |
| 464 | TCP/UDP | Kpasswd |
| 636 | TCP | LDAPS |
| 3268/3269 | TCP | GC/GCSSL |
| 49152–65535 | TCP | RPC Dinámico |
En servidores Windows Firewall, un Group Policy con reglas restringidas puede exigir excepciones adicionales. En dispositivos externos, valida ACL y política de inspección de protocolos.
Ejecutar diagnósticos avanzados y escalar
Si el servidor ya parece sano pero el aviso persiste, busca problemas en los controladores de dominio:
dcdiag /v /c /d /e /fixdesde un DC: muestra carencias de servicios y arregla registros DNS básicos.repadmin /replsum: detecta DCs que no reciben cambios.repadmin /showrepl *: averigua qué socios de replicación están caídos.- Emplea Active Directory Sites and Services para revisar puentes de sitio y costes incorrectos.
- Si no hay errores en el bosque, revisa la carga de CPU/RAM en los DC y el espacio en disco de la base NTDS.dit.
Cuando las pruebas advierten de corrupción de base de datos o replicación detenida, eleva el caso al equipo de infraestructura o soporte Microsoft. Aporta archivos *.evtx, reportes de dcdiag y capturas de repadmin.
Buenas prácticas para prevenir reapariciones
- Implementa monitorización proactiva (SCOM, Zabbix, Nagios) sobre los contadores de DNS, Netlogon y Kerberos.
- Automatiza backups de System State de los DC y verifica su restauración en laboratorio.
- Centraliza reglas de firewall mediante GPOs y revísalas tras cada cambio de seguridad.
- Configura NIC teaming sólo cuando sea necesario; la complejidad añade puntos de fallo.
- Aplica actualizaciones de Windows Server con regularidad para corregir vulnerabilidades de Kerberos y mejoras en el cliente DNS.
- Documenta las zonas de sitio y subred en Active Directory Sites and Services, especialmente en entornos con múltiples WAN.
Conclusión
El mensaje «Naming Information Cannot Be Located» rara vez responde a un único desencadenante; suele ser la colisión de varios factores: DNS inconsistente, sincronización horaria deficiente, canales seguros rotos o filtrado de puertos. Aplicando la metodología descrita —comenzando por la conectividad física y ascendiendo hasta la lógica de Active Directory— restablecerás la resolución de nombres y la autenticación de manera sistemática y repetible. Mantén una disciplina de supervisión continua y documentación actualizada para impedir que la incidencia reaparezca, garantizando la estabilidad del dominio y la disponibilidad de los servicios dependientes.