So beheben Sie Remotedesktopfehler, die durch eine Zeit- oder Datumsabweichung verursacht werden

Beim Verbindungsversuch per RDP zu einem Remoteserver in der AD-Domäne stieß ich auf diesen ärgerlichen Fehler. Die Meldung „Remotedesktop kann die Identität aufgrund einer Datums- oder Zeitabweichung nicht überprüfen“ ist recht häufig, aber etwas seltsam, da die Uhren manchmal tatsächlich korrekt sind. Windows gibt diese Meldung aus, weil die Kerberos-Authentifizierung eine perfekte Synchronisierung erfordert – und bei einer Abweichung von mehr als fünf Minuten gerät das System in Panik. In manchen Fällen scheint jedoch alles synchronisiert zu sein, und trotzdem erscheint die Fehlermeldung. Man sollte daher alles doppelt prüfen, um sicherzugehen.

Das größte Problem ist die Zeitsynchronisierung, insbesondere bei der Serververwaltung über ILO oder Remote-Konsolen. Selbst wenn die Zeit visuell korrekt erscheint, sollte die Zeitsynchronisierung überprüft werden. Manchmal kann der Hypervisor auf einer VM die Host-Zeitsynchronisierung stören, oder der Remote-Server kann eine Zeitabweichung aufweisen. Eine Überprüfung mit nativen Befehlen oder Tools ist ratsam.

Wie man RDP-Zeit-/Authentifizierungsfehler behebt

Überprüfen und synchronisieren Sie die Zeit auf dem Remote-Server manuell.

Dies ist hilfreich, falls die Uhrzeit tatsächlich, auch nur geringfügig, nicht synchronisiert ist. Der Befehl ist einfach und funktioniert auf den meisten Windows-Servern:

net time \\remote-ip-or-hostname

Auf manchen Systemen ist dieser Befehl möglicherweise veraltet, eignet sich aber dennoch für eine schnelle Überprüfung. Falls die Uhrzeit nicht übereinstimmt, führen Sie eine manuelle Synchronisierung durch, indem Sie den Zeitdienst konfigurieren. Führen Sie dazu folgenden Befehl in einem PowerShell-Fenster mit Administratorrechten aus:

w32tm /config /manualpeerlist:"your.ntp.server" /syncfromflags:manual net stop w32time net start w32time w32tm /resync

Ersetzen Sie „your.ntp.server“ durch die IP-Adresse oder den Hostnamen Ihres NTP-Servers. Dadurch wird die Uhrzeit neu synchronisiert und die Diskrepanz hoffentlich behoben. Beachten Sie, dass dies manchmal einen Neustart oder mehrere Versuche erfordert, insbesondere wenn der Zeitdienst hartnäckig reagiert.

Noch etwas: Wenn es sich bei dem Remote-System um eine VM handelt, prüfen Sie, ob der Hypervisor eine eigene Zeitsynchronisierung erzwingt. VMs versuchen häufig, die Zeit mit dem Host zu synchronisieren, was bei falscher Konfiguration zu unerwarteten Abweichungen führen kann. Deaktivieren Sie gegebenenfalls die Zeitsynchronisierung in den VM-Einstellungen oder konfigurieren Sie sie so, dass sie ausschließlich NTP-Quellen verwendet.

DNS- und Netzwerkeinstellungen überprüfen

Da die DNS-Auflösung auch Kerberos beeinträchtigen kann, stellen Sie sicher, dass die DNS-Einstellungen des Servers korrekt sind. Verwenden Sie dazu folgenden Befehl in der Nähe der Serverkonsole:

nslookup some_server_name DNS_Server_IP

Wenn die DNS-Auflösung nicht korrekt funktioniert, kann dies zu Problemen mit Kerberos-Tickets oder Authentifizierungsfehlern führen. Wechseln Sie gegebenenfalls den DNS-Server oder beheben Sie Probleme mit der DNS-Reaktionsfähigkeit. Denn Windows macht es einem manchmal unnötig schwer.

