MENU
  1. Inicio
  2. Windows
  3. Windows Server
  4. Windows Server 2019: solución al error “We can’t sign you in because your domain isn’t available” y equipo que “se sale” del dominio

Windows Server 2019: solución al error “We can’t sign you in because your domain isn’t available” y equipo que “se sale” del dominio

Windows Server

¿Tu Windows Server 2019 en VMware muestra a veces “We can’t sign you in because your domain isn’t available” y tras reiniciar vuelve a funcionar? Este playbook te guía para diagnosticar sin reiniciar, recuperar el acceso y aplicar correcciones permanentes en Active Directory, DNS, Netlogon, tiempo y red.

Índice

Resumen de la pregunta

En una VM de Windows Server 2019 unida a dominio aparece intermitentemente, al iniciar sesión, el mensaje:

“We can’t sign you in with this credential because your domain isn’t available …”

Tras reiniciar, el inicio con las mismas credenciales vuelve a funcionar. El tiempo está sincronizado y otros servidores no presentan el problema. ¿Cómo corregirlo?

Respuesta y enfoque

La clave es no reiniciar para “tapar” el síntoma. Cuando ocurra, ejecuta el diagnóstico rápido que sigue, recupera el acceso de forma segura y aplica la corrección permanente en función de la causa raíz.

Diagnóstico rápido sin reiniciar

Probar inicio de sesión offline o local

  • Si puedes, entra con .\Administrator (cuenta local) o con una cuenta de dominio que haya iniciado sesión antes (usa credenciales en caché).
  • Si tampoco te deja, es posible que el caché de inicios de sesión esté deshabilitado por directiva.

Comprobar conectividad y descubrimiento de DC

ping <DC_FQDN>
nslookup -type=srv ldap.tcp.dc._msdcs.<tu-dominio.local>
nltest /dsgetdc:<tu-dominio.local>

Si falla alguno, hay problemas de red o DNS en ese host.

Verificar el canal seguro de la cuenta de equipo

nltest /sc_query:<tu-dominio.local>
Test-ComputerSecureChannel -Verbose

Si indica fallo, el canal seguro (trust) está roto o inestable.

Revisar eventos en la ventana del fallo

Abre el Visor de eventos (System y Security) y filtra por:

  • Netlogon: 5719, 5781
  • Kerberos: 4, 5, 7
  • LSA/SSPI: 40960, 40961
  • GroupPolicy: 1053, 1055, 1129
  • DNS Client: 1014
  • Security: 4768, 4771, 4625 (intentos y errores de autenticación)

Validar tiempo y Kerberos

w32tm /query /status
w32tm /stripchart /computer:<DC_FQDN> /samples:5 /dataonly

Aun si “parece bien”, confirma un desfase < 5 minutos respecto del DC.

Atajo seguro para recuperar sin reiniciar

Si solo necesitas volver a entrar mientras investigas:

Restart-Service Netlogon
klist purge
gpupdate /force

Si el canal seguro está roto, repara:

Test-ComputerSecureChannel -Repair -Credential DOMINIO\CuentaAdmin

Alternativa en consola:

netdom reset %COMPUTERNAME% /domain:<tu-dominio.local> /UserD:DOMINIO\CuentaAdmin /PasswordD:*

Mapa de síntomas a causa y acción

Síntoma visiblePrueba claveCausa probableAcción inmediata
No permite entrar con usuario que antes funcionabaInicio local OK, dominio NO; valor de cachéCredenciales en caché deshabilitadas y DC inaccesibleHabilitar caché; revisar conectividad DC
Errores intermitentes, cambia según DCnltest /sc_query falla a ratosCanal seguro inestable o replicación lentaReparar trust; validar dcdiag/repadmin
“Domain isn’t available” + DNS 1014SRV de AD no resuelveDNS del NIC mal configuradoUsar solo DNS de AD; registrar y limpiar caché
Solo tras arranque o cambio de redGroupPolicy 1129; perfil de red no es DominioRed/NLA tarda; GPO no espera redHabilitar “Always wait for the network…”
Falla desde cierto parcheEventos de Netlogon/KerberosEndurecimientos recientesRevisar compatibilidad y actualizar todos los DCs

