Heute möchte ich mal wieder ein Problem behandeln, auf das ich letztens gestoßen bin. Die RDP-Verbindung ließ sich zu einen unserer Windows 7 Clients nicht herstellen. Außer einer Warnung und einer anschließenden Fehlermeldung hat derjenige, der die RDP-Verbindung aufbauen wollte, nichts weiter zu Gesicht bekommen.
1. Das Problem
Beim Verbinden mit dem betroffenen Zielcomputer per Remotedesktop erhählt der Benutzer folgende Warnung:
Diese scheint noch ein wenig Hoffnung zu geben mit der Ja/Nein-Auswahl. Diese wird aber trotz drücken des „Ja“-Buttons mit der direkt folgenden Fehlermeldung zerstört:
2. Die Analyse
Wenn man nach dieser Fehlermeldung sucht, findet man meist Lösungen, die den RDP-Zugriff von Windows-Versionen ab Windows Vista auf alte Windows XP-PCs oder Windows Server 2003-Server betreffen. Hierzu muss man wissen, dass Microsoft ab Vista eine zusätzliche Sicherheitsstufe namens „Authentifizierung auf Netzwerkebene“ (NLA) für RDP-Verbindungen eingeführt hat.
Beim betroffenen Rechner ist per Gruppenrichtlinie (daher sind die Optionen ausgegraut) genau diese höhere Sicherheitsstufe festgelegt worden:
Das bedeutet, dass der RDP-Client ebenfalls NLA unterstützen muss ( ab Windows XP SP3). Nun habe ich aber nicht versucht von einem alten Windows-Rechner ohne NLA auf diesen Windows 7-Rechner zuzugreifen, sondern von einem anderen Windows 7-Rechner aus. Irgendetwas verhindert also die NLA und der Client denkt, das Ziel sei ein WindowsXP/2003-Rechner ohne NLA.
Hinter dieser hochtrabenden Bezeichnung „Network Level Authentication“ steht im Prinzip die Nutzung von TLS (1.0) zur Authentifizierung des RDP-Sitzungshosts und somit werden entsprechende Zertifikate benötigt. Und hier begann sich dann der Wald bei mir zu lichten.
Bestätigung fand ich dann auch in der Ereignisanzeige des Zielcomputers:
Es erschien ein Fehlereintrag von der Quelle „Schannel“ (das MS-Äquivalent zu OpenSSL) mit der Event ID 36870. In diesem Eintrag wird von einem Fehlercode 0x8009030d und einem internen Fehlerstatus 10001 berichtet, den das kryptografische Modul zurückgegeben hat.
Es gibt also ein Problem mit der TLS/SSL-Authentifizierung, wenn auf den RDP-Server zugegriffen werden soll.
3. Die Lösung
Hierzu lassen wir uns erstmal anzeigen, welches Zertifikat dem RDP-Service zugewiesen ist. In der Admin-cmd des Zielcomputers folgendes eintippen:
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash
Wir bekommen den/die SHA1-Fingerprint(s) des zugewiesenen Zertifikats. Normalerweise wird man hier nur 1 Hashwert und somit auch nur 1 zugewiesenes Zertifikat sehen. Egal, ob 1 oder wie bei uns 2 Hashwerte aufgelistet werden, ist es wichtig, dass die den Hashwerten entsprechenden Zertifikate auch vorhanden sind und für die Remotedesktop-Verwendung spezifiziert sind. Den Fingerprint gleichen wir mit den installierten Computer- und RemoteDesktop-Zertifikaten ab:
Die Zertifikatsverwaltung des Computers erreichen wir wie folgt:
- Start -> „mmc“ in die Startmenü-Suche eingeben -> Rechtsklick auf mmc.exe und als „Administrator ausführen“
- dann Datei -> Snap-In hinzufügen..
- links Zertifikate auswählen, in der Mitte „hinzufügen“
- im aufpoppenden Dialog „Computer“ auswählen -> weiter -> fertigstellen -> ok
Anschließend können wir uns zu den „Eigenen Zertifikaten“ und „Remote Desktop“-Zertifikaten durchklicken, diese mit Doppelklick öffnen und unter „Details“ den Fingerprint anschauen.
Nach Abgleich stellte ich fest, dass das Zertifikat mit dem 2. Hashwert nicht mehr vorhanden war (oben rot markiert), der erste Wert entsprach dem Computerzertifikat, welches bei uns durch das Autoenrollment der Zertifizierungsstelle nach Ablauf erneuert wird.
Nach ein wenig Recherche in der Historie unserer Zertifizierungsstelle, fand ich tatsächlich das Zertifikat. Es war ein Computerzertifikat, welches jetzt durch das Autoenrollment ersetzt wurde. Aus einem bestimmten Grund (den ich zu diesem Zeitpunkt aber schon im Hinterkopf hatte) versuchte der RDP-Server des betroffenen Rechners also immer noch ein Zertifikat zu benutzen, welches ersetzt wurde.
An dieser Stelle musste ich mich fast 1 Jahr zurückerinnern, denn ich wollte damals die Zertifikatswarnungen bei RDP-Verbindungen beheben und stieß auf einen Blogpost von Franky’s Web. In diesem Beitrag beschreibt der Autor, wie man Zertifikate für RDP nutzen konnte. Das Problem bei dieser Methode ist jetzt, dass dieses Zertifikat irgendwie festgeschrieben wurde und somit vom Autoenrollment einer Zertifizierungsstelle unbeeindruckt bleibt.
Nach ein wenig Suchen stieß ich dann auf einen MS-Artikel, wo unter „Method 2“ dann die Lösung zu finden war. Unter dem Registry-Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp wurde der Hashwert des für RDP zu verwendenden Zertifikats gespeichert:
Den Eintrag „SSLCertificateSHA1Hash“ habe ich kurzerhand gelöscht. Ein erneutes Ausführen des WMIC-Befehls ergab nun:
Ist also kein expliziter Hashwert hinterlegt, benutzt der RDP-Server das Computerzertifikat, welches durch das Autoenrollment geändert wird.
Anschließend konnte ich mich wieder per RDP mit dem Zielcomputer verbinden, und das ohne Fehlermeldungen oder irgendwelche Zertifikatswarnungen (die ja gerade durch die Einführung einer Zertifizierungsstelle verhindert werden sollen).
danke – hat geholfen!
Top und vielen Dank :) Das hat geholfen