¿Perdiste la “trust relationship” tras restaurar el único DC desde un backup de hace 159 días? Aquí tienes un procedimiento claro, de menos a más invasivo, para recuperar el canal seguro, restablecer Kerberos y devolver la confianza del dominio sin reinstalar equipos.
Contexto y síntoma
Escenario clásico: un entorno con un único controlador de dominio (DC) se restaura desde una copia de seguridad muy antigua. Desde ese momento, los equipos Windows no confían en el dominio: al iniciar sesión aparece el error “The trust relationship between this workstation and the primary domain failed”. En los clientes, Test-ComputerSecureChannel -Repair
falla; netdom resetpwd
“funciona” pero no resuelve; reiniciar cuentas de equipo en AD tampoco ayuda.
Causa técnica probable
Las cuentas de equipo (incluida la del DC) rotan su contraseña del canal seguro aproximadamente cada 30 días. Al volver el DC a un estado de hace 159 días, quedaron desincronizados los secretos que usan clientes y DC. A la desincronización de contraseñas se suelen sumar dos aceleradores del problema: hora y DNS incorrectos. Si el reloj difiere >5 minutos o el DNS no apunta al DC, Kerberos fracasa y el síntoma se multiplica.
Clave: la confianza se repara desde el cliente con su cuenta de equipo. netdom resetpwd
sirve para la cuenta del DC; no arregla por sí mismo a todos los clientes.
Checklist en el DC antes de tocar clientes
Arreglar clientes con un DC “tocado” solo traslada el problema. Asegura primero la salud del controlador de dominio restaurado:
Salud básica del DC
- Servicios AD DS, DNS, Netlogon en ejecución.
dcdiag
sin errores críticos ySYSVOL
/NETLOGON
compartidos (net share
debe listarlos).- Si usas DFSR para SYSVOL, servicio “DFS Replication” en estado Running y sin eventos de error recientes.
Hora y origen NTP
En un bosque con un solo DC, ese DC hace de PDC Emulator y debe ser la fuente de hora fiable para el dominio. Configúralo y fuerza la resincronización:
w32tm /config /reliable:yes /syncfromflags:manual /manualpeerlist:"<tuNTPexterno>"
w32tm /config /update
w32tm /resync /force
Comprueba también la zona horaria del DC y que los clientes puedan alcanzarlo por NTP (si procede) o que hereden la hora vía dominio.
DNS correcto
- El DC debe poder resolver su propia zona de AD y publicar los SRV requeridos.
- Si usas reenviadores externos, verifica que sean alcanzables.
- Registra de nuevo los registros dinámicos si hiciera falta:
ipconfig /registerdns
Recordatorio:netdom resetpwd
actualiza la contraseña de la cuenta del DC (ejecútalo en el DC cuando sea necesario). Para los clientes, usa Test-ComputerSecureChannel
, Reset-ComputerMachinePassword
, nltest
o netdom reset
.
Reparación en los clientes (ruta recomendada)
En cada equipo afectado, inicia sesión con el Administrador local (.\Administrador
) u otra cuenta local con privilegios. Procede así:
Asegura DNS y hora
- DNS del cliente → solo la IP del DC (no mezcles con DNS de ISP/routers).
- Vacía caché DNS y resincroniza hora:
ipconfig /flushdns w32tm /resync /rediscover
Repara el canal seguro con PowerShell
PowerShell es preferible por su verbosidad y control de errores:
$cred = Get-Credential 'DOMINIO\Administrador'
Test-ComputerSecureChannel -Server <DC> -Verbose
Test-ComputerSecureChannel -Repair -Server <DC> -Credential $cred
Si sigue fallando:
Reset-ComputerMachinePassword -Server <DC> -Credential $cred
Restart-Computer
Alternativas en CMD
nltest /sc_reset:<DOMINIO><DC>
nltest /scchangepwd:<DOMINIO>
netdom reset <NombreEquipo> /domain:<DOMINIO> /usero:<DOMINIO\Administrador> /passwordo:*
Si no se repara, salir y volver a unir
Cuando el secreto de la cuenta de equipo está irrecuperable, la vía fiable es salir del dominio y volver a unir:
$cred = Get-Credential 'DOMINIO\Administrador'
Remove-Computer -UnjoinDomainCredential $cred -PassThru -Verbose -Restart
Tras el reinicio:
Add-Computer -DomainName <DOMINIO> -Credential $cred -Restart
Con el mismo nombre de equipo y sin cambiar SID de máquina, el perfil de usuario de dominio suele reconectarse al reincorporar el equipo. Aun así, respalda datos críticos de usuario por si hubiera perfiles móviles o redirecciones de carpetas.
Matriz de diagnóstico rápido
Síntoma | Causa probable | Acción |
---|---|---|
“Trust relationship failed” al iniciar sesión | Contraseña de cuenta de equipo desincronizada | Test-ComputerSecureChannel -Repair o Reset-ComputerMachinePassword |
Test-ComputerSecureChannel falla inmediatamente | Hora o DNS incorrectos | Corregir NTP y apuntar DNS solo al DC |
GPO no aplica, SYSVOL no accesible | SYSVOL no compartido/DFSR detenido | Revisar servicio DFSR, compartir SYSVOL /NETLOGON , eventos |
netdom resetpwd “ok” pero clientes siguen rotos | Confusión de herramienta | Usar netdom reset en clientes o PowerShell |
Verificación de éxito
nltest /scquery:<DOMINIO>
devuelve “Trusted DC Connection Status Status = 0 0x0 NERRSuccess”.klist purge
y nuevo inicio de sesión obtiene TGT válido.gpupdate /force
aplica sin errores ygpresult /r
lista GPO de dominio.- Eventos limpios en System (Netlogon), Directory Service, DNS Server y DFS Replication.
Remediación masiva
Cuando hay decenas o cientos de equipos, automatiza. Tres enfoques típicos: script de inicio (GPO), Intune/Endpoint Manager o PowerShell Remoting.
Plantilla mínima por equipo
$ErrorActionPreference = 'Stop'
$log = "C:\Windows\Temp\fix-trust.log"
function Write-Log([string]$m){ $ts = (Get-Date).ToString("s"); "$ts`t$m" | Out-File -FilePath $log -Append -Encoding utf8 }
try {
Write-Log "Comprobando canal seguro..."
if (-not (Test-ComputerSecureChannel)) {
\$cred = New-Object System.Management.Automation.PSCredential("DOMINIO\Administrador", (ConvertTo-SecureString "PideLaClaveDeFormaSegura" -AsPlainText -Force))
try {
Write-Log "Intentando Reset-ComputerMachinePassword..."
Reset-ComputerMachinePassword -Server \<DC> -Credential \$cred
Write-Log "Reset OK. Reiniciando"
Restart-Computer -Force
} catch {
Write-Log "Fallo en reset. Desuniendo del dominio..."
Remove-Computer -UnjoinDomainCredential \$cred -Force -Restart
\# Al siguiente arranque, un script de inicio puede ejecutar Add-Computer
}
} else {
Write-Log "Canal seguro OK. Nada que hacer."
}
} catch {
Write-Log "Error inesperado: \$($\_.Exception.Message)"
} </code></pre>
<div class="note" style="border:1px solid #4fc1e9;background:#f5fbff;padding:12px;border-radius:6px;">
<strong>Sugerencia:</strong> divide el proceso en dos scripts: uno que <em>repara</em> y reinicia, y otro de <em>post-arranque</em> que reingresa al dominio solo si detecta que el equipo está en grupo de trabajo.
</div>
<h2>Escenarios especiales</h2>
<h3>La cuenta del DC también quedó desincronizada</h3>
<p>Si el propio DC muestra alertas de Netlogon sobre su canal seguro, ejecuta en el DC:</p>
<pre><code class="language-cmd">netdom resetpwd /Server:<DC> /UserD:<DOMINIO\Administrador> /PasswordD:*</code></pre>
<p>Luego reinicia Netlogon o el equipo si los eventos persisten.</p>
<h3>SYSVOL no se comparte tras la restauración</h3>
<p>Con un solo DC, si <code>SYSVOL</code>/<code>NETLOGON</code> no aparecen en <code>net share</code>, revisa DFSR, el estado de inicialización de SYSVOL y los eventos de “journal wrap”. Hasta que SYSVOL no esté funcional, las GPO no aplicarán aunque el canal seguro esté bien.</p>
<h3>Backup cercano a la <em>tombstone lifetime</em></h3>
<p>Si la copia es muy antigua (cercana o superior a la <em>tombstone lifetime</em> del bosque), evalúa cuidadosamente: podrían aparecer objetos obsoletos o inconsistencias. En casos extremos, contempla restauración autoritativa o incluso recuperación del bosque. Son operaciones de alto impacto que requieren ventana de mantenimiento y respaldo actual <em>antes</em> de ejecutarlas.</p>
<h3>Rotación de la clave KRBTGT</h3>
<p>Tras una restauración antigua, considera rotar la contraseña de la cuenta <strong>KRBTGT</strong> (dos rotaciones espaciadas) para invalidar TGT antiguos y reforzar la seguridad. Planifícalo para no interrumpir servicios que dependan de tickets de larga vida.</p>
<h2>Buenas prácticas y prevención</h2>
<ul>
<li><strong>Al menos dos DCs</strong> por dominio, ambos DNS/GC. Evita el punto único de falla.</li>
<li><strong>Backups probados</strong>: estado del sistema y SYSVOL verificados con simulacros de restauración periódicos.</li>
<li><strong>Supervisión de hora</strong> (NTP) y <strong>rotación de cuentas de equipo</strong> (eventos, alertas de Netlogon).</li>
<li><strong>DNS consistente</strong> en clientes: solo DC(s) como servidores DNS mientras se resuelve el incidente.</li>
<li><strong>Documenta</strong> el runbook de “trust relationship” con los comandos de este artículo para respuesta rápida.</li>
</ul>
<h2>Preguntas frecuentes</h2>
<p><strong>¿Por qué “reiniciar la cuenta de equipo en AD” no sirve?</strong><br>
Porque no cambia el secreto del <em>cliente</em>. El canal seguro es una contraseña compartida que debe regenerarse desde el equipo afectado o forzarse con los cmdlets mencionados.</p>
<p><strong>¿Puedo usar una cuenta de dominio distinta a Administrador?</strong><br>
Sí, cualquier cuenta con privilegios suficientes para cambiar contraseñas de cuentas de equipo y unir equipos al dominio.</p>
<p><strong>¿Pérdida de perfiles al salir y reingresar?</strong><br>
Si conservas el mismo nombre de equipo y reusas el objeto de equipo en AD, el perfil de dominio local suele enlazarse. Aun así, respalda datos críticos.</p>
<p><strong>¿Vale la pena intentar solo <code>nltest /sc_reset</code>?</strong><br>
Sí, es rápido y a veces suficiente. Si falla, pasa a <code>Reset-ComputerMachinePassword</code> y, como último recurso, desunir/reunir.</p>
<h2>Guía paso a paso consolidada</h2>
<ol>
<li><strong>En el DC</strong>: valida servicios (AD DS/DNS/Netlogon), comparte <code>SYSVOL</code>/<code>NETLOGON</code>, corrige NTP y DNS.</li>
<li><strong>En cada cliente</strong>: ajusta DNS (solo DC), resincroniza hora, ejecuta:
<pre><code class="language-powershell">$cred = Get-Credential 'DOMINIO\Administrador'
Test-ComputerSecureChannel -Repair -Server <DC> -Credential $cred
O bien:
Reset-ComputerMachinePassword -Server <DC> -Credential $cred
Restart-Computer
</code></pre>
</li>
<li><strong>Si falla</strong>: salir a grupo de trabajo y reingresar:
<pre><code class="language-powershell">Remove-Computer -UnjoinDomainCredential $cred -PassThru -Verbose -Restart
Luego
Add-Computer -DomainName <DOMINIO> -Credential $cred -Restart
Verifica: nltest /sc_query:<DOMINIO>
, klist
, gpupdate /force
, eventos limpios.
Estabiliza: plan de rotación de KRBTGT, agrega un segundo DC, revisa backups.
Errores comunes y cómo evitarlos
- Mezclar DNS (DC + ISP): rompe la localización de SRV y Kerberos. Corrige a solo DC.
- Confiar en
netdom resetpwd
para clientes: no lo arreglará; úsalo en el DC si su cuenta está mal. - Ignorar la hora: diferencias de >5 min invalidan tickets Kerberos aunque “todo lo demás” parezca bien.
- No revisar SYSVOL: sin SYSVOL, GPO y scripts de inicio fallarán incluso con confianza restablecida.
Comandos útiles de referencia
dcdiag /v
nltest /dsgetdc:<DOMINIO>
nltest /sc_query:<DOMINIO>
ipconfig /all
ipconfig /registerdns
w32tm /query /status
klist
gpupdate /force
gpresult /r
Casos de borde
- Equipos muy antiguos (muchos meses sin encender): suelen necesitar reset del canal seguro sí o sí.
- Servidores con servicios críticos: programa ventana y prueba
Reset-ComputerMachinePassword
primero; reingreso al dominio puede requerir reconfigurar permisos/grupos de servicio. - Entornos con BitLocker y protección TPM: reingreso no debería afectar, pero verifica políticas de recuperación y almacenamientos de claves.
Resumen ejecutivo
Tras restaurar un DC desde un backup de 159 días, los secretos de cuentas de equipo quedaron obsoletos. Antes de actuar sobre clientes, sanea el DC (servicios, NTP, DNS, SYSVOL). En clientes, repara el canal seguro con PowerShell; si no, reset y, como último recurso, desunir/reunir. Después, rota KRBTGT cuando proceda y evita reincidir desplegando un segundo DC y controlando hora/DNS.
Apéndice: ejemplo de script de inicio por GPO
Este script detecta y corrige el canal seguro durante el arranque. Sustituye <DOMINIO>, <DC> y gestiona las credenciales de forma segura (por ejemplo, usando un gMSA para operaciones remotas aprobadas o un mecanismo de inyección de credenciales que cumplas en tu organización).
# Script de inicio (GPO) - Fix Trust Relationship
$log = "C:\Windows\Temp\trustfix-startup.log"
function Log { param([string]$m) "$((Get-Date).ToString('s')) `t $m" | Out-File -FilePath $log -Append -Encoding utf8 }
try {
# Asegurar DNS al DC (opcional, si tu política lo permite)
# Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses "IP.DEL.DC"
Log "Probando canal seguro..."
if (-not (Test-ComputerSecureChannel)) {
Log "Canal inseguro; intentando reparación"
\# Credenciales: reemplaza por tu método corporativo de obtención segura
\$cred = New-Object System.Management.Automation.PSCredential("DOMINIO\Administrador", (ConvertTo-SecureString "PideLaClaveDeFormaSegura" -AsPlainText -Force))
try {
Reset-ComputerMachinePassword -Server \ -Credential \$cred
Log "Reparado; forzando reinicio"
Restart-Computer -Force
} catch {
Log "Fallo en Reset-ComputerMachinePassword: \$(\$*.Exception.Message)"
}
} else {
Log "Canal seguro OK"
}
} catch {
Log "Error: \$(\$*.Exception.Message)"
}
Apéndice: plan de contingencia del DC
- Si el DC restaurado no comparte SYSVOL, evalúa resembrado de SYSVOL.
- Si no hay forma de recuperar coherencia, considera forest recovery en ventana controlada.
- Tras estabilizar, promociona un segundo DC y valida replicación.
Con estos pasos, podrás recomponer la relación de confianza tras una restauración antigua, minimizando tiempos de indisponibilidad y protegiendo la integridad del dominio.