Informationen
- Änderung bei RDP-Dateien durch Microsoft-Updates ab April 2026
- RDP-Dateien unter Ubuntu signieren
- Möchte ich ein 14" oder ein 16" Notebook?
Ä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:
- Einmaliger Erklärdialog beim ersten Öffnen einer
.rdp-Datei - 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
Screenshot - Sicherheitswarnung vor jeder RDP-Verbindung - Kein Zertifikat - Kein Reg-Schlüssel
Screenshot - Sicherheitswarnung vor jeder RDP-Verbindung - Mit Zertifikat - Kein Reg-Schlüssel
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:
- https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings
- https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/rdpsign
- https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-admx-terminalserver
- https://support.microsoft.com/en-gb/topic/windows-11-version-25h2-update-history-99c7f493-df2a-4832-bd2d-6706baa0dec0
- https://support.microsoft.com/en-gb/topic/april-14-2026-kb5083769-os-builds-26200-8246-and-26100-8246-22f90ae5-9f26-40ac-9134-6a586a71163b
- https://support.microsoft.com/en-us/topic/may-12-2026-kb5089549-os-builds-26200-8457-and-26100-8457-28ec2a99-4bbe-481d-a340-5c6cf18d9acb
- https://support.microsoft.com/de-de/topic/21-m%C3%A4rz-2026-kb5085516-betriebssystembuilds-26200-8039-und-26100-8039-out-of-band-09e85404-1cb6-4ed4-9ca5-3e40d74307b9
- https://github.com/nfedera/rdpsign
- https://gpsearch.azurewebsites.net/default.aspx?lang=en-US&policyid=2540
- https://gpedit.tplant.com.au/en-us/policy/TerminalServer/TS_CLIENT_TRUSTED_CERTIFICATE_THUMBPRINTS_2/
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 | |
|
|
||
| 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) |