Error de confianza de dominio en Windows Server (0xC000018B): causas, reparación sin rejoin y prevención definitiva

Si al iniciar sesión aparece “The security database on the server does not have a computer account for this workstation trust relationship”, lo más probable es que el canal seguro con el dominio se haya roto. Aquí tienes cómo identificar la causa raíz, reparar sin desunir del dominio y evitar que vuelva a ocurrir.

Índice

Resumen del caso real

En una máquina virtual con Windows Server 2016 Standard, cada pocos días surge el error de confianza de dominio al iniciar sesión. Para “salir del paso” se había estado desuniendo y volviendo a unir al dominio. Ya se probaron sin éxito: sincronía de hora con el DC, búsqueda de SPN duplicados, corrección de fallos de gpupdate, reseteo de la cuenta de equipo en AD, reseteo de la contraseña de equipo con netdom, quitar/añadir el objeto en la OU, limpiar/registrar DNS y cambios vía ADSIEdit. Solo ocurre en esa VM. En el Visor de eventos aparece Audit Failure con Security ID = NULL SID y Status = 0xC000018B.

Qué significa el código y el síntoma

  • 0xC000018B = STATUSNOTRUSTSAMACCOUNT: el canal seguro (secure channel) entre el equipo y el dominio está roto. El equipo no puede autenticarse ante un DC con la contraseña de su cuenta de equipo.
  • El error recurrente en una VM apunta a reversiones de estado (snapshots/restore) o clones que compiten por la misma cuenta de equipo y van sobrescribiendo su contraseña en AD.
  • El evento con NULL SID indica que el equipo no llegó a establecer identidad válida en la fase de establecimiento de sesión.

Corrección rápida (sin desunir/reunir del dominio)

Ejecuta en la VM afectada con credenciales de dominio con permisos para restablecer contraseñas de cuentas de equipo:

# Comprobar canal seguro
Test-ComputerSecureChannel -Verbose

Repararlo

Test-ComputerSecureChannel -Repair -Credential DOMINIO\CuentaAdmin

Alternativas equivalentes

Reset-ComputerMachinePassword -Server DC01 -Credential DOMINIO\CuentaAdmin
nltest /sc\_verify\:DOMINIO
nltest /sc\_reset\:DOMINIO\DC01
netdom resetpwd /server\:DC01 /userd\:DOMINIO\CuentaAdmin /passwordd:\* 

Luego:

  • gpupdate /force
  • Reiniciar el servicio Netlogon o reiniciar la VM.
  • Confirmar en el Visor de eventos que ya no aparece el error.

Nota: volver a unir al dominio funciona, pero es innecesario y más disruptivo; basta con reparar el canal seguro.

Por qué se rompe el canal seguro (explicación clara)

Cada equipo miembro de un dominio tiene una cuenta de equipo en Active Directory con una contraseña aleatoria que el propio equipo cambia de forma periódica (por defecto, alrededor de cada 30 días). Esta contraseña se guarda en el equipo (LSA Secrets) y en AD. Cuando una VM se revierte a un snapshot o se restaura desde un backup antiguo, el equipo recupera una contraseña antigua que ya no coincide con la que AD considera vigente. También se rompe cuando dos equipos con el mismo nombre (original y clon) usan la misma cuenta de equipo y “se pisan” la contraseña en AD.

Procedimiento detallado paso a paso

  1. Valida hora y conectividad
    • Comprueba hora/fecha/zona (w32tm /query /status) y que la VM solo use los DNS de los DCs.
    • Verifica puertos hacia los DCs: RPC (135 + dinámicos), Kerberos (88/464), LDAP (389/636), SMB (445), DNS (53), NTP (123).
  2. Comprueba rápido el canal con Test-ComputerSecureChannel o nltest /sc_verify:DOMINIO.
  3. Repara el canal con PowerShell: Test-ComputerSecureChannel -Repair -Credential DOMINIO\CuentaAdmin o bien: Reset-ComputerMachinePassword -Server DC01 -Credential DOMINIO\CuentaAdmin Si tu sitio usa RODC, apunta a un DC escribible con el parámetro -Server.
  4. Refresca directivas y servicios: gpupdate /force Restart-Service Netlogon -Force
  5. Verifica: nltest /sc_query:DOMINIO Test-ComputerSecureChannel
  6. Corrobora en el DC que no se generen eventos 5723/5805 después de la reparación.

Prevención: cómo evitar que vuelva a romperse

