The error ‘remote desktop cannot verify the identity time or date difference’ occurs while trying to connect to a remote server in the AD domain via RDP.

Here at Bobcares, we have seen several such Windows-related errors as part of our Server Management Services for web hosts and online service providers.

Today we’ll take a look at the causes for this error and see the fix.

Why does the ‘remote desktop cannot verify the identity time or date difference’ error occur

This error occurs while trying to connect to a remote server in the AD domain via RDP.

For instance, the error appears as below.

This error specifies that the RDP client couldn’t authenticate using Kerberos. It happens because the time difference between the local and remote computer exceeds 5 minutes.

How we resolve the error ‘remote desktop cannot verify the identity time or date difference’

In order to fix this error, our Support Engineers opened the remote server console over ILO. Also, we made sure that the time and time zone was the same on both computers.

We run the below command to check the time on the remote computer.

net time \\remote-computer-IP-address

Here is the command we use to sync the time manually if necessary and restart the w32time service.

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

Note: If the remote server is a virtual machine, we ensure that the time synchronization with the host hypervisor is disabled in the VM settings.

Since we have physical access to the remote computer, we check the DNS server in the network adapter settings. Also, we make sure that we can access this DNS server from the remote server. For that, we make use of the below command.

nslookup some_server_name DNSServername

In case, the DNS DNS server is not responding, we make sure that it is working correctly or we try to specify another DNS server address.

However, if multiple network adapters are used on the remote computer, we make sure that the routing table is correct when accessing the DNS server. The computer may try to access the DNS server using another network adapter a different IP subnet.

Then we try to connect to the remote computer using the IP address instead of the full FQDN DNS name in the RDP client connection window. In our case, Kerberos won’t be used for authentication.

We make sure that a trust relationship with the AD domain exists. To do it, we run this PowerShell command.

Test-ComputerSecureChannel

If there are trusted relationships, it will return True.

To repair the trusted relationship with the Active Directory domain, we run this command:

Test-ComputerSecureChannel -Repair -Credential contoso\your_admin_account_name

If the below error appears then we check the availability of the domain controller from the server and open TCP/UDP ports for the “Domain and Trusts” service.

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

Also, we make sure that the same “RDP Security Layer” is selected both on the local and remote computer.

We set this parameter by using the “Require use of specific security layer for remote (RDP) connections” policy. It is present in the GPO section Computer Configuration >> Administrative Templates >> Windows Components >> Remote Desktop Services >> Remote Desktop Session Host >> Security by selecting less secure RDP level.

Or we do it by using the below registry key.

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

[Are you still stuck with Windows error? – We are here to help you]

Conclusion

In short, this error occurs while trying to connect to a remote server in the AD domain via RDP. Today, we saw the solution provided by our Support Engineers.