Netlogon no inicia en Controlador de Dominio: guía completa de reparación en Windows Server

Cuando el servicio Netlogon se niega a arrancar en un Controlador de Dominio (DC) de Windows Server, las consolas de Active Directory se vuelven inaccesibles y cadenas de fallos en cascada (W32Time, autenticación Kerberos, replicación SYSVOL, entre otras) dejan a toda la infraestructura al borde del colapso. Este artículo profundiza en las causas, el procedimiento de diagnóstico y las soluciones probadas —desde comprobaciones rápidas hasta restauraciones de bajo nivel— para devolver la salud al dominio sin reinstalar el sistema ni degradar el DC.

Índice

Por qué Netlogon es crítico en un entorno de dominio

Netlogon actúa como el “portero” de Active Directory. Su responsabilidad principal es establecer y mantener el canal seguro (secure channel) entre los equipos cliente/servidor y el DC. Además:

Registra los controladores de dominio en DNS usando registros SRV.
Facilita la autenticación NTLM y Kerberos.
Sincroniza la hora a través de Windows Time (clave para evitar tickets Kerberos caducados).
Publica y mantiene los recursos compartidos SYSVOL y NETLOGON.

Cuando Netlogon no arranca, el dominio sigue existiendo, pero los clientes se quedan sin la “puerta de entrada” para autenticarse, las políticas de grupo dejan de aplicarse y la replicación de los DC se interrumpe. El impacto puede ir desde inicios de sesión lentos hasta la imposibilidad total de acceder a servidores y aplicaciones corporativas.

Síntomas típicos de un Netlogon detenido

Error al abrir dsa.msc (Active Directory Users and Computers) y demás herramientas RSAT.
Eventos ID 5719, 5781, 5807 en el registro del sistema.
Servidores miembros que no encuentran un DC disponible.
Fallo de políticas de grupo (gpupdate /force queda en “processing…”).
No se comparten SYSVOL y NETLOGON (net share los muestra ausentes).

Tabla resumen de los pasos de corrección

Paso	Acciones clave	Objetivo
Verificar estado del servicio	`sc query netlogon` o services.msc	Confirmar si está detenido o en pausa
Revisar el Visor de eventos	“System” / “Application”; foco en errores Netlogon y ID 6011	Descubrir causas de fallo o cambio de nombre
Validar configuración de red	Comprobar que el DNS primario apunte al propio DC	Evitar fallos de localización de SRV
Comprobar seguridad y firewall	Desactivar antivirus / firewall temporalmente	Descartar bloqueos de puertos RPC/SMB
Iniciar servicio con privilegios	Tipo de inicio Automático y pulsar “Iniciar”	Garantizar arranque tras reinicios
Usar comandos correctos	`net start netlogon` (sin “‑force”)	Evitar sintaxis errónea
Diagnóstico avanzado	`dcdiag /v`, `nltest /sc_verify:DOMINIO`	Detectar corrupción de AD o del canal seguro
Restaurar o recrear Netlogon	`sfc /scannow`, `sc delete → sc create`	Reparar instalación dañada

Guía paso a paso detallada

Verificar el estado del servicio y dependencias

Ejecuta:

sc query netlogon
sc qc netlogon

Confirma que el tipo de inicio sea “Auto” o “Auto (Delayed)” y que los servicios dependientes (LanmanServer, LanmanWorkstation, entre otros) estén activos. Si Netlogon aparece como “STOPPED” y un intento manual falla con ERROR 1068 (dependencia), comprueba primero W32Time y Remote Procedure Call.

Analizar el Visor de eventos en busca de ID 6011

El ID 6011 señala que el nombre de equipo o de dominio cambió en el registro (HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters). Esto rompe el canal seguro y Netlogon se rehúsa a iniciar. Si ves “WORKGROUP” en lugar del FQDN esperado, estás ante la causa raíz.

Corregir la configuración de red y DNS

En un DC, nunca uses DNS de proveedores públicos (8.8.8.8, 1.1.1.1) en el adaptador principal.
Para entornos con varios DC, lista primero su propia IP y después la de un partner replicado.
Reinicia el servicio DNS o limpia la caché con ipconfig /flushdns.

Descartar bloqueos de seguridad

Los AV corporativos suelen activar módulos de “Self‑Defense” que impiden la creación de procesos hijo (svchost) o la apertura de puertos RPC / SMB. Deshabilita temporalmente el antivirus y prueba iniciar Netlogon. No olvides excluir las rutas %systemroot%\NTDS, %systemroot%\SYSVOL y %systemroot%\System32.

Reiniciar Netlogon con comandos correctos

Existe la creencia de usar -force con net start. Ese parámetro nunca ha existido; cualquier documento que lo sugiera está desactualizado. El comando correcto es:

net stop netlogon
net start netlogon

Diagnóstico avanzado con DCDIAG, NLTEST y NETDIAG

dcdiag /e /c /v /f:dcdiag.txt
nltest /sc_verify:DOMINIO
nltest /dclist:DOMINIO
netdiag /v

Revisa los archivos de salida para detectar:

Fallo de registros SRV en DNS.
Inconsistencias de replicación (“Access denied syncing MachineAccount”).
Errores de Trust con otros dominios o bosques (Error 1789).

Restablecer el canal seguro sin reiniciar el servidor

Si el DC sigue unido al dominio pero Netlogon no inicia, bastará con restablecer su secret:

nltest /sc_reset:DOMINIO\NombreDC$

Esto fuerza la renegociación de la contraseña del canal seguro y se refleja en los eventos ID 5712 (éxito).

Recrear Netlogon como último recurso

Úsalo únicamente si los binarios se dañaron (corrupción en disco, malware, fallo de actualización):

sc delete netlogon
sfc /scannow
dism /online /cleanup-image /restorehealth
sc create netlogon binPath= "%SystemRoot%\system32\lsass.exe" type= share start= auto

Termina reiniciando el servidor y ejecutando dcdiag /fix para re‑registrar los SRV.

Caso práctico: cambio de dominio a WORKGROUP

En el incidente que motivó este artículo, el Visor de eventos mostró múltiples ID 6011. Al inspeccionar el registro, Domain apuntaba a “WORKGROUP”. Tras revertir la clave a “midominio.local” y reiniciar, Netlogon inició con normalidad, SYSVOL volvió a compartirse y el reloj se sincronizó. Ninguna GPO necesitó reprocesarse manualmente; bastó un gpupdate /force.

Buenas prácticas para prevenir futuras incidencias

Mantén backups periódicos de System State; te dan la opción de restaurar Autoritativamente SYSVOL.
Deshabilita la opción “Permitir que los clientes cambien la contraseña del canal seguro” salvo que sea estrictamente necesario.
Implementa monitorización con Event Subscriptions o SIEM para detectar IDs 5719, 5807 y 6011 en tiempo real.
Documenta los cambios de red: nuevos segmentos, VLANs y routers pueden bloquear puertos 135, 137‑139, 445 y 389/636.
Tras aplicar parches de seguridad, comprueba siempre los servicios críticos (Netlogon, Kerberos, KDC, W32Time).

Preguntas frecuentes

¿Qué pasa si degrado y promo de nuevo el DC?

Es funcional, pero conlleva la pérdida de objetos exclusivos (certificados emitidos, secretos de AAD Connect, etc.). Agotar primero todos los pasos de reparación de Netlogon es menos intrusivo.

¿Puedo cambiar la IP del DC sin afectar Netlogon?

Sí, pero requiere:

Actualizar los registros A y SRV en DNS.
Forzar un ipconfig /registerdns.
Reiniciar Netlogon y verificar dcdiag /test:RegisterInDns.

¿Sustituye Kerberos por completo a Netlogon?

No. Kerberos usa TCP/UDP 88 y 464, pero necesita que Netlogon publique los DC en DNS y mantenga sincronizado el reloj; además, NTLM v2 y ciertos procesos de legacy dependen explícitamente de Netlogon.

Conclusión

Un fallo de Netlogon puede parecer terminal, pero con un enfoque ordenado —revisión de eventos, chequeo de DNS, verificación del canal seguro y corrección del registro— la mayoría de los incidentes se resuelven sin reinstalar Windows Server ni degradar el rol de DC. Conservar respaldos de System State y practicar auditorías periódicas son las mejores defensas para garantizar la resiliencia de Active Directory.