Snapshots, backups y clones

  • Elimina snapshots antiguos o evita revertir la VM a un punto previo tras cambiar la contraseña de la cuenta de equipo.
  • Si tu herramienta de backup verifica restauraciones arrancando clones, hazlo en red aislada o con nombre distinto. Un clon con el mismo hostname actualizará la contraseña de la cuenta de equipo en AD y dejará a producción “huérfana”.
  • Evita discos no persistentes o políticas de “descartar cambios al apagar”.
  • Para plantillas, usa Sysprep y precrea cuentas de equipo si aplica; no arranques dos máquinas con el mismo nombre en la red de producción.

Políticas de contraseña de cuenta de equipo

  • Revisa la GPO: Miembros del dominio: Edad máxima de la contraseña de la cuenta de equipo (≈30 días por defecto). Evita valores demasiado bajos.
  • En el registro del equipo (HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters):
    • DisablePasswordChange → debe ser 0 o no existir.
    • MaximumPasswordAge → mantenlo en un valor razonable (p. ej., 30).
  • No desactives permanentemente el cambio de contraseña del equipo salvo casos muy controlados.

Salud de AD, DNS y conectividad

  • En un DC: repadmin /replsummary y dcdiag /v para descartar replicación deficiente.
  • Revisa eventos 5723/5805 en el DC alrededor del fallo.
  • Asegura que la VM solo usa DNS de los DCs y no hay bloqueos de puertos (RPC/Kerberos/SMB).
  • Valida SPNs del equipo: setspn -Q */NOMBRE-EQUIPO (busca duplicados).

Comprobación proactiva (opcional)

Crea una tarea programada que alerte si el canal seguro falla:

if (-not (Test-ComputerSecureChannel)) { Exit 1 } else { Exit 0 }

Tablas útiles

Comandos de verificación y reparación

ComandoUsoCuándo usar
Test-ComputerSecureChannelComprueba si el canal seguro está OK (True/False).Diagnóstico inicial y post-reparación.
Test-ComputerSecureChannel -RepairResetea la contraseña de la cuenta de equipo desde el equipo.Solución rápida sin salir del dominio.
Reset-ComputerMachinePassword -Server DCEquivalente en PowerShell; permite apuntar a DC escribible específico.Entornos con RODC o replicación lenta.
nltest /scquery /scverify /sc_resetConsulta, verifica y restablece relación con el DC.Escenarios con herramientas clásicas o scripts heredados.
netdom resetpwdResetea contraseña de equipo desde línea de comandos.Servidores sin PowerShell avanzado o por preferencia.

Claves de registro relacionadas

ClaveValor recomendadoEfecto
HKLM\...\Netlogon\Parameters\DisablePasswordChange0 (o no presente)Permite rotar la contraseña de la cuenta de equipo.
HKLM\...\Netlogon\Parameters\MaximumPasswordAge30Días máximos antes de forzar cambio de contraseña.

Puertos necesarios (desde el miembro hacia los DCs)

ProtocoloPuertoPropósito
Kerberos88 (TCP/UDP), 464Autenticación y cambio de contraseñas.
LDAP/LDAPS389/636Consultas a AD.
SMB445Acceso a SYSVOL/NETLOGON.
RPC135 + dinámicosNetlogon, DCOM, servicios de dominio.
DNS53Resolución de nombres.
NTP123Sincronización de hora.

Checklist de diagnóstico rápido

  • ¿Hay snapshots o restores recientes? ¿Backups que inicien un clon con el mismo hostname?
  • ¿La VM vuelve “mágicamente” a un estado anterior tras reinicios? (discos no persistentes).
  • ¿La GPO de edad de contraseña de la cuenta de equipo está alterada para esa OU?
  • ¿El DC muestra problemas de replicación (latencia) o conectividad intermitente?
  • ¿Existen SPNs duplicados o un objeto de equipo duplicado con el mismo nombre?
  • ¿La VM usa únicamente DNS de los DCs?

Errores comunes y cómo evitarlos

  • Solución “rejoin” constante: volver a unir al dominio “funciona”, pero es más lento, rompe perfiles, reinserta el equipo en la OU por defecto y no ataca la causa. Prefiere repair.
  • Confiar en un RODC para reparar: apunta a un DC escribible cuando restableces la contraseña del equipo.
  • Desactivar cambios de contraseña del equipo: puede “parchear” ambientes con snapshots, pero reduce seguridad y empeora a largo plazo.
  • Usar DNS externos: provoca fallos intermitentes (DC no localizado, Kerberos roto). Usa solo DNS de los DCs.

Automatización: script de autoreparación con registro en eventos

Para servidores “sin ventana de mantenimiento”, puedes crear una tarea que verifique y repare el canal seguro, dejando huella en el registro de eventos:

$source = 'TrustRepair'
$log    = 'Application'
if (-not [System.Diagnostics.EventLog]::SourceExists($source)) {
  New-EventLog -LogName $log -Source $source
}
try {
  if (-not (Test-ComputerSecureChannel)) {
    Write-EventLog -LogName $log -Source $source -EntryType Warning -EventId 1000 -Message 'Canal seguro roto; intentando reparación...'
    $cred = Get-Credential 'DOMINIO\CuentaAdmin'
    Test-ComputerSecureChannel -Repair -Credential $cred | Out-Null
    Restart-Service Netlogon -Force
    gpupdate /force | Out-Null
    if (Test-ComputerSecureChannel) {
      Write-EventLog -LogName $log -Source $source -EntryType Information -EventId 1001 -Message 'Reparación del canal seguro exitosa.'
    } else {
      Write-EventLog -LogName $log -Source $source -EntryType Error -EventId 1002 -Message 'La reparación no fue exitosa.'
    }
  }
} catch {
  Write-EventLog -LogName $log -Source $source -EntryType Error -EventId 1003 -Message "Excepción en reparación: $($_.Exception.Message)"
}

Apéndice: eventos relevantes en DCs y miembros

  • DC (Netlogon)
    • 5723/5805: la sesión desde el equipo X falló al autenticarse con estado 0xC000018B.
    • 5719: no se pudo establecer sesión con un DC (suele indicar red/DNS).
  • Miembro
    • Auditoría de Logon con Security ID = NULL SID y estado 0xC000018B.
    • Errores de Netlogon al iniciar servicios dependientes de autenticación de dominio.

Cómo funcionan las contraseñas de cuentas de equipo (en breve)

  • El servicio Netlogon rota la contraseña de la cuenta de equipo automáticamente (~30 días por defecto).
  • AD conserva la contraseña actual y la anterior para tolerar replicación.
  • Si el equipo “retrocede en el tiempo” (snapshot/restore) más allá de esa ventanita, la contraseña ya no coincide y el canal se rompe.
  • Dos máquinas con el mismo nombre compiten por la misma cuenta en AD; la última en cambiar la contraseña deja a la otra fuera.

Cuándo sí conviene “rejoin”

Situación¿Repair basta?¿Rejoin recomendado?Notas
Cuenta de equipo eliminada en ADNoRecrear la cuenta o unir de nuevo a la OU correcta.
Renombraste el equipo y/o cambiaste dominioNo siempreSincroniza SPNs y objetos; considera netdom renamecomputer.
Objetos duplicados o corrupción de metadatosDependePosibleSoluciona duplicados de SPN/objeto y reune si persiste.
Simple desalineación por snapshotNoUsa repair; corrige el proceso de snapshots.

Buenas prácticas en entornos virtualizados

  • Evita checkpoints persistentes en producción. Si necesitas “freeze” para mantenimiento, elimina el snapshot al finalizar.
  • En pruebas de restauración, opera los clones en VLAN aislada o con nombre temporal.
  • Incluye en tu runbook una verificación de Test-ComputerSecureChannel tras restaurar servidores de aplicaciones sensibles.

Guía de solución condensada

  1. Confirma el síntoma: error de confianza + 0xC000018B / NULL SID.
  2. Comprueba DNS, hora y puertos a DCs.
  3. Ejecuta Test-ComputerSecureChannel -Repair (o equivalentes).
  4. gpupdate /force y reinicia Netlogon.
  5. Elimina la causa raíz: snapshots/clones/plantillas mal usadas, GPO agresivas, DNS erróneo.

Conclusión

Este error es un canal seguro roto. En VMs, la causa más común es un snapshot/backup/clon que revierte o compite por la contraseña de la cuenta de equipo. Soluciona al instante con los comandos de reparación y elimina la causa raíz (snapshots/clones en red de producción, discos no persistentes o GPOs agresivas). Así deja de repetirse.


Comandos clave (lista rápida)

# Diagnóstico
Test-ComputerSecureChannel -Verbose
nltest /sc_query:DOMINIO
nltest /dsgetdc:DOMINIO

Reparación

Test-ComputerSecureChannel -Repair -Credential DOMINIO\CuentaAdmin
Reset-ComputerMachinePassword -Server DC01 -Credential DOMINIO\CuentaAdmin
nltest /sc\_reset\:DOMINIO\DC01
netdom resetpwd /server\:DC01 /userd\:DOMINIO\CuentaAdmin /passwordd:\*

Post-acción

gpupdate /force
Restart-Service Netlogon -Force 
Índice