In the process of trying to establish a connection to a remote server in the AD domain via RDP, an error such as "Remote desktop cannot verify the identity time or date difference between your computer and the remote computer" occurs.
Here at Ibmi Media, as part of our Server Management Services, we regularly help our Customers to solve Windows related errors.
In this context, we shall look into the main causes of this error and how to tackle it.

What triggers "remote desktop cannot verify the identity time or date difference" error?

As earlier stated, this error happens while trying to connect to a remote server in the AD domain via RDP.

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 to fix the error "remote desktop cannot verify the identity time or date difference?

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

To implement this, simply execute the following command to check the time on the remote computer;

net time \\remote-computer-IP-address

The commands to sync the time manually if necessary and restart the w32time service is provided below;

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 these commands;

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 struggling with Windows error? – We are here to help you today.]