Cuando un servidor Windows que reside en un dominio B intenta atender la conexión de un usuario o equipo del dominio A y la autenticación falla con el código STATUSNOLOGON_SERVERS (0xC000005E), el administrador suele preguntarse qué controlador de dominio (DC) faltó en la ecuación. ¿Fue el DC del propio servidor o el DC del usuario externo? La respuesta, y la manera de resolver el incidente, pasa por comprender a fondo el flujo de autenticación entre dominios, validar cada dependencia de red y aplicar un método de diagnóstico disciplinado. En esta guía encontrarás todo lo necesario para identificar la causa, aplicar una solución rápida y, lo más importante, evitar que el problema vuelva a repetirse.

¿Qué significa STATUSNOLOGON_SERVERS?

El valor 0xC000005E corresponde al error STATUSNOLOGON_SERVERS y se genera cuando el componente de autenticación (Netlogon/Kerberos) no puede encontrar ningún DC válido capaz de procesar la solicitud. La ausencia de un DC puede producirse por:

• Fallo de red o desconexión total con el DC.
• DNS que no resuelve los registros SRV ni los nombres de los DC.
• Puertos de autenticación filtrados (Kerberos, LDAP, RPC dinámico, etc.).
• Controladores en estado offline, saturados o con replicación detenida.

Aunque el servidor y el cliente pertenecen a dominios distintos, el primer paso de localización de DC siempre se realiza en el dominio del servidor. Solo después de confirmar que la cuenta no existe en su propio directorio, el DC de ese dominio usa la relación de confianza para consultar al DC del dominio del usuario. Por eso, si el servidor no consigue llegar a su DC, jamás llegará a interrogar al DC remoto y el error se disparará de inmediato.

Flujo normal de autenticación en relaciones de confianza

Para seguir el rastro de la solicitud conviene tener presentes estas etapas cronológicas:

1. Localización del DC local. El componente Netlogon del servidor busca en DNS los registros SRV ldap.tcp.dc._msdcs.dominioB.
2. Contacto inicial por LDAP/Kerberos. Tras resolver una (o varias) direcciones IP, el servidor inicia la negociación con el DC local.
3. Búsqueda de la cuenta. Si la cuenta pertenece a un dominio de confianza, el DC local determina la ruta de salida válida.
4. Encadenado de confianza. El DC del dominio B actúa como Security Account Manager (SAM) Referral, reenvía la petición al DC del dominio A y espera la respuesta.
5. Devolución del ticket Kerberos. Si todo es correcto, el servidor recibe el TGT, el usuario queda autenticado y la conexión continúa.

Un solo fallo en cualquiera de los dos primeros pasos (resolución de DC o comunicación con ese DC) provoca STATUSNOLOGON_SERVERS y, en consecuencia, detiene el resto de la cadena.

Por qué aparece el error: causas frecuentes

Los laboratorios de soporte de Microsoft documentan cientos de escenarios, pero los más habituales se agrupan en estas categorías:

• Problemas de DNS: zonas fragmentadas, registros SRV faltantes o round‑robin que apunta a DC fuera de servicio.
• Filtros de cortafuegos: reglas nuevas que bloquean los puertos 88, 389, 445, 135 o el rango RPC dinámico 49152‑65535.
• Pérdida de sincronización horaria: más de 5 minutos de diferencia rompe Kerberos.
• Replica estancada: objetos de confianza sin actualizar provocan fallos de prefix delegation.
• Controladores sobrecargados: CPU al 100 % o volúmenes SYSVOL sin espacio libre.

Diagnóstico paso a paso

Validar conectividad de red

Ejecuta ping y tracert hacia cada DC local y remoto. Un salto inesperado, una latencia anómala o cualquier pérdida de paquetes justificarán investigar la capa 3.

Comprobar resolución DNS y registros SRV

En el servidor afectado:

nltest /dsgetdc:dominioB
nltest /dsgetdc:dominioA
nslookup -type=SRV ldap.tcp.dc._msdcs.dominioB

El comando debe devolver al menos un DC válido por dominio. Si la salida es vacía o muestra servidores caídos, repara la zona o forzar una actualización dinámica.

Verificar puertos y cortafuegos

