Ich habe eine Maschine mit Win 10 Build 18362 und eine mit Win 7 Ultimate SP1. Ich kann mich mit Remote Desktop problemlos von der Win 7-Maschine zur Win 10-Maschine verbinden, aber wenn ich versuche, von Win 10 zu Win 7 zu wechseln, werden die Standardanmeldeinformationen abgefragt, und beim ersten Versuch von einem neuen Benutzerkonto aus sehe ich dasAufforderung zur Identitätsüberprüfung am Remotecomputerdas fragt nach, ob die Verbindung vertrauenswürdig ist. Sobald ich das akzeptiere, erscheint ganz kurz „Bitte warten …“ (oder etwas Ähnliches), wie man es beim Anmelden erwarten würde, aber dann wird die Verbindung unterbrochen.
Bei der Untersuchung des Datenverkehrs mit Wireshark sehe ich, dass eine TLS 1.2-Verbindung hergestellt wird, dann aber ein TCP-Reset gesendet wird. Neben verschiedenen Fixes im Internet habe ich auch Folgendes versucht:
- Ändern des Ports von 3389 auf einen anderen
- Stellen Sie sicher, dass das Konto auf dem Win 7-Computer ein Administratorkonto ist.
- überprüft, ob auf dem Win 7-Rechner ein Passwort festgelegt ist
- Netzwerkprofil auf Win 10-Rechner auf privat setzen
- Richten Sie auf dem Win 10-Computer ein neues Windows-Konto mit einem anderen Benutzernamen ein und versuchen Sie, sich mit diesem bei der Win 7-Maschine anzumelden
- stellte sicher, dass TLS 1.1 und 1.2 auf dem Win 7-Rechner aktiviert waren
- überprüft, ob Remoteverbindungen auf dem Win 7-Computer aktiviert wurden
- Deaktivieren Sie im Remotedesktop-Anmeldefenster auf der Registerkarte „Lokale Ressourcen“ in der Gruppe „Lokale Geräte und Ressourcen“ (klicken Sie auf „Mehr ...“) die Option „Smartcards oder Windows Hello for Business“.
- im Remotedesktop-Anmeldefenster auf der Registerkarte „Erweitert“ wurde „Wenn die Serverauthentifizierung fehlschlägt:“ in „Verbinden und nicht warnen“ geändert.
- überprüft, ob Remote Desktop TCP-in und Remote Desktop-Einträge in den eingehenden Verbindungen der Windows-Firewall vorhanden waren
- Legen Sie den Umfang der TCP-in-Firewall-Regel auf „Nur öffentlich“ fest (entfernen Sie „Privat“ und „Domäne“).
- habe das UDP-Transportprotokoll sowohl in der Registrierung als auch mithilfe des Gruppenrichtlinien-Editors aktiviert (in der Registrierung den Schlüssel SelectTransport unter HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services von „1“ auf „2“ geändert und in der Gruppenrichtlinie unter Computerkonfiguration -> Administrative Vorlagen -> Windows-Komponenten -> Remotedesktopdienste -> Remotedesktop-Sitzungshost -> Verbindungen die Option „RDP-Transportprotokolle auswählen“ aktiviert und auf „Entweder UDP oder TCP verwenden“ eingestellt).
Ich habe die von Microsoft angebotenen Optionen ausprobiertHier(Schritte 3 und 4), wo die folgenden Befehle in PowerShell ausgegeben werden, um zu sehen, welche Anwendungen auf Port 3389 lauschen:
cmd /c 'netstat -ano | find "3389"'
cmd /c 'tasklist /svc | find "<pid listening on 3389>"'
Zuerst dachte ich, ich wäre hier auf etwas gestoßen, da der Bericht, welche Anwendungen den Port verwendeten, „CryptSvc, Dnscache, LanmanWorkstation“ lautete. Ich dachte, diese hätten nichts mit RDP zu tun, aber als ich den Port auf 3390 änderte und dieselben Befehle wiederholte, wurden nun dieselben 3 Anwendungsnamen auf 3390 angezeigt, was mich zu der Annahme veranlasste, dass diese tatsächlich mit RDP zu tun haben, obwohl laut Schritt 6 dieses Artikels nur TermServe.exe den Port verwenden sollte, sodass ich mir über die Ergebnisse dieses Artikels nicht ganz sicher bin. Dieser Artikel wurde jedoch 2019 geschrieben und ich arbeite mit Win 7, daher könnte es sein, dass Win 7 nur die 3 auflistet, nicht nur TermServe.exe.
Nach der Untersuchung der Ereignisanzeige sehe ich unter dem Zweig TerminalServices-ClientActiveXCore -> Microsoft-Windows-TerminalServices-RDPClient/Operational einen Warneintrag mit folgendem Inhalt:
RDPClient_SSL: Beim Übergang von TsSslStateDisconnected zu TsSslStateDisconnected als Reaktion auf TsSslEventInvalidState ist ein Fehler aufgetreten (Fehlercode 0x8000FFFF).
Außerdem sehe ich unter „TerminalServices-LocalSessionManager -> Operational“ ein Informationsereignis mit dem folgenden Inhalt:
Sitzung 1 wurde getrennt, Ursachencode 5
Wenn ich mir eine Liste mit RDS Session Host Server Disconnect Codes anschaueHier, Grundcode 5 lautet „Ein anderer Benutzer hat sich mit dem Server verbunden und erzwingt die Trennung der aktuellen Verbindung.“ … was seltsam ist, da ich der einzige Benutzer bin.
Es scheint, als ob ich über mein lokales Netzwerk problemlos mit dem Win 7-Rechner Kontakt aufnehmen kann. Direkt nach der Identitätsüberprüfung wird die Verbindung unterbrochen. Kann irgendjemand in diesen Symptomen Hinweise darauf erkennen, was ich versuchen kann, zu beheben?
Danke schön!