Causas probables y correcciones permanentes

Caché de credenciales deshabilitado y DC momentáneamente no accesible

Síntoma: Mensaje “domain isn’t available” sin dejar entrar con cuentas que antes funcionaban. Tras reinicio (cuando el DC ya está disponible) vuelve a entrar.

Corrección: Habilita la caché de inicios de sesión.

  • GPO: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options → Interactive logon: Number of previous logons to cache → establece 10 (o cualquier > 0).
  • Registro (informativo): HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount.

Canal seguro del equipo roto o inestable

Síntoma: nltest /sc_query o Test-ComputerSecureChannel fallan, a veces depende del DC de destino; errores 5719, 40961, 1053.

Por qué pasa: Contraseña de la cuenta de equipo desincronizada (snapshots revertidos, VM suspendida largos periodos), replicación AD lenta, endurecimientos de Netlogon.

Corrección:

  • Repara: Test-ComputerSecureChannel -Repair o netdom reset.
  • En DCs: valida dcdiag y repadmin /replsummary; corrige replicación.
  • Evita reversiones de snapshot que devuelvan contraseñas antiguas del equipo.
  • Si nada funciona, quita y vuelve a unir al dominio (último recurso).

DNS mal configurado en el servidor

Buenas prácticas del NIC:

  • ÚNICOS DNS: direcciones de tus DCs de AD (IPv4/IPv6). Nunca pongas DNS públicos (8.8.8.8, etc.).
  • Sufijo DNS primario del dominio configurado correctamente.
  • Comprueba SRV de AD:
ipconfig /all
ipconfig /flushdns && ipconfig /registerdns
nslookup -type=srv ldap.tcp.dc._msdcs.<tu-dominio.local>

Red, NIC o capa VMware con intermitencias

Acciones:

  • Actualiza VMware Tools y el driver vmxnet3.
  • Desactiva ahorro de energía del adaptador virtual.
  • Para prueba, deshabilita temporalmente offloads y comprueba estabilidad:
# Solo para diagnóstico temporal
Disable-NetAdapterLso -Name "Ethernet"
Disable-NetAdapterChecksumOffload -Name "Ethernet"
  • Revisa VLAN/port-group, failover del vSwitch y cualquier microsegmentación o firewall entre la VM y los DCs.
  • Verifica puertos de AD abiertos: Kerberos 88, LDAP 389/636, SMB 445, RPC 135 + rango dinámico 49152–65535.
# Pruebas puntuales de puertos
Test-NetConnection -ComputerName <DC_FQDN> -Port 88
Test-NetConnection -ComputerName <DC_FQDN> -Port 389
Test-NetConnection -ComputerName <DC_FQDN> -Port 445

Orden de arranque, NLA y pertenencia a dominio en el inicio de sesión

  • Habilita la GPO Always wait for the network at computer startup and logon para evitar que el inicio proceda antes de que la red esté lista.
  • Comprueba que el perfil de firewall sea Domain (servicio NLA en Automático (inicio retrasado)).
  • Confirma con gpresult /r que se aplican GPOs de dominio.

Actualizaciones de seguridad de Kerberos y Netlogon

Aplica actualizaciones en DCs y miembros de dominio de forma consistente. Tras determinados parches, el canal seguro y la firma/sellado pueden requerir niveles que equipos desactualizados no cumplen. Si es tu caso, verás eventos de Netlogon o errores de Kerberos al autenticarse.

Procedimiento detallado paso a paso

Confirmar sitio de AD y DC preferido

nltest /dsgetsite
nltest /dclist:<tu-dominio.local>

Si la VM está asociada al sitio incorrecto (subred mal definida), puede contactar DCs remotos con mayor latencia. Corrige Active Directory Sites and Services para que la subred de la VM apunte al sitio correcto.

Validar el tiempo de dominio

En miembros de dominio, el origen de tiempo debe ser un DC (en última instancia el PDC Emulator). Evita la sincronización simultánea desde el hipervisor.

w32tm /query /source
w32tm /query /configuration
w32tm /resync /nowait

Si usabas sincronización de hora de VMware Tools en la VM, desactívala para miembros de dominio y deja que w32time gobierne.

Inspección de DNS en profundidad

Get-DnsClientServerAddress | ft -Auto
ipconfig /displaydns | more
nslookup <DC_FQDN>
nslookup -type=srv kerberos.tcp.<tu-dominio.local>

Asegúrate de que los registros A y SRV de los DCs resuelven y que dc._msdcs apunta a tus DCs activos.

Validación de GPO y perfil de red

gpresult /h C:\Temp\gp.html
gpupdate /force

Abre el informe y confirma que se aplican GPOs de dominio (indicará “Network Location: Domain”). Si aparece “Private/Public”, revisa firewall o detección de red.

Recuperación sin reinicio y verificación del canal seguro

Restart-Service Netlogon -Verbose
Test-ComputerSecureChannel -Verbose
Si falla:
Test-ComputerSecureChannel -Repair -Credential DOMINIO\CuentaAdmin

Tras reparar, fuerza actualización de políticas y vacía tickets Kerberos:

klist purge
gpupdate /force

Automatiza el diagnóstico en un script

Usa este script para capturar, en caliente, el estado del servidor cuando ocurra el fallo. Guarda la salida para comparación.

# Guardar como C:\Temp\Diag-AD.ps1 (ejecutar como admin)
$ts = Get-Date -Format "yyyyMMdd-HHmmss"
$log = "C:\Temp\AD-Diag-$ts.txt"
"=== Diagnóstico AD $ts ===" | Out-File $log
"Usuario: $env:USERNAME  Equipo: $env:COMPUTERNAME" | Out-File $log -Append

"--- Conectividad DC ---" | Out-File \$log -Append
\$domain = (Get-WmiObject Win32\_ComputerSystem).Domain
nltest /dsgetdc:\$domain | Out-File \$log -Append
ipconfig /all | Out-File \$log -Append

"--- Canal seguro ---" | Out-File \$log -Append
try { Test-ComputerSecureChannel -Verbose \*>&1 | Out-File \$log -Append } catch { $\_ | Out-File \$log -Append }

"--- Tiempo ---" | Out-File \$log -Append
w32tm /query /status | Out-File \$log -Append
w32tm /query /source | Out-File \$log -Append

"--- DNS SRV ---" | Out-File \$log -Append
nslookup -type=srv \ldap.\tcp.dc.\_msdcs.\$domain | Out-File \$log -Append

"--- Eventos recientes ---" | Out-File \$log -Append
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=(Get-Date).AddMinutes(-30)} |
Where-Object { $\_.Id -in 5719,5781,1053,1055,1129,1014 } |
Select-Object TimeCreated, Id, ProviderName, LevelDisplayName, Message |
Format-List | Out-File \$log -Append

"--- Fin ---" | Out-File \$log -Append
Write-Host "Archivo generado: \$log"

Endurecimiento y seguimiento para que no vuelva

  • Configura el NIC con solo DNS de AD (mínimo dos DCs).
  • Programa una tarea cada 5–10 min que ejecute nltest /sc_verify:<tu-dominio.local> y alerte si falla.
  • En DCs: ejecuta periódicamente dcdiag y repadmin /showrepl.
  • Revisa la asignación de Sites & Subnets para que la VM pertenezca al sitio correcto.
  • Mantén al día parches de Windows en DCs y miembros de dominio.

Cuándo volver a unir al dominio

Si Test-ComputerSecureChannel -Repair y netdom reset no recuperan el canal seguro, y tras descartar DNS/red/replicación, quita el equipo del dominio y vuelve a unirlo (con reinicio). Haz copia de SID del perfil local si es necesario, y revalida GPOs y pertenencia al sitio tras la unión.

Puertos y servicios que deben estar accesibles

ServicioProtocolo / PuertoUso
KerberosTCP/UDP 88Autenticación
LDAPTCP/UDP 389Consultas de directorio
LDAPSTCP 636LDAP sobre TLS
SMB/CIFSTCP 445Compartición, SYSVOL/NETLOGON
RPC Endpoint MapperTCP 135Asignación de RPC
RPC dinámicoTCP 49152–65535DCOM/RPC para políticas y más
DNSTCP/UDP 53Resolución de nombres y SRV
W32TimeUDP 123 (NTP)Sincronización de tiempo

Directivas útiles a revisar

Ruta de GPOAjusteValor recomendado
Computer Config → Windows Settings → Security Settings → Local Policies → Security OptionsInteractive logon: Number of previous logons to cache≥ 10
Computer Config → Policies → Administrative Templates → System → LogonAlways wait for the network at computer startup and logonEnabled
Computer Config → Policies → Administrative Templates → System → Group PolicyConfigure Group Policy slow link detectionDeshabilitar o ajustar umbral
Computer Config → Windows Settings → Security Settings → Windows Defender FirewallReglas que permitan puertos ADPermitir hacia/desde DCs

Buenas prácticas específicas en VMware

  • Usa adaptador vmxnet3 y mantén el driver actualizado.
  • Evita “revertir” snapshots en servidores unidos a dominio; si lo haces, repara el canal seguro inmediatamente.
  • No dependas de la sincronización de hora de VMware Tools en miembros de dominio; deja que w32time gobierne.
  • Si hay vMotion o cambios de host frecuentes, verifica que no perdés conectividad a DCs por filtros de red o ACLs dinámicas.

Preguntas frecuentes rápidas

¿Por qué reiniciar “arregla” el problema? Porque fuerza renegociación del canal seguro, renovación de tickets y descubridor de DC (DC Locator). Si el fallo es de conectividad/DNS intermitente, tras el reinicio puede tocar un DC accesible y parece “arreglado”.

¿Qué valor poner en la caché de inicios de sesión? Diez (10) es un punto de partida razonable. Evita 0 salvo que tu política de seguridad lo exija.

¿Reparar el canal seguro es seguro? Sí; Test-ComputerSecureChannel -Repair resetea la contraseña de la cuenta de equipo de forma segura con un DC. No afecta a usuarios ni servicios.

¿Puedo limitar puertos RPC dinámicos? Sí, para firewall estricto puedes acotar el rango RPC y permitirlo en ambos sentidos, pero requiere planeamiento y pruebas previas.

Conclusión

El patrón “falla de dominio” + “se arregla al reiniciar” apunta casi siempre a pérdida temporal de conectividad o descubrimiento de DC en ese host, agravado si el caché de inicios de sesión está deshabilitado, o a un canal seguro inestable. Con las medidas anteriores —caché habilitado, DNS correcto en el NIC, reparación del canal seguro, espera activa por la red en el arranque, y saneamiento de red/VMware— el problema suele resolverse de forma permanente.

Checklist final aplicable

  • NIC: solo DNS de AD; sufijo correcto.
  • DNS: SRV resuelven; ldap.tcp.dc._msdcs operativo.
  • Tiempo: desfase < 5 min; origen = DC.
  • Canal seguro: Test-ComputerSecureChannel OK.
  • GPO: caché de logons ≥ 10; “Always wait for the network…” habilitada.
  • Red: puertos AD abiertos; sin pérdidas ni alta latencia hacia DCs.
  • VMware: vmxnet3 + Tools actualizados; no revertir snapshots de miembros de dominio.
  • Monitoreo: tarea con nltest /sc_verify; filtro de eventos 5719/1129/1014.
Windows Server
Índice