El siguiente cuadro resume los puertos imprescindibles entre el servidor, su DC y, si procede, los DC del dominio de confianza:

Puerto	Protocolo	Servicio	Dirección recomendada
88	TCP/UDP	Kerberos	Bidireccional
135	TCP	RPC Endpoint Mapper	Bidireccional
389	TCP/UDP	LDAP	Bidireccional
445	TCP	SMB/CIFS	Bidireccional
636	TCP	LDAPS	Bidireccional
3268/3269	TCP	Global Catalog	Bidireccional
49152‑65535	TCP	RPC dinámico	Bidireccional

Revisar salud de los controladores de dominio

Desde cualquier DC:

repadmin /replsummary
dcdiag /v
eventvwr.msc  (filtros Netlogon 5719, Directory‑Service, DNS‑Server)

Una réplica fallida o errores continuos 5719/5783 en Netlogon confirman la imposibilidad de servicio. Repara la replicación antes de continuar.

Auditar la relación de confianza

En Active Directory Domains and Trusts lanza la acción Validate. Si devuelve Failed o Access Denied, ejecuta:

netdom trust dominioA /domain:dominioB /verify
netdom trust dominioA /domain:dominioB /reset

Esto renueva la contraseña de la confianza y purga referencias antiguas.

Sincronización de hora y Kerberos

Desajustes superiores a cinco minutos provocan errores de tipo KRBAPERR_SKEW. Garantiza que w32time apunta a una raíz NTP fiable y que ambos dominios usan una fuente común o encadenada.

Soluciones rápidas y temporales

• Reiniciar Netlogon: sc stop netlogon && sc start netlogon. Fuerza la rediscovery de DC y renueva la caché SRV.
• Limpiar registros DNS: borra manualmente los registros huérfanos o usa dnscmd /enumrecords combinado con /ageallrecords.
• Acceso de emergencia por host file: si el problema es puramente DNS, añade temporalmente “DC_IP dcN.dominioB.local” en %systemroot%\system32\drivers\etc\hosts.
• Forzar replicación inmediata: repadmin /syncall /AdeP para propagar los últimos cambios.

Buenas prácticas para prevenir futuros incidentes

• Configura Sites & Services para que cada subred apunte al sitio físico correcto. Evitarás consultas a DC remotos innecesarias.
• Monitorea con Azure Monitor, SCOM u otra plataforma que alerte ante errores 5719 en Netlogon y 4015 en DNS.
• Revisa los backups de estado del sistema de todos los DC y practica recuperaciones periódicas.
• Establece políticas de cambio que auditen reglas de firewall antes de entrar en producción.
• Asegura sincronización horaria escalonada: PDC Emulator <‑> NTP externo <‑> resto de DC <‑> servidores miembro.

Preguntas frecuentes

¿El error puede deberse a licencias de CAL caducadas?
No. Las licencias de acceso no intervienen en la localización de DC.

¿Influye el nivel funcional del dominio?
Solo si usas AES o RC4 para Kerberos y tu DC más antiguo no soporta el cifrado. En ese caso, el DC rechazará el ticket y verás eventos 4771.

¿Qué diferencia hay entre STATUSNOLOGONSERVERS y STATUSNOTRUSTSAM_ACCOUNT?
El primero indica ausencia de DC; el segundo apunta a una cuenta de confianza rota. Ambos pueden aparecer juntos cuando la replicación es deficiente.

¿Puedo deshabilitar el firewall para probar?
Como prueba puntual sí, pero documenta la acción y vuelve a habilitarlo enseguida. Mejor captura con PortQry o Wireshark para identificar el puerto exacto.

Conclusión

El error STATUSNOLOGON_SERVERS no es caprichoso: señala inequívocamente que algún controlador de dominio vital para la autenticación está fuera de alcance, sea del dominio local o del dominio de confianza. La única forma fiable de erradicarlo es seguir un proceso ordenado —verificar red, DNS, puertos, salud de DC y confianza— hasta detectar el eslabón roto. Una vez restaurado, reinicia Netlogon o el propio servidor para vaciar cachés y garantizar un camino limpio. Si documentas cada hallazgo y aplicas las buenas prácticas descritas, convertirás un incidente repetitivo en una anomalía residual y fácilmente contenible.