Problema

En entornos con varios controladores de dominio (DC) y servidores que usan RDP, es frecuente encontrarse con credenciales “invalidas” al conectar por nombre de host, mientras que la misma conexión por dirección IP funciona sin problemas. El síntoma típico es la aparición intermitente del evento 37 en los logs del DC:

Ticket PAC constructed by: <DC> Client: <DOMAIN>\<DC>$ Ticket for: krbtgt

Este evento indica que el Ticket Granting Ticket (TGT) no pudo ser validado correctamente entre DCs. Cuando la falla ocurre en un cruce de sitio (Site A → Site B), la autenticación Kerberos se rompe y RDP recurre a NTLM, que a su vez rechaza las credenciales si la política de seguridad lo impide. El problema se vuelve crítico porque afecta a cualquier servicio que dependa de Kerberos: DFS, SMB, PowerShell remoting, etc.

Causa

El error 37 tiene varias causas habituales que se combinan con frecuencia en despliegues híbridos de Windows Server 2022 y 2025:

  1. Desincronización de relojes
    Kerberos requiere que la diferencia horaria entre todos los miembros sea < 5 min. En sitios con VPN sin NAT, los servidores pueden usar fuentes NTP distintas y generar desfases que provocan la invalidación del TGT.

  2. Replicación de SYSVOL/NTDS incompleta
    El ticket PAC incluye los atributos de la cuenta krbtgt. Si la réplica de la cuenta o de sus atributos (por ejemplo, msDS-KeyVersionNumber) está corrupta o desactualizada en algún DC, ese DC generará tickets que otros no pueden validar.

  3. Versión de la clave krbtgt desalineada
    Cada vez que se restablece la contraseña de krbtgt, se crea una nueva versión de clave. Si algún DC sigue usando la versión anterior (por ejemplo, por caché de Kerberos o por un servicio que no se reinició), los tickets firmados con la versión antigua serán rechazados.

  4. Configuración de compatibilidad de Kerberos
    Los controladores de dominio 2025 pueden estar configurados para usar la plantilla de certificado Kerberos con compatibilidad Server2016/Windows10. Si algunos DC todavía tienen la plantilla “Domain Controller” antigua, el proceso de firma de tickets puede fallar al cruzar sitios.

  5. Rutas de red y latencia
    En VPN de sitio‑a‑sitio, los paquetes de Kerberos pueden perderse o retrasarse lo suficiente como para que el DC receptor considere expirado el ticket. La pérdida se refleja como evento 37.

Solución

Una estrategia robusta aborda todas las áreas anteriores, sin depender de un único paso. El siguiente flujo funciona en la mayoría de los entornos con Windows Server 2022/2025 y dominios funcionales 2016 o superiores.

1. Verificar sincronización horaria

  • Asegúrate de que todos DC, servidores y estaciones cliente usen la misma fuente NTP (preferiblemente el propio DC PDC Emulator).
  • Ejecuta en cada máquina:
w32tm /query /status
  • Corrige desviaciones mayores a 5 min con:
w32tm /config /manualpeerlist:"ntp1.example.com ntp2.example.com" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /nowait

2. Confirmar salud de la replicación

  • Usa repadmin para detectar fallos de SYSVOL y NTDS:
repadmin /replsummary
repadmin /showrepl * /verbose /all
  • Si aparecen errores de “access denied” o “out‑of‑sync”, ejecuta una replicación forzada:
repadmin /syncall /AdeP
  • Revisa que el objeto krbtgt tenga la misma msDS-KeyVersionNumber en todos los DC:
repadmin /showobjmeta "CN=krbtgt,CN=Users,DC=example,DC=com"

3. Rotar la contraseña de krbtgt con doble paso

Una rotación simple (una sola vez) deja versiones de clave en algunos DC y genera el error 37. El procedimiento recomendado es doble rotación:

# Paso 1: Cambiar la contraseña
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "TempPass123!" -Force)
# Forzar replicación
repadmin /syncall /AdeP
# Esperar al menos 24 h (o hasta que todos los DC hayan actualizado sus cachés)
Start-Sleep -Seconds 86400

