El escritorio remoto no puede verificar la identidad de la computadora remota debido a la diferencia de fecha y hora

Me encontré con el siguiente error al intentar conectarme a través de RDP a un servidor remoto en el dominio AD. Después de especificar las credenciales de dominio correctas para el usuario RDP, apareció el mensaje de error (que se muestra a continuación) y se cerró la ventana del cliente RDP.

Escritorio remoto no puede verificar la identidad de la computadora remota porque hay una diferencia de fecha o hora entre su computadora y la computadora remota. Asegúrese de que el reloj de su computadora esté configurado con la hora correcta y luego intente conectarse nuevamente. Si el problema se repite, comuníquese con su administrador de red o con el propietario de la computadora remota.

Como se desprende del error, el cliente RDP no pudo autenticarse usando Kerberos, ya que la diferencia de tiempo entre la computadora local y remota excede los 5 minutos. Pero en mi caso resultó que no era cierto: habiendo abierto la consola del servidor remoto sobre ILO, me aseguré de que la hora y la zona horaria fueran las mismas en ambas computadoras (y se obtuvieron del mismo servidor NTP de origen).

Puede intentar verificar la hora en la computadora remota usando este comando:

net time \remote-computer-IP-address

Puede sincronizar la hora manualmente por si acaso y reiniciar el servicio w32time:

w32tm /config /manualpeerlist:your_ntp_server_ip NTP,0x8 /syncfromflags:manual
net stop w32time & net start w32time & w32tm /resync

Este artículo describe algunas otras razones por las que el tiempo puede ser incorrecto en una computadora.

Consejo. Si el servidor remoto es una máquina virtual, asegúrese de que la sincronización de la hora con el hipervisor del host esté deshabilitada en la configuración de la máquina virtual.

Si tiene acceso físico a la computadora remota (tuve acceso a través de la consola de HPE ILO), verifique el servidor DNS en la configuración del adaptador de red. También asegúrese de que puede acceder a este servidor DNS desde su servidor remoto. Es más fácil hacerlo usando este comando:

nslookup some_server_name DNSServername

Si el servidor DNS no responde, asegúrese de que esté funcionando correctamente o intente especificar otra dirección de servidor DNS.

Si se utilizan varios adaptadores de red en la computadora remota, asegúrese de que la tabla de enrutamiento sea correcta al acceder al servidor DNS. Es posible que la computadora intente acceder al servidor DNS utilizando otro adaptador de red con una subred IP diferente.

Intente conectarse a la computadora remota usando el dirección IP en lugar del nombre DNS FQDN completo en la ventana de conexión del cliente RDP. En este caso, Kerberos no se utilizará para la autenticación.

Asegúrese de que exista una relación de confianza con el dominio de AD. Para hacerlo, ejecute este comando de PowerShell:

Test-ComputerSecureChannel

Si hay relaciones de confianza, devolverá True.

Para reparar la relación de confianza con el dominio de Active Directory, puede usar este comando:

Test-ComputerSecureChannel -Repair -Credential contosoyour_admin_account_name

Si el error «Test-ComputerSecureChannel : Cannot reset the secure channel password for the computer account in the domain. Operation failed with the following exception: The server is not operational”Aparece, verifique la disponibilidad del controlador de dominio desde su servidor y abra los puertos TCP / UDP para el servicio“ Dominio y Fideicomisos ”usando la herramienta portqry.

Asegúrese de que la misma «Capa de seguridad RDP» esté seleccionada tanto en la computadora local como en la remota. Este parámetro se puede configurar mediante el «Requerir el uso de una capa de seguridad específica para conexiones remotas (RDP) « política en la sección GPO Configuración del equipo -> Plantillas administrativas -> Componentes de Windows -> Servicios de escritorio remoto -> Host de sesión de escritorio remoto -> Seguridad seleccionando un nivel de RDP menos seguro como se describe en este artículo. O hazlo usando esta clave de registro: HKLM System CurrentControlSet Control Terminal Server WinStations RDP-Tcp SecurityLayer.

También se recomienda asegurarse de que el problema no esté relacionado con los cambios recientes en el protocolo CredSSP.