Informationen

Änderung bei RDP-Dateien durch Microsoft-Updates ab April 2026

Erstellt mit Unterstützung von ChatGPT

Kurzbeschreibung

Microsoft hat mit den Sicherheitsupdates ab April 2026 das Verhalten beim Öffnen von Remote-Desktop-Dateien (.rdp) geändert.

Seit diesem Update zeigt der Windows-Remotedesktopclient mstsc.exe beim Öffnen einer .rdp-Datei zusätzliche Sicherheitsdialoge an. Hintergrund ist der Schutz vor Phishing-Angriffen über manipulierte RDP-Dateien. Eine .rdp-Datei kann nicht nur das Verbindungsziel enthalten, sondern auch lokale Ressourcen des Benutzers an den entfernten Computer weiterreichen, zum Beispiel Zwischenablage, Drucker, Laufwerke, Kamera oder Smartcards. Microsoft beschreibt diese Änderung ausdrücklich als Schutzmaßnahme gegen missbräuchliche RDP-Dateien.

Temporäre Lösung #1 - Mit GPO/-Reg-Eintrag deaktivieren

Es gibt einen temporären Workaround, der das alte Dialogverhalten wiederherstellt. Der wird derzeit häufig so gesetzt:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services\Client]
"RedirectionWarningDialogVersion"=dword:00000001

Oder per PowerShell als Administrator:

New-Item -Path "HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client" -Force | Out-Null
New-ItemProperty `
  -Path "HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client" `
  -Name "RedirectionWarningDialogVersion" `
  -PropertyType DWord `
  -Value 1 `
  -Force

Das ist für kleine Kunden praktisch, aber sicherheitlich und strategisch unschön. Microsoft hat die Änderung bewusst eingeführt, um RDP-Datei-Missbrauch zu verhindern; ein Workaround kann später wieder entfernt oder geändert werden. Für Kunden ohne Domäne müsstest du ihn manuell, per RMM, Intune, Script, Fernwartung oder Installer setzen.

Ich würde das nur als Übergangslösung einsetzen.

Lösung #2 - RDP-Dateien signieren

Mircosoft empfiehlt RDP-Dateien mit einem Code-Signing-Zertifikat zu signieren. Das ist auch die Lösung die ich empfehle und in meinem Lösungen einsetzen.

Da inzwischen alle mir bekannten Code-Signing-Zertifikate mit einer 2FA-Lösung arbeiten kommt eigentlich nur noch eine eigene CA in Frage.

Damit ein PC eine signierte RDP-Datei akzeptiert muss die Root-CA, das Signing-Cert und ein Registry-Eintrag vorhanden sein.

Betroffene Systeme

Die Änderung betrifft laut Microsoft unter anderem:

Windows 11
Windows 10
Windows Server 2025
Windows Server 2022
Windows Server 2019
Windows Server 2016
Windows Server 2012 R2
Windows Server 2012

Die neue Warnlogik gilt für den Remotedesktopverbindungsclient beim Öffnen von .rdp-Dateien.

Ab wann tritt die Änderung auf?

Die Änderung wurde mit den April-2026-Sicherheitsupdates eingeführt.

Für Windows 11 24H2/25H2 ist der relevante Patchstand beispielsweise:

April 2026 Sicherheitsupdate
KB5083769
Windows 11 24H2: Build 26100.8246
Windows 11 25H2: Build 26200.8246

Neuere kumulative Updates enthalten diese Änderung ebenfalls. Ein PC mit einem älteren Build, zum Beispiel 26200.8039, hat diese Änderung möglicherweise noch nicht.

Prüfen kann man den Buildstand mit:

winver

oder per PowerShell:

Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber, WindowsVersion

Was hat sich geändert?

Vor dem Update

Vor dem April-2026-Update konnte eine .rdp-Datei weitgehend direkt geöffnet werden.

Wenn in der Datei beispielsweise folgende Einstellungen gesetzt waren:

redirectclipboard:i:1
redirectprinters:i:1

wurden Zwischenablage und Drucker normalerweise automatisch gemäß RDP-Datei aktiviert.

Es konnte zwar weiterhin eine Zertifikatswarnung erscheinen, wenn der entfernte RDP-PC kein vertrauenswürdiges Serverzertifikat hatte, aber die lokalen Ressourcen wurden meistens wie in der .rdp-Datei definiert verwendet.

Nach dem Update

Nach dem Update zeigt Windows beim Öffnen einer .rdp-Datei zusätzliche Sicherheitsdialoge an.

Microsoft unterscheidet dabei im Wesentlichen zwei Dialogarten:

  1. Einmaliger Erklärdialog beim ersten Öffnen einer .rdp-Datei
  2. Wiederkehrender Sicherheitsdialog bei jeder .rdp-Datei

Microsoft beschreibt, dass beim ersten Öffnen einer .rdp-Datei nach dem Update ein einmaliger Hinweis erscheint, der die Risiken von RDP-Dateien erklärt. Nach Bestätigung erscheint dieser Dialog für das Benutzerkonto nicht erneut.

Zusätzlich erscheint bei jeder .rdp-Datei ein Sicherheitsdialog, bevor die Verbindung aufgebaut wird. Dieser Dialog zeigt unter anderem:

Remotecomputer / Zieladresse
Herausgeber der RDP-Datei
angeforderte lokale Ressourcen

Alle lokalen Ressourcen, die durch die .rdp-Datei angefordert werden, sind zunächst deaktiviert und müssen vom Benutzer aktiv erlaubt werden. Dazu gehören zum Beispiel Zwischenablage, Drucker, Laufwerke, Kamera oder Smartcards.

Welche Auswirkungen hat das praktisch?

Wenn eine .rdp-Datei lokale Ressourcen anfordert, werden diese nicht mehr stillschweigend übernommen. Der Benutzer muss sie im Dialog aktiv auswählen.

Typische betroffene Einstellungen sind:

redirectclipboard:i:1
redirectprinters:i:1
drivestoredirect:s:*
redirectcomports:i:1
redirectsmartcards:i:1
devicestoredirect:s:*
audiocapturemode:i:1
camerastoredirect:s:*

Das führt dazu, dass Benutzer nach dem Update zum Beispiel jedes Mal gefragt werden, ob sie die Zwischenablage oder Drucker freigeben möchten.

Screenshot - Einmalige Sicherheitswarnung bei der 1. RDP-Verbindung

rdp-meldung1.png

Screenshot - Sicherheitswarnung vor jeder RDP-Verbindung - Kein Zertifikat - Kein Reg-Schlüssel

rdp-meldung2.png

Screenshot - Sicherheitswarnung vor jeder RDP-Verbindung - Mit Zertifikat - Kein Reg-Schlüssel

grafik.png

Warum hat Microsoft das geändert?

Eine .rdp-Datei ist nicht nur eine einfache Verknüpfung. Sie kann festlegen:

zu welchem Server verbunden wird
welche Anzeigeeinstellungen verwendet werden
welche lokalen Geräte weitergeleitet werden
ob Drucker, Zwischenablage oder Laufwerke verfügbar sind
welche Gateway- und Authentifizierungseinstellungen genutzt werden

Angreifer können manipulierte RDP-Dateien per E-Mail oder Download verteilen. Öffnet ein Benutzer eine solche Datei, kann sein PC mit einem fremden System verbunden werden und dabei lokale Ressourcen freigeben. Genau dieses Risiko möchte Microsoft reduzieren.

Unterschied zwischen RDP-Serverzertifikat und RDP-Dateisignatur

Wichtig ist die Unterscheidung zwischen zwei verschiedenen Zertifikatsthemen.

RDP-Serverzertifikat

Das RDP-Serverzertifikat betrifft die Identität des entfernten Computers.

Wenn der Ziel-PC kein vertrauenswürdiges Zertifikat hat, erscheint eine Meldung ähnlich:

Die Identität des Remotecomputers kann nicht überprüft werden.

Dieses Zertifikat liegt auf dem Zielsystem, also auf dem RDP-PC oder RDP-Server.

RDP-Dateisignatur

Die RDP-Dateisignatur betrifft die Herkunft und Unverändertheit der .rdp-Datei.

Wenn eine .rdp-Datei nicht signiert ist oder der Herausgeber nicht verifiziert werden kann, zeigt Windows sinngemäß:

Unbekannter Herausgeber
Unbekannte Remoteverbindung

Ein korrektes RDP-Serverzertifikat entfernt daher nicht automatisch den neuen .rdp-Dateidialog. Beide Themen sind getrennt.

Wann wird der Herausgeber angezeigt?

Wenn eine .rdp-Datei digital signiert ist und Windows die Zertifikatskette prüfen kann, kann Windows den Herausgeber anzeigen.

Beispiel:

Herausgeber: RDP Secure Access

Wenn die Datei nicht signiert ist oder die Zertifikatskette nicht vertraut wird, erscheint stattdessen:

Unbekannter Herausgeber

Damit Windows eine intern signierte .rdp-Datei als vertrauenswürdig akzeptiert, müssen auf dem Client passende Vertrauenseinstellungen vorhanden sein.

Typischer Aufbau:

Root-CA-Zertifikat im lokalen Zertifikatsspeicher
RDP-Signer-Zertifikat bzw. dessen Zertifikatskette vertrauenswürdig
SHA1-Thumbprint des Signer-Zertifikats in der RDP-Trusted-Publisher-Policy

Die relevante Richtlinie heißt:

Specify SHA1 thumbprints of certificates representing trusted .rdp publishers

Welche Registry-/Policy-Einstellung ist relevant?

Für vertrauenswürdige .rdp-Publisher wird der SHA1-Thumbprint des Signaturzertifikats hinterlegt.

Registry-Pfad:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
"AllowSignedFiles"=dword:00000001
"TrustedCertThumbprints"="SHA1_THUMBPRINT_DES_RDP_SIGNER_ZERTIFIKATS"

Wichtig: Hier gehört der SHA1-Thumbprint des Signer-Zertifikats hinein, nicht der Thumbprint der Root-CA.

Temporärer Kompatibilitäts-Workaround

Es gibt eine Policy/Registry-Einstellung, mit der das alte Dialogverhalten vorübergehend wiederhergestellt werden kann:

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows NT\Terminal Services\Client]
"RedirectionWarningDialogVersion"=dword:00000001

Per PowerShell als Administrator:

New-Item -Path "HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client" -Force | Out-Null; New-ItemProperty -Path "HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client" -Name "RedirectionWarningDialogVersion" -PropertyType DWord -Value 1 -Force | Out-Null

Diese Lösung ist als Übergangslösung zu verstehen. Microsoft hat die neue Warnlogik aus Sicherheitsgründen eingeführt; daher sollte man nicht davon ausgehen, dass dieser Workaround dauerhaft unverändert bestehen bleibt.

Empfohlene Zielkonfiguration

Für verwaltete RDP-Dateien empfiehlt sich folgender Ablauf:

1. RDP-Datei vollständig erzeugen
2. RDP-Datei serverseitig signieren
3. Signierte RDP-Datei an den Benutzer ausliefern
4. Auf dem Client Root-CA bzw. Zertifikatsvertrauen einrichten
5. Auf dem Client den Signer-Thumbprint als vertrauenswürdigen RDP-Publisher setzen

Die .rdp-Datei darf nach dem Signieren nicht mehr verändert werden, sonst wird die Signatur ungültig.

Zusammenfassung

Seit dem April-2026-Sicherheitsupdate behandelt Windows .rdp-Dateien deutlich restriktiver. Beim Öffnen einer .rdp-Datei werden lokale Ressourcen wie Zwischenablage, Drucker oder Laufwerke nicht mehr automatisch anhand der Datei freigegeben, sondern müssen vom Benutzer aktiv bestätigt werden. Die Änderung dient dem Schutz vor RDP-Phishing und betrifft insbesondere Umgebungen, in denen .rdp-Dateien dynamisch erzeugt und heruntergeladen werden.

Für eine saubere Lösung müssen .rdp-Dateien signiert und die entsprechenden Herausgeberzertifikate bzw. Policies auf den Windows-Clients eingerichtet werden. Alternativ kann kurzfristig der Registry-Workaround RedirectionWarningDialogVersion=1 verwendet werden.

Quellen:

RDP-Dateien unter Ubuntu signieren

Erstellt mit Unterstützung von ChatGPT

Allgemein

Ich nutzte diese Lösung um unter Ubuntu RDP-Dateien zu signieren.

1. Pakete auf Ubuntu installieren

sudo apt update && sudo apt install -y openssl curl python3

Das Linux-Tool installieren:

sudo curl -L https://raw.githubusercontent.com/nfedera/rdpsign/master/rdpsign.py -o /usr/local/bin/rdpsign && sudo chmod +x /usr/local/bin/rdpsign

Das Tool nutzt laut README Python und OpenSSL; der Beispielaufruf ist rdpsign test.rdp test-signed.rdp signer.crt -k signer.key.

2. Verzeichnisstruktur erstellen

sudo mkdir -p /opt/rdp-ca/{private,certs,csr,out}
sudo chmod 700 /opt/rdp-ca/private
cd /opt/rdp-ca

3. OpenSSL-Konfiguration für Root-CA erstellen

sudo tee /opt/rdp-ca/root-ca.cnf >/dev/null <<'EOF'
[ req ]
default_bits = 4096
prompt = no
default_md = sha256
distinguished_name = dn
x509_extensions = v3_ca

[ dn ]
C = DE
O = RDP Secure Access
CN = RDP Secure Access Root CA

[ v3_ca ]
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer
basicConstraints = critical, CA:true
keyUsage = critical, keyCertSign, cRLSign
EOF


4. Root-CA mit 10 Jahren Laufzeit erstellen

sudo openssl genrsa -out /opt/rdp-ca/private/rdp-secure-access-root-ca.key 4096
sudo openssl req -x509 -new -nodes -key /opt/rdp-ca/private/rdp-secure-access-root-ca.key -sha256 -days 3650 -out /opt/rdp-ca/certs/RDP-Secure-Access-Root-CA.cer -config /opt/rdp-ca/root-ca.cnf

Die Datei, die du später den Windows-Usern gibst, ist:

/opt/rdp-ca/certs/RDP-Secure-Access-Root-CA.cer

Der private Key bleibt geheim:

/opt/rdp-ca/private/rdp-secure-access-root-ca.key


5. Konfiguration für das RDP-Signing-Zertifikat erstellen

Der sichtbare Name im Windows-Dialog kommt aus dem Zertifikat, daher setze ich hier:

CN = RDP Secure Access


sudo tee /opt/rdp-ca/rdp-signer.cnf >/dev/null <<'EOF'
[ req ]
default_bits = 4096
prompt = no
default_md = sha256
distinguished_name = dn
req_extensions = v3_req

[ dn ]
C = DE
O = RDP Secure Access
CN = RDP Secure Access

[ v3_req ]
basicConstraints = critical, CA:false
keyUsage = critical, digitalSignature
extendedKeyUsage = critical, codeSigning
subjectKeyIdentifier = hash
EOF


Ein Code-Signing-EKU ist hier wichtig; mehrere aktuelle Anleitungen und Fehlerberichte weisen darauf hin, dass ein normales TLS-Zertifikat für .rdp-Dateisignatur nicht ausreicht und Code Signing als EKU benötigt wird.


6. RDP-Signing-Zertifikat mit 10 Jahren erstellen

sudo openssl genrsa -out /opt/rdp-ca/private/rdp-secure-access-signer.key 4096


sudo openssl req -new -key /opt/rdp-ca/private/rdp-secure-access-signer.key -out /opt/rdp-ca/csr/rdp-secure-access-signer.csr -config /opt/rdp-ca/rdp-signer.cnf


sudo openssl x509 -req -in /opt/rdp-ca/csr/rdp-secure-access-signer.csr -CA /opt/rdp-ca/certs/RDP-Secure-Access-Root-CA.cer -CAkey /opt/rdp-ca/private/rdp-secure-access-root-ca.key -CAcreateserial -out /opt/rdp-ca/certs/RDP-Secure-Access-Signer.cer -days 3650 -sha256 -extfile /opt/rdp-ca/rdp-signer.cnf -extensions v3_req



7. Thumbprint für Registry-Datei ermitteln

Windows braucht den SHA1-Thumbprint des Signer-Zertifikats, nicht den Thumbprint der Root-CA.

openssl x509 -in /opt/rdp-ca/certs/RDP-Secure-Access-Signer.cer -noout -fingerprint -sha1 | cut -d= -f2 | tr -d ':'


Beispielausgabe:

A1B2C3D4E5F60718293A4B5C6D7E8F9012345678


Diesen Wert brauchst du gleich in der .reg.

Microsofts Policy heißt „Specify SHA1 thumbprints of certificates representing trusted .rdp publishers“. Wenn ein .rdp-File mit einem Zertifikat signiert ist, dessen SHA1-Thumbprint in dieser Liste steht, soll der Benutzer beim Start keine Warnmeldung bekommen.


8. Beispiel-Registry-Datei für Windows-Clients

Auf Ubuntu erzeugen:

SIGNER_THUMBPRINT="$(openssl x509 -in /opt/rdp-ca/certs/RDP-Secure-Access-Signer.cer -noout -fingerprint -sha1 | cut -d= -f2 | tr -d ':')"


sudo tee /opt/rdp-ca/out/RDP-Secure-Access-Client-Trust.reg >/dev/null <<EOF
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
"AllowSignedFiles"=dword:00000001
"TrustedCertThumbprints"="$SIGNER_THUMBPRINT"
EOF


Die fertige Datei liegt dann hier:

/opt/rdp-ca/out/RDP-Secure-Access-Client-Trust.reg


Diese .reg muss auf dem Windows-Client als Administrator importiert werden.

Zusätzlich muss die Root-CA auf dem Client installiert werden:

RDP-Secure-Access-Root-CA.cer
→ Lokaler Computer
→ Vertrauenswürdige Stammzertifizierungsstellen


Optional kannst du auch das öffentliche Signer-Zertifikat mitgeben:

RDP-Secure-Access-Signer.cer
→ Lokaler Computer
→ Vertrauenswürdige Herausgeber


Der zentrale Punkt bleibt aber: Root-CA vertraut + Signer-Thumbprint in TrustedCertThumbprints.


9. Eine RDP-Datei auf Ubuntu signieren

Beispiel:

cp /pfad/zur/original.rdp /opt/rdp-ca/out/test.rdp


Signieren:

rdpsign /opt/rdp-ca/out/test.rdp /opt/rdp-ca/out/test-signed.rdp /opt/rdp-ca/certs/RDP-Secure-Access-Signer.cer -k /opt/rdp-ca/private/rdp-secure-access-signer.key


Danach gibst du dem Benutzer nur noch:

test-signed.rdp


Nicht mehr die unsignierte Datei.


10. Wichtig: Datei nach dem Signieren nicht mehr verändern

Nach dem Signieren darfst du die .rdp-Datei nicht mehr ändern. Auch kleine Änderungen wie Zielhost, Username, Gateway, Drucker-Redirect oder Clipboard-Redirect machen die Signatur ungültig.

Ablauf also immer:

1. .rdp vollständig erzeugen
2. .rdp signieren
3. signierte .rdp ausliefern



11. Dateien, die du den Windows-Usern bereitstellst

Minimal:

RDP-Secure-Access-Root-CA.cer
RDP-Secure-Access-Client-Trust.reg


Optional zusätzlich:

RDP-Secure-Access-Signer.cer


Die privaten Keys bleiben ausschließlich auf dem Server:

/opt/rdp-ca/private/rdp-secure-access-root-ca.key
/opt/rdp-ca/private/rdp-secure-access-signer.key


Diese Dateien niemals an Kunden geben.


12. Auf einem Windows-Client installieren

certutil -addstore -f Root "RDP-Secure-Access-Root-CA.cer"
certutil -addstore -f TrustedPublisher "RDP-Secure-Access-Signer.cer"
reg import "RDP-Secure-Access-Trust.reg"

 

13. Test auf einem Windows-Client

Nach Import von Zertifikat und .reg:

gpupdate /force


Dann mstsc.exe vollständig schließen und die signierte .rdp öffnen.

Wenn alles passt, sollte als Herausgeber erscheinen:

RDP Secure Access


Und die wiederkehrenden Warnungen für die signierte .rdp-Datei sollten verschwinden beziehungsweise die in der .rdp gesetzten Umleitungen wie Zwischenablage und Drucker sollten wieder greifen. Microsofts offizielles rdpsign.exe überschreibt beim Signieren die Eingabedatei; das Linux-Tool erzeugt stattdessen eine separate Ausgabedatei.


Möchte ich ein 14" oder ein 16" Notebook?

Es gibt Notebooks in vielen verschiedenen Größen und Ausrichtungen.

Hier im Unternehmen gibt es zwei Standardgeräte. Eines mit einem 14" Bildschirm und eines mit einem 16" Bildschirm.

Der Unterschied beträgt in der Diagonale nur 5 cm. Diese fühlen sich unterwegs aber größer an. Auch die 0,4 kg Gewicht fühlen sich unterwegs schwerer an.

Die Geschwindigkeit, Speicher und Anschlüsse der Geräte sind identisch.

Zu jedem Notebook gibt es eine Dockingstation. Diese wird mit einem (1) USB Kabel mit dem Notebook verbunden. 2 Monitore, Netzwerk, Strom und alle USB Geräte werden an die Dockingstation angeschlossen.


14" Notebook 16" Notebook


14z.png

16z.png

Info Das Notebook ist leichter und damit mobiler.
Man kann es besser transportieren und schneller aufbauen oder in die Hand nehmen.
Das Notebook ist größer und schwerer. 
Man kann damit besser über einen längeren Zeitraum arbeiten wenn man genug Platz hat.
Externe Geräte 2 Monitore, Tastatur, Maus, Headset, Webcam, Drucker 2 Monitore, Tastatur, Maus, Headset, Webcam, Drucker
Vorteile Leichter und kleiner. Alles auf dem Bildschirm ist 15% größer.
Die Tastatur hat einen Nummernblock.
Nachteile Alles auf dem Bildschirm ist 15% kleiner.
Die Tastatur hat keinen Nummernblock.
Schwerer und größer.
Gewicht 1,59 kg

1,91 kg - (20% mehr Gewicht)

Bildschirm-Diagonale 35,6 cm

40,6 cm - (14% mehr Fläche)

Maße (BxTxH) 31,4 x 22,6 x 2,29 cm

35,7 x 25,3 x 2,48 cm - (38% mehr Volumen)