Da hat Microsoft doch viele kalt erwischt: Nach der Installation der Windows Updates vom April 2026 erscheint beim Anklicken von *.rdp-Dateien ein Warnhinweis.
Hintergrund dieser Änderung ist, das Microsoft nun erwartet, das man *.rdp-Dateien signiert. Begründet wird das mit mehr Sicherheit, um Phishing zu verhindern. Leider sorgt diese Änderung für erhöhtes Support-Aufkommen mit Meldungen wie “Wir kommen nicht mehr in den Terminalserver rein” (“Verbinden” anklicken war da schon zu viel) oder eben das da unerwartet und plötzlich etwas aufpoppt. Schlimmer noch: Diese Sicherheitswarnung kommt nicht nur bei (Terminal-)Servern sondern auch Clients (wenn man sich zum Beispiel vom Home Office aus auf den Arbeitsplatz-PC verbindet).
Vor den Updates konnte man eine *.rdp-Datei doppelt anklicken und die Verbindung wurde aufgebaut. Wobei das erst der Fall war, wenn man (initial) den Haken gesetzt hatte, das man den Remotecomputer kennt. Seit April erscheinen bei der Nutzung von *.rdp-Dateien folgende beide Meldungen hintereinander:
Bei der ersten Meldung kann man den Haken setzen, das man verstanden hat und dann sieht man dieses Fenster nicht mehr. In der Registry wird dann folgendes gesetzt:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client RdpLaunchConsentAccepted = 1 Typ: REG_DWORD
Wer diese Einstellung automatisiert setzen möchte kann diesen Befehl nutzen:
- CMD: reg add “HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client” /v “RdpLaunchConsentAccepted” /t REG_DWORD /d 1 /f
- PowerShell: Set-ItemProperty -Path “HKCU:\Software\Microsoft\Terminal Server Client” -Name “RdpLaunchConsentAccepted” -Value 1
Die zweite Meldung erscheint bei jedem Verbindungsaufbau mittels *.rdp-Datei. Ohne das die Datei signiert ist, kann man diesen Dialog nicht unterbinden.
Betroffen von dieser Änderung ist offenbar nur das Bordmittel “Remotedesktopverbindung”, auch bekannt als mstsc.exe, und ggf. davon abhängige Anwendungen. Auf der anderen Seite gibt es RDP-Clients die davon nicht betroffen sind, da sie nicht auf Windows-Mittel zurückgreifen.
Wie bekommt man diese Sicherheitswarnung weg?
Als kurzfristigen Workaround bietet Microsoft an, durch das Setzen folgenden Wertes in der Registry das Verhalten wie vor dem Patchday vorübergehend wiederherzustellen:
HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client RedirectionWarningDialogVersion = 1 Typ: REG_DWORD
Via Befehl geht das so:
- CMD: reg add “HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client” /v “RedirectionWarningDialogVersion” /t REG_DWORD /d 1 /f
- PowerShell: Set-ItemProperty -Path “HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client” -Name “RedirectionWarningDialogVersion” -Value 1
Aber die Redmonder behalten sich vor, diesen Wert in Zukunft zu ignorieren. Ich meine sogar aufgeschnappt zu haben, das dies zum Jahresende schon der Fall sein soll.
Die nach derzeitigen Stand finale Lösung besteht darin, *.rdp-Dateien zu signieren, der Vorgang ist zwar relativ einfach, aber auf Client-Seite stößt man je nach Umgebung auf verschiedene Unwegbarkeiten. Die Voraussetzungen hierfür sind fast überschaubar:
- Ein Zertifikat das mindestens für die Server-Authentifizierung und optional “codeSigning” geeignet ist. Der private Schlüssel muss für das Signieren bekannt sein.
- Auf dem System das die *.rdp-Datei signieren soll muss das gennannte Zertifikat samt privatem Schlüssel vorhanden sein.
- Zum Signieren wird das Tool rdpsign.exe benötigt (Bordmittel von Windows).
- Auf der Client-Seite muss diesem Zertifikat vertraut werden und die signiertem *.rdp-Datei muss bereitgestellt werden. Ferner werden verschiedene Einstellungen benötigt.
In Unternehmensumgebungen mit einer Active Directory-Domäne und Zertifikatsdiensten (PKI) sollte das kein Thema sein. Das Ganze hat in Sachen Bring-your-own-device, bei Nicht-Domänen-Mitgliedern oder anderweitig nicht-verwalteten Geräten seine Grenzen. Daher nachfolgend für kleinere oder RMM-verwaltete Systeme und Umgebungen eine Lösung.
Selbstsigniertes Zertifikat erstellen
In der PowerShell folgenden Befehl ausführen:
New-SelfSignedCertificate -DnsName "<Name>" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(10)
Bei “-DnsName” kann man einen Namen, eine IP oder einfach irgendwas eintragen. Die Gültigkeit kann über “-NotAfter (Get-Date).AddYears(10)”, in diesem Beispiel 10 Jahre, es geht auch länger oder kürzer, eingestellt werden. Gibt man dies nicht an, ist das Zertifikat ein Jahr gültig. In der hier genutzten Standardeinstellung dient dieses Zertifikat für die Client- und Serverauthentifizierung und kann für “Digitale Signatur” und “Schlüsselverschlüsselung” verwendet werden. Über die Parameter “-Type CodeSigningCert” und “-KeyUsage DigitalSignature” kann man dies einschränken.
Die Ausgabe des Befehls liefert den Fingerabdruck (Thumbprint) des Zertifikats, diesen sollte man gleich notieren, da man ihn später benötigt.
*.rdp-Datei signieren
In einer Eingabeaufforderung oder in der PowerShell wird die *.rdp-Datei wie folgt signiert:
rdpsign /sha265 <Fingerabdruck> <Dateiname>
Wildcards etc. funktionieren dem Test nach leider nicht, man kann also nicht einfach auf einmal mehrere *.rdp-Dateien signieren.
Zertifikat für den Client exportieren
In der PowerShell via
$cert = Get-ChildItem -Path Cert:\LocalMachine\My\<Fingerabdruck> Export-Certificate -Cert $cert -FilePath "<Name>.cer"
oder über die Zertifikate-MMC nach einem Rechtsklick auf das Zertifikat “Alle Aufgaben – Exportieren…”, ohne privaten Schlüssel als “DER-codiert-binär X.509 (CER).
Zertifikat auf dem Client importieren
Das zuvor exportierte Zertifikat muss auf dem Client unter
Computer - Vertrauenswürdige Stammzertifizierungsstelle
importiert werden. In der PowerShell geht das mit
Import-Certificate -FilePath "<Name.cer>" -CertStoreLocation "Cert:\LocalMachine\My"
Weitere notwendige Einstellungen auf dem Client
Ohne die nachfolgende Konfiguration erscheint die Sicherheitswarnung dennoch, ganz gleich wie oft man den Haken bei “…merken” setzt:
- CMD: reg add “HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services” /v TrustedCertThumbprints /t REG_SZ /d “<Fingerabdruck>” /f
- PowerShell: New-ItemProperty -Path “HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services” -Name “TrustedCertThumbprints” -Value “<Fingerabdruck>” -PropertyType String -Force
Klickt man nun eine signierte *.rdp-Datei doppelt an, erscheint zwar zunächst noch eine Sicherheitswarnung, aber mit dem Unterschied, das man nun den Haken setzen kann bei “Meine Auswahl für Remoteverbindungen dieses Herausgebers merken”. Bei zukünftigen Verbindungen wird diese Warnung nicht mehr angezeigt.
Wichtig: An dieser Stelle einmalig bestätigen, das zum Beispiel die Zwischenablage genutzt werden soll.
Der “Merken”-Haken ändert übrigens folgendes in der Registry:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\PublisherPermissions\<Fingerabdruck>
Unterhalb dieses Schlüssel findet sich ob man die Zwischenablage etc. aktiviert hat.
Zusammenfassung
Das Ganze mal kurz als Stichpunkte zugesammengefasst:
- Zertifikat mit priv. Schlüssel mit min. serverAuth und ggf. codeSigning.
- *.rdp-Datei signieren.
- Das Zertifikat ohne priv. Schlüssel auf dem Client importieren.
- Auf dem Client die notwendige Registry-Änderungen vornehmen.
Fazit
So oder so erfordert die Änderung seitens Microsoft einige Schritte. In der Domäne und mit PKI ist das etwas einfacher, da man die Einstellungen und Fingerabdrücke mittels Gruppenrichtlinie verteilen kann. Verwaltet man Geräte mittels RMM oder ähnlichem muss man die Dateien und Einstellungen entsprechend anders ausbringen. Alles lösbar, aber ich glaube Microsoft hat den Anwendern hiermit einen Bärendienst erwiesen und den ITlern mehr Arbeit verschafft. Man hat ja sonst nichts zu tun.
Das Ganze sorgt für Verwirrung und Verunsicherung auf Anwender-Seite bei zweifelhafter Aussicht das dies Phishing via RDP reduziert. Mir persönlich ist bislang kein Phishing-Versuch mittels Remotedesktopverbindung unter gekommen. Idealerweise ist kein RDP-Server, ganz gleich ob Terminalserver oder Arbeitsplatz, direkt aus dem Internet heraus erreichbar, wir stellen diese immer hinter ein VPN.
Wie hat Dir der Artikel gefallen ?
(Bislang keine Stimmen erhalten.)
Loading...
Du möchtest den Blog unterstützen ?
Neben PayPal.ME gibt es noch weitere Möglichkeiten, lies hier wie du diesen Blog unterstützen kannst.
Quellen
WindowsPro – RDP-Dateien mit einem Zertifikat signieren
Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 15 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.
Artikel (RSS)
XING
Schreibe einen Kommentar