Error “The trust relationship between this workstation and the primary domain failed”: causas y soluciones en Windows 10 y Windows Server

¿Usuarios que no pueden iniciar sesión, servidores que pierden la conexión con el dominio y un mensaje en pantalla indicando que “The trust relationship between this workstation and the primary domain failed”? Este fallo tiene cura rápida y, con unas cuantas buenas prácticas, puede evitarse para siempre.

Descripción del error

El mensaje aparece cuando Windows comprueba el canal seguro que mantiene con el Controlador de Dominio (DC). Cada equipo unido a dominio posee en Active Directory una cuenta de máquina con su propia contraseña, que se renueva automáticamente cada 30 días. Si esa contraseña deja de coincidir entre el cliente y el DC —por desfases de tiempo, copias antiguas, o errores de replicación— el canal se rompe y el inicio de sesión se bloquea.

Cómo reconocer el problema

• Error al iniciar sesión con cualquier cuenta de dominio, incluso con administradores.
• Eventos ID 5722 o ID 5805 en el registro System del DC.
• En el cliente, comandos como nltest /scquery:DOMINIO devuelven STATUSACCESS_DENIED.

Soluciones prácticas

Qué hacer	Dónde/Cómo	Cuándo usarlo
Restablecer la cuenta del equipo en Active Directory	En Active Directory Users and Computers → clic derecho en el equipo → Reset Account → reiniciar el PC.	Método más rápido si la cuenta aún existe en AD y se dispone de acceso al DC.
Reparar el canal seguro sin salir del dominio	# En el cliente o remoto Test-ComputerSecureChannel -Repair -Credential DOMINIO\Administrador O bien netdom resetpwd /server:DC /userd:DOMINIO\Administrador /passwordd:*	Ideal para automatización y grandes lotes de PCs. Evita des‑unir y volver a unir.
Salir y volver a unir el equipo al dominio	Cambiar a Workgroup → reiniciar → unir de nuevo → reiniciar.	Último recurso cuando los métodos anteriores fallan o la cuenta fue eliminada.

Paso a paso detallado

Restablecer la cuenta desde Active Directory

1. Inicia dsa.msc en un DC.
2. Localiza el objeto del equipo, botón derecho y selecciona Reset Account.
3. En el equipo afectado, reinicia. Durante el arranque negociará una nueva contraseña con el DC.
4. Comprueba el registro de sucesos del cliente; deben aparecer eventos ID 4742 (password set).

Reparar el canal con PowerShell (ideal para scripts)

1. Abre PowerShell con privilegios de administrador en el cliente o en un servidor de gestión.
2. Ejecuta:
   Test-ComputerSecureChannel -ComputerName PC01 -Repair -Credential DOMINIO\Administrador
3. Si devuelve True, el canal se reparó. Un reinicio no es obligatorio pero sí recomendable.
4. Para cientos de equipos:
   Get-ADComputer -Filter * | ForEach-Object { if (-not (Test-ComputerSecureChannel -ComputerName $_.Name)) { Test-ComputerSecureChannel -ComputerName $_.Name -Repair -Credential DOMINIO\Administrador } }

Des‑unir y volver a unir (hard reset)

1. Inicia sesión con la cuenta Administrador local.
2. Propiedades del sistema → Change → selecciona Workgroup (por ejemplo “TEMP”).
3. Reinicia y comprueba que el perfil local funciona.
4. Vuelve a unir al dominio con credenciales de administrador de dominio.
5. Reinicia de nuevo y verifica que los usuarios pueden iniciar sesión.

Causas frecuentes

• Desfase horario: si la diferencia con el DC supera 5 minutos, Kerberos falla.
• Contraseña de máquina desactualizada: ocurre tras restaurar snapshots, imágenes o al deshabilitar el cambio automático.
• Snapshots o checkpoints de máquinas virtuales revertidos a un estado antiguo.
• DNS mal configurado, firewalls bloqueando puertos LDAP/SMB (135, 389, 445).
• Controladores de red obsoletos que causan interrupciones en la conectividad.

Medidas preventivas

• Sincronización horaria uniforme: configura los DC como NTP clients apuntando a la misma fuente externa y deja que los equipos sigan la jerarquía AD.
  w32tm /config /syncfromflags:domhier /update
• Mantén habilitado el cambio automático de contraseña: la directiva “Domain member: Disable machine account password changes” debe estar en Not Defined o Disabled.
• Revisa “Maximum machine account password age” (30 días por defecto) y ajústalo solo en entornos con necesidades especiales.
• Auditoría mensual con PowerShell:
  Get-ADComputer -Filter * | ForEach-Object { Test-ComputerSecureChannel -ComputerName $_.Name -Verbose ` | Out-File C:\Logs\SecureChannelCheck.log -Append }
• Actualiza drivers y aplica parches a NICs y sistemas operativos para reducir desconexiones.

Automatización en entornos con 100 equipos o más

En redes medianas resulta inviable resolver equipo por equipo. Un enfoque escalable mezcla PowerShell Remoting y task scheduler.

1. Crea un fichero CSV con los equipos:
   NombrePC,OU
2. Lanza el siguiente script desde un servidor con WinRM habilitado:

Import-Csv C:\Inventario\pcs.csv |
  ForEach-Object {
      Invoke-Command -ComputerName $_.NombrePC -ScriptBlock {
          if (-not (Test-ComputerSecureChannel)) {
              Test-ComputerSecureChannel -Repair -Credential DOMINIO\Administrador
          }
      } -ErrorAction SilentlyContinue
  }

Consejos adicionales

• Programa la tarea durante la noche para no interrumpir sesiones.
• Registra los resultados en un share central; los equipos que fallen repetidamente suelen tener problemas de hardware o malware.
• Aplica GPOs de “Turn on PowerShell Transcription” para auditar los comandos ejecutados.

Buenas prácticas de infraestructura

Más allá del error concreto, reforzar la arquitectura de dominio mitiga otros incidentes de autenticación:

• Usa al menos dos DC por sitio y comprueba la replicación con repadmin /replsummary.
• Mantén los DC actualizados y apunta sus adaptadores DNS exclusivamente a otros DCs (nunca al loopback 127.0.0.1 en todas las entradas).
• Documenta y automatiza la creación de snapshots para que nunca superen el umbral de rotación de contraseñas.
• Integra monitorización (Nagios, Zabbix, PRTG) para alertas cuando aparezcan eventos 5722 o 5805.

Preguntas frecuentes

¿Puedo desactivar el cambio automático de contraseña?

Técnicamente sí, pero es una práctica desaconsejada que reduce la seguridad y hace que las contraseñas de máquina queden expuestas durante más tiempo.
¿Restablecer la cuenta borra SIDHistory o permisos?

No. “Reset Account” mantiene el SID, lo que cambia es la contraseña de la cuenta de máquina.
¿Qué ocurre con servidores críticos donde no puedo reiniciar?

La reparación del canal seguro con Test‑ComputerSecureChannel -Repair suele ser suficiente sin reinicio. No obstante, muchos administradores prefieren reiniciar para confirmar que Kerberos inicia limpio.

Conclusión

La pérdida de confianza entre un equipo y el dominio es un problema molesto pero con solución clara. Detectar la causa —casi siempre tiempo o contraseñas de máquina desalineadas— y aplicar uno de los tres métodos descritos devuelve la productividad en minutos. Con sincronización NTP, políticas adecuadas y auditoría periódica, es posible que nunca vuelvas a ver este error.