I was doing some maintenance on some Citrix Provisioning Services servers. These guys are VMs running on VMWare. After a reboot, I got this error when trying to RDP back in to one of the servers

The connection cannot be completed because the remote computer that was reached is not the one you specified. This could be caused by an outdated entry in the DNS cache. Try using the IP address of the computer instead of the name.

In the Windows System Event Log, we see this error:

Log Name: System
Source: Microsoft-Windows-Security-Kerberos
Date: 12/10/2013 10:14:28 AM
Event ID: 4
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: ClientName.DomainName
Description:
The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server servername$. The target name used was TERMSRV/SERVERNAME. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (DomainName) is different from the client domain (DomainName), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.

Initially I ran ipconfig /flushdns on the client because that’s kind of what the RDP error told me to do. When that didn’t fix it, a coworker mentioned that he had seen it before.

When this VM came back up, the time was all jacked up in vCenter. It was reporting a time in GMT when the server was actually in EST. That, apparently, was enough to set off alarm bells and RDP thought the server was being impersonated!

We fixed the time in vCenter and rebooted the VM. Success!