I came across the following error when trying to connect via RDP to a remote server in the AD domain. After specifying the correct domain credentials for the RDP user, the error message appeared (shown below) and the RDP client window closed.
As it appears from the error, the RDP client couldn’t authenticate using Kerberos, since the time difference between the local and remote computer exceeds 5 minutes. But in my case it turned out that it was not true: having opened the remote server console over ILO, I made sure that the time and time zone were the same on both computers (and were obtained from the same source NTP server).
You can try to check the time on the remote computer using this command:
net time \\remote-computer-IP-address
You can sync time manually just in case and restart the w32time service:
w32tm /config /manualpeerlist:your_ntp_server_ip NTP,0x8 /syncfromflags:manual
net stop w32time & net start w32time & w32tm /resync
This article describes some other reasons why time can be wrong on a computer.
If you have physical access to the remote computer (I had access through the HPE ILO console), check the DNS server in the network adapter settings. Also make sure that you can access this DNS server from your remote server. It is easier to do it using this command:
nslookup some_server_name DNSServername
If the DNS server is not responding, make sure that it is working correctly or try to specify another DNS server address.
If multiple network adapters are used on the remote computer, 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.
Try to connect to the remote computer using the IP address instead of full FQDN DNS name in the RDP client connection window. In this case, Kerberos won’t be used for authentication.
Make sure that trust relationship with the AD domain exists. To do it, run this PowerShell command:
Test-ComputerSecureChannel
If there is trusted relationships, it will return True.
To repair the trusted relationship with the Active Directory domain, you can use this command:
Test-ComputerSecureChannel -Repair -Credential contoso\your_admin_account_name
If the 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” appears, check the availability of the domain controller from your server and open TCP/UDP ports for “Domain and Trusts” service using the portqry tool.
Make sure that the same “RDP Security Layer” is selected both on the local and remote computer. This parameter may be set using the “Require use of specific security layer for remote (RDP) connections” policy in the GPO section Computer Configuration -> Administrative Templates -> Windows Components -> Remote Desktop Services -> Remote Desktop Session Host -> Security by selecting less secure RDP level as described in this article. Or do it using this registry key: HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\SecurityLayer.
It is also recommended to make sure that the problem is not related to the recent changes in the CredSSP protocol.
2 comments
It worked in my case. I had to check on the remote machine the time and date, also the regional settings.
Updating the date fixed the issue, it was off by 1 day.
I tried a “netdom /query fsmo” but in my case the server could not communicate. Also, when validating on exiting it stated that the DNS Server was not responding. Quick fix without rebooting. You’ll need to be on the console, RDP will bounce you. I selected “Obtain an IP Address automatically” exited and waited a few moments. I then entered back in the manual settings and exited. Viola, almost immediately I was able to RDP via NetBios and FQDN.