Cómo solucionar un error de Escritorio remoto causado por una falta de coincidencia de fecha o hora

Me encontré con ese molesto error al intentar conectarme vía RDP a un servidor remoto en el dominio de AD. El mensaje «Escritorio remoto no puede verificar la identidad» debido a una discrepancia de fecha o hora es bastante común, pero resulta un poco extraño porque a veces los relojes sí son correctos. Básicamente, Windows lo muestra porque la autenticación Kerberos necesita una sincronización perfecta, y si los relojes tienen una diferencia de más de 5 minutos, la situación se vuelve alarmante. Sin embargo, en algunos casos, aunque todo parecía sincronizado, sigue apareciendo el error. Es una de esas situaciones en las que hay que volver a comprobarlo todo para estar seguro.

El principal problema es la sincronización horaria, especialmente si se administran servidores mediante ILO o consolas remotas. Incluso si la hora parece correcta visualmente, vale la pena revisar la configuración de sincronización. A veces, en una máquina virtual, el hipervisor puede interferir con la sincronización horaria del host, o el servidor remoto puede presentar alguna desviación. Es mejor verificar con comandos o herramientas nativas.

Cómo solucionar errores de autenticación y tiempo de RDP

Comprobar y sincronizar la hora manualmente en el servidor remoto

Esto ayuda si la hora está desincronizada, aunque sea un poco. El comando es sencillo y funciona en la mayoría de los servidores Windows:

net time \\remote-ip-or-hostname

En algunos sistemas, este comando podría estar obsoleto, pero sigue siendo una comprobación rápida. Si no está sincronizado, realice una sincronización manual configurando el servicio de hora. A continuación, se muestra lo que debe ejecutarse en una ventana de administración de PowerShell:

w32tm /config /manualpeerlist:"your.ntp.server" /syncfromflags:manual net stop w32time net start w32time w32tm /resync

Reemplace your.ntp.server con la IP o el nombre de host de su servidor NTP de red. Espere a que se sincronice el reloj, con suerte solucionando la discrepancia. Tenga en cuenta que a veces es necesario reiniciar o intentarlo un par de veces, especialmente si el servicio de hora no responde correctamente.

Otro punto: si el servidor remoto es una máquina virtual, compruebe que su hipervisor no esté forzando su propia sincronización horaria. Las máquinas virtuales suelen intentar sincronizar la hora con el host, lo que puede causar discrepancias extrañas si no se configura correctamente. Deshabilite la sincronización horaria en la configuración de la máquina virtual si es necesario o configúrela para que dependa únicamente de fuentes NTP.

Verificar la configuración de DNS y red

Dado que la resolución DNS también puede interferir con Kerberos, asegúrese de que la configuración DNS del servidor sea correcta. Use este comando cerca de la consola del servidor:

nslookup some_server_name DNS_Server_IP

Si el DNS no se resuelve correctamente, podría estar causando problemas con los tickets de Kerberos o fallos de autenticación. Cambie los servidores DNS si es necesario o solucione los problemas de respuesta del DNS. Porque, claro, a veces Windows tiene que complicarlo más de lo necesario.

Si hay varios adaptadores de red, compruebe que la tabla de enrutamiento no esté dirigiendo el tráfico DNS a través de la interfaz incorrecta. Utilice la función de impresión de rutas para ver qué adaptador se utiliza para las direcciones IP DNS. Garantizar un enrutamiento correcto ayuda a mantener la coherencia de los flujos de seguridad y autenticación.

Utilice la dirección IP en lugar del FQDN para RDP

Esto es un truco, pero si todo lo demás falla, conéctese directamente por IP en lugar del nombre de dominio completo.¿Por qué? Porque Kerberos se basa en DNS y relaciones de confianza de dominio. Al usar IP, se omite Kerberos por completo, lo que simplifica mucho el proceso de autenticación. No siempre es una solución a largo plazo, pero en configuraciones complejas, podría ayudar a conectarse y verificar si el problema está relacionado exclusivamente con Kerberos.

Comprobar las relaciones de confianza con Active Directory

Ejecute este comando de PowerShell para ver si la relación de confianza de la computadora sigue siendo válida:

Test-ComputerSecureChannel

Si devuelve True, la confianza es correcta. De lo contrario, podrías tener que repararla. El comando que debes probar es:

Test-ComputerSecureChannel -Repair -Credential domain\admin_user

Reemplace domain\admin_user con una cuenta administrativa con permisos en el dominio. A veces, esto falla con un error que indica que el servidor no está operativo, lo que indica problemas de comunicación con el controlador de dominio o problemas en el puerto de red. En estos casos, compruebe que los puertos TCP/UDP 88, 389 y demás estén abiertos y disponibles. Es posible que necesite herramientas como PortQry para realizar pruebas.

Asegúrese de que la configuración de la capa de seguridad RDP sea coherente

A veces, la falta de coincidencia de la capa de seguridad provoca fallos en el protocolo de enlace. Puede verificarlo o configurarlo en el Editor de directivas de grupo, en Configuración del equipo > Plantillas administrativas > Componentes de Windows > Servicios de Escritorio remoto > Host de sesión de Escritorio remoto > Seguridad. Busque Requerir el uso de una capa de seguridad específica para conexiones remotas (RDP) y configúrelo con opciones menos seguras, como la capa de seguridad RDP o SSL (TLS 1.0).Como alternativa, modifique el registro directamente en:

HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SecurityLayer

Establezca el valor en 1 o 0 para diferentes modos de seguridad. Tenga en cuenta que reducir la configuración de seguridad no siempre es ideal, pero ayuda a solucionar problemas si el protocolo de enlace falla debido a incompatibilidades de protocolo.

Por último, tenga en cuenta que los cambios recientes en CredSSP también pueden causar problemas. Si las actualizaciones afectaron el protocolo, podría ser necesario ajustar las políticas o actualizar los clientes y servidores según corresponda. Ese es otro tema completamente diferente.

En resumen, solucionar problemas de tiempo de RDP o Kerberos es una combinación de verificación de relojes, DNS, relaciones de confianza y configuración de seguridad. No siempre es sencillo, pero normalmente uno de estos enfoques resuelve el problema. A veces, basta con reiniciar el servicio de tiempo después de realizar cambios, o reiniciarlo si la sincronización es muy discordante.