Sind mehrere Netzwerkadapter vorhanden, prüfen Sie, ob die Routingtabelle den DNS-Verkehr nicht über die falsche Schnittstelle leitet. Verwenden Sie `route print`, um zu ermitteln, welcher Adapter für die DNS-IP-Adressen verwendet wird. Korrektes Routing trägt zu konsistenten Sicherheits- und Authentifizierungsabläufen bei.

Verwenden Sie für RDP die IP-Adresse anstelle des FQDN.

Das ist zwar etwas umständlich, aber wenn alles andere fehlschlägt, stellen Sie die Verbindung direkt über die IP-Adresse anstatt über den vollständigen Domänennamen her. Warum? Weil Kerberos auf DNS und Domänenvertrauensbeziehungen basiert. Bei Verwendung der IP-Adresse wird Kerberos komplett umgangen, was den Authentifizierungsprozess deutlich vereinfacht. Das ist zwar nicht immer eine dauerhafte Lösung, kann aber bei komplexen Konfigurationen helfen, eine Verbindung herzustellen und zu überprüfen, ob das Problem tatsächlich an Kerberos liegt.

Überprüfen Sie die Vertrauensbeziehungen mit Active Directory.

Führen Sie diesen PowerShell-Befehl aus, um zu prüfen, ob die Vertrauensstellung des Computers noch gültig ist:

Test-ComputerSecureChannel

Wenn die Funktion „True“ zurückgibt, ist die Vertrauensstellung in Ordnung. Andernfalls müssen Sie sie möglicherweise reparieren. Versuchen Sie es mit folgendem Befehl:

Test-ComputerSecureChannel -Repair -Credential domain\admin_user

Ersetzen Sie „domain\admin_user“ durch ein Administratorkonto mit Domänenrechten. Manchmal schlägt dies mit einer Fehlermeldung fehl, dass der Server nicht betriebsbereit ist. Dies deutet auf Kommunikationsprobleme mit dem Domänencontroller oder auf Netzwerkprobleme hin.Überprüfen Sie in solchen Fällen, ob die TCP/UDP-Ports 88, 389 und weitere geöffnet und verfügbar sind. Für diese Tests benötigen Sie möglicherweise Tools wie PortQry.

Stellen Sie sicher, dass die Einstellungen der RDP-Sicherheitsschicht konsistent sind.

Manchmal führt eine Inkompatibilität der Sicherheitsebene zu Handshake-Fehlern. Sie können dies im Gruppenrichtlinien-Editor unter Computerkonfiguration > Administrative Vorlagen > Windows-Komponenten > Remotedesktopdienste > Remotedesktop-Sitzungshost > Sicherheit überprüfen oder festlegen. Suchen Sie nach Verwendung einer bestimmten Sicherheitsebene für Remote-(RDP-)Verbindungen erforderlich und wählen Sie eine weniger sichere Option wie RDP-Sicherheitsebene oder SSL (TLS 1.0).Alternativ können Sie die Registrierung direkt bearbeiten.

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

Stellen Sie den Wert für verschiedene Sicherheitsmodi auf 1 oder 0 ein. Beachten Sie jedoch: Das Reduzieren der Sicherheitseinstellungen ist nicht immer optimal, kann aber bei der Fehlersuche helfen, wenn der Handshake aufgrund von Protokollinkompatibilitäten fehlschlägt.

Zu guter Letzt sollten Sie beachten, dass auch die jüngsten Änderungen an CredSSP Probleme verursachen können. Falls Updates das Protokoll beeinträchtigt haben, müssen Sie möglicherweise Ihre Richtlinien anpassen oder Clients und Server entsprechend aktualisieren. Das ist allerdings ein ganz anderes Thema.

Zusammenfassend lässt sich sagen, dass die Behebung von RDP-Zeit- oder Kerberos-Problemen eine Kombination aus der Überprüfung von Uhren, DNS, Vertrauensstellungen und Sicherheitseinstellungen erfordert. Das ist nicht immer einfach, aber in der Regel löst einer dieser Ansätze das Problem. Manchmal genügt es, den Zeitdienst nach Änderungen neu zu starten – oder den Computer neu zu starten, falls die Zeitangaben stark abweichen.