# Paso 2: Cambiar a la contraseña final
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "FinalPass456!" -Force)
repadmin /syncall /AdeP
  • Después de la segunda rotación, reinicia los servicios Kerberos en cada DC:
net stop kdc && net start kdc

4. Uniformizar la plantilla de certificado Kerberos

  • En la CA interna, elimina cualquier plantilla “Domain Controller” marcada como superseded y asegúrate de que todos DC tengan asignada la plantilla Kerberos Authentication con compatibilidad Server2016/Windows10.
  • Ejecuta en cada DC:
certutil -pulse
  • Verifica que el certificado tenga la extensión KDC Authentication y que su cadena de confianza sea válida.

5. Optimizar la VPN y la latencia

  • Habilita IPsec entre los sitios para evitar que los paquetes Kerberos sean fragmentados o descartados por firewalls.
  • Configura la VPN para que no haga inspección profunda de paquetes UDP 88 (Kerberos).
  • Si la latencia supera los 150 ms, considera crear un DC adicional en el sitio remoto para evitar cruces de sitio en la autenticación inicial.

6. Limpiar cachés de Kerberos

En servidores que siguen fallando después de los pasos anteriores, purga la caché local:

klist purge
klist tickets

Reinicia los servicios que dependen de Kerberos (RDP, LSASS) o, en caso de duda, reinicia el servidor.

Cuándo aplicar esta solución

  • Síntomas: RDP por nombre devuelve “invalid credentials”, eventos 37 en los DC, fallos intermitentes de autenticación Kerberos entre sitios, tickets TGT que no se validan.
  • Entorno: Múltiples DC (2022/2025), dominio funcional 2016+, VPN de sitio‑a‑sitio sin NAT, políticas de seguridad que bloquean NTLM.
  • No aplica: Si el problema es exclusivamente NTLM (evento 4625 con código 0xC000006D) o si la falla ocurre solo en clientes Windows 10 sin dominio, la causa suele ser distinta (política de contraseñas, caché de credenciales).

Código

# 1. Verificar y corregir sincronización horaria
w32tm /query /status
w32tm /config /manualpeerlist:"ntp1.example.com ntp2.example.com" /syncfromflags:manual /reliable:yes /update
net stop w32time && net start w32time
w32tm /resync /nowait

# 2. Chequear replicación y versión de krbtgt
repadmin /replsummary
repadmin /showobjmeta "CN=krbtgt,CN=Users,DC=example,DC=com"

# 3. Rotación doble de la contraseña krbtgt
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "TempPass123!" -Force)
repadmin /syncall /AdeP
Start-Sleep -Seconds 86400
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString -AsPlainText "FinalPass456!" -Force)
repadmin /syncall /AdeP
net stop kdc && net start kdc

# 4. Forzar renovación de certificados Kerberos
certutil -pulse
klist purge

Verificación

  1. Evento 37: Después de aplicar los pasos, abre el Visor de eventos en cada DC y filtra por Kerberos‑Key‑Distribution‑Center → Event ID 37. No debería aparecer en los últimos 24 h.
  2. RDP por nombre: Desde un cliente en Site A, conecta a servername.siteb.example.com usando RDP. La autenticación debe completarse sin solicitar credenciales adicionales.
  3. Ticket válido: Ejecuta klist en el cliente después de iniciar sesión. Deberías ver un TGT con Ticket flags = 0x0 y una hora de expiración acorde a la política de dominio.
  4. Replicación: repadmin /replsummary debe reportar 0 % de fallos y Success en todos los DC.

Notas adicionales

  • En entornos con más de dos sitios, es recomendable tener al menos un DC local por sitio; de lo contrario, cada cruce de sitio implica una petición de TGT a un DC remoto, aumentando la probabilidad de error 37.
  • Si la VPN está basada en IPsec, verifica que los puertos UDP 88 y TCP 88 estén permitidos en ambos extremos; algunos firewalls los bloquean por defecto.
  • Después de la rotación de krbtgt, los controladores que ejecutan versiones de Windows Server anteriores a 2012 pueden requerir un reinicio para limpiar la caché de claves.
  • Mantén siempre una copia de seguridad del objeto krbtgt antes de cambiar la contraseña; en caso de error crítico, puedes restaurar el objeto desde AD recycle bin.