Cuando un equipo Windows pierde la capacidad de autenticarse contra su dominio de Active Directory, la productividad se detiene de inmediato. Los mensajes “There is no logon server available…” y “The security database on the server does not have a computer account for this workstation trust relationship” indican que el canal seguro Kerberos entre el PC y el controlador de dominio se ha roto. A continuación encontrarás una guía completa —probada en entornos Windows 10/11 y Windows Server 2016 en adelante— para restablecer la relación de confianza, entender el motivo de la avería y aplicar medidas preventivas.
Cómo y por qué se rompe el canal seguro
Durante el proceso de unión al dominio, el equipo crea un objeto de cuenta de equipo en Active Directory y negocia una contraseña interna de 128 caracteres que se renueva, por defecto, cada 30 días. Si por cualquier causa el DC y el equipo ya no coinciden en esa contraseña, Kerberos rechaza los tickets y lanza los errores anteriores.
- Desfase de hora: Kerberos requiere que la diferencia de reloj sea < 5 min.
- Restauración de snapshots: volver a un estado anterior invalida la contraseña guardada en el PC.
- Cambios de nombre o de SID: modificar el nombre del equipo sin actualizar AD rompe la vinculación.
- Contraseña caducada y equipo apagado: si el PC estaba fuera de línea cuando tocaba el cambio, no recibió la contraseña nueva.
Método recomendado: salir y volver a unir el equipo al dominio
Este proceso garantiza un clean slate creando una contraseña de canal segura nueva y fresca:
- Inicia sesión con la cuenta local de administrador
Desconecta temporalmente el cable de red o deshabilita la NIC. Así evitas que el equipo siga enviando autenticaciones fallidas al DC y bloquee cuentas. - Cambia a un grupo de trabajo
Ve a Panel de control → Sistema → Cambiar configuración → Cambiar, seleccionaWorkgroup, asigna un nombre temporal (p. ej.WORKGROUP) y reinicia. - Reinicia y entra de nuevo con la cuenta local
El equipo ya no intentará autenticarse frente a AD; todos los recursos de red seguirán inaccesibles, lo cual es normal. - Vuelve a unir el equipo al dominio
Repite la ruta anterior, marcaDomain, introduce el FQDN (contoso.local) y credenciales de un administrador de dominio.
Tras el mensaje “Welcome to the domain”, reinicia de nuevo. - Valida que el inicio de sesión funciona
Conéctate con un usuario de dominio y comprueba que recibe su perfil sin errores.
Comprobaciones post‑unión (impiden recurrencias)
| Paso | Acción | Propósito |
|---|---|---|
| Sincronizar hora | w32tm /resync o validar que el reloj difiere < 5 min del DC. | Evita rechazos de Kerberos. |
| Verificar conectividad y DNS | ping DCFQDN, nslookup ldap.tcp.dc.msdcs, dcdiag /test:dns. | Aísla fallos de red o resolución. |
| Resetear la cuenta de equipo en AD (opcional) | En Active Directory Users and Computers haz clic derecho → Reset. | Limpia contraseñas y atributos corruptos. |
| Reparar canal seguro sin desunir (alternativa) | Test-ComputerSecureChannel -Repair -Credential (Get-Credential)o netdom reset <PC> /domain:<dominio> | Solución rápida cuando la cuenta aún existe en AD. |
Alternativa express con PowerShell: reparar sin salir del dominio
Si la cuenta de equipo sigue presente y no hubo cambios de nombre, abrir una consola local elevada (PowerShell 7+ preferible) basta para regenerar la contraseña:
Solicita credenciales de un administrador de dominio
$cred = Get-Credential
Test-ComputerSecureChannel -Repair -Credential $cred
En segundos verás True. Reinicia y comprueba el inicio de sesión. Este método salva políticas de grupo y perfiles, por lo que es ideal cuando tienes muchos equipos afectados.
Diagnóstico profundo: eventos, logs y comandos clave
- Visor de eventos → Sistema – ID 5722, 5719 y 3210 apuntan a fallos Kerberos y de canal seguro.
nltest /scverify:dominio– Confirma si el canal esOKoACCESSDENIED.netdom verify %COMPUTERNAME%– Mismo objetivo quenltestcon sintaxis más legible.Get-ADComputer -Identity PC -Properties PasswordLastSet– Comprueba la fecha de cambio de contraseña en AD.repadmin /replsummary– Descarta que el problema venga de replicación entre DCs.
Buenas prácticas para prevenir que se rompa la confianza
- Política de tiempo de contraseña: mantén los 30 días por defecto o reduce a 14 días en portátiles propensos a largos periodos fuera de la oficina.
- NTP robusto: apunta todos los DCs a la misma referencia (GPS, reloj atómico, etc.) y usa
w32tm /monitorpara auditar desviaciones. - Backups con conciencia de dominio: evita restaurar snapshots de DCs o de equipos unidos sin previa limpieza de metadatos.
- Deshabilita la caducidad automática en laboratorios: en VMs que se clonan a menudo,
registry: HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DisablePasswordChange=1 (DWORD). - Automatiza la reparación: scripts con
Test-ComputerSecureChannelonetdom resetvía Intune, ConfigMgr o políticas de inicio.
Preguntas frecuentes
¿Puedo cambiar el nombre del equipo y unirlo en un solo paso?
Sí. Desde la misma ventana de “Propiedades de sistema” puedes introducir nombre nuevo y dominio de una sola vez. Sin embargo, AD creará un nuevo objeto; planifica la migración de perfiles si procede.
Tras reparar, las GPO no se aplican. ¿Por qué?
Ejecuta gpresult /r o rsop.msc; el problema suele ser el DFS Namespace o políticas huérfanas que se corrompieron cuando el canal estaba roto. Forzar gpupdate /force suele bastar.
¿El comando netdom trust sirve en este caso?
No. netdom trust gestiona relaciones entre dominios/árboles. Lo que necesitas es netdom reset o netdom resetpwd para la contraseña de la workstation trust.
¿Cómo actuar si hay cientos de equipos afectados?
Distribuye un script que ejecute Test-ComputerSecureChannel -Repair durante el próximo inicio. Puedes desencadenarlo con una tarea programada que se autodestruya tras devolver True. En entornos híbridos, Intune Remediation es tu aliado.
¿Puedo evitar reiniciar?
La nueva contraseña se almacena en LSA y NetLogon; hasta que ambos servicios no reinicien, el ticket TGT seguirá usando credenciales antiguas. Por tanto, reiniciar es la vía más segura y soportada.
Conclusiones
Restaurar la relación de confianza es un procedimiento directo siempre que domines tres pilares: nombre de equipo invariable, reloj sincronizado y cuenta de equipo con contraseña vigente. Mantén scripts de reparación listos, supervisa la salud de tus DCs y habilita alertas de evento 5719/5722 para actuar antes de que los usuarios noten el problema.