Zum 14. April 2026 (Patchday) hat Microsoft eine Korrektur am Remote Desktop vorgenommen, um RDP-Verbindungen besser gegen Phishing-Angriffe zu schützen. Die Anwender bekommen beim Aufbau der RDP-Verbindung eine Warnmeldung angezeigt. Das sorgt für reichlich Irritationen und Probleme. Hier eine Nachlese samt Überblick über diesen Sachverhalt einschließlich Workarounds.
Remote Desktop-Änderungen durch April 2026-Updates
Zum 14. April 2026 (zweiter Dienstag im Monat, Patchday bei Microsoft) wurden verschiedene kumulative Updates für die unterstützten Versionen aller Windows-Clients und Windows Server freigegeben. In den Änderungsmitteilungen der April 2026-Updates findet sich folgende Passage:
[Remote Desktop] This update improves protection against phishing attacks that use Remote Desktop (.rdp) files. When you open an .rdp file, Remote Desktop shows all requested connection settings before it connects, with each setting turned off by default. A one-time security warning also appears the first time you open an .rdp file on a device.
Dieser Sachverhalt wurde kurz in den Blog-Beiträgen Patchday: Windows 10/11 Updates (14. April 2026) und Patchday: Windows Server-Updates (14. April 2026) von mir erwähnt.
Microsoft erklärt die RDP-Änderung
Eine RDP-Datei teilt der Remotedesktop Connection-App mit, wie eine Verbindung mit einem Remotecomputer hergestellt wird. Abhängig von den Einstellungen kann die Datei auch Teile des lokalen Geräts (Windows Client oder Windows Server freigeben, so dass z. B. ein Remote-Zugriff auf die Zwischenablage, Laufwerke oder die Kamera möglich ist. Was Anwendern oder Administratoren die Möglichkeit eröffnet, remote auf eine Windows-Maschine (z.B. wenn diese in einer virtuellen Maschine läuft) zuzugreifen, hat auch Risiken.
Böswillige Akteure missbrauchen diese Funktion, indem sie RDP-Dateien über Phishing-E-Mails versenden. Öffnet ein Opfer eine solche RDP-Datei, baut Windows im Hintergrund eine Verbindung mit einem Server bereit, der vom Angreifer gesteuert wird. Der Angreifer erhält so Zugriff auf lokale Ressourcen wie Dateien, Anmeldeinformationen und vieles mehr.
Einmalige Warnung bei RDP-Verbindungen
Microsoft beschreibt diese Risiken und Implikationen im Support-Beitrag Understanding security warnings when opening Remote Desktop (RDP) files. Aus Sicherheitsgründen wird beim ersten Öffnen einer RDP-Datei nach der Installation des April 2026-Updates ein Schulungsdialogfeld angezeigt. Es wird erläutert, was RDP-Dateien sind und warnt vor Phishing-Risiken.
Nachdem Nutzer die RDP-Dateiverbindungen in diesem Dialogfeld durch Markierung des Kontrollkästchens und über die OK-Schaltfläche zugelassen haben, wird die Warnung für das Nutzerkonto nicht mehr angezeigt.
Warndialogfeld vor dem Aufbau jeder RDP-Verbindung
Bei jedem Öffnen einer RDP-Datei zeigt Windows zukünftig ein Sicherheitsdialogfeld zur "Verbindungssicherheit", bevor eine Verbindung hergestellt wird. Das Dialogfeld zeigt die Adresse des Remotecomputers und ein Kontrollkästchen für jede lokale Ressource an, auf die die Datei zugreifen möchte. Der Zugriff auf alle diese Ressourcen ist standardmäßig deaktiviert – Anwender müssen die einzelnen Ressourcen explizit aktivieren.
Das Dialogfeld kann dem Benutzer von Windows in zwei verschiedenen Varianten angezeigt werden. Ist eine RDP-Datei nicht digital signiert (ist nicht überprüfbar, wer sie erstellt hat oder ob sie manipuliert wurde), wird obiges Sicherheitsdialogfeld angezeigt. Das Dialogfeld beinhaltet ein Banner mit dem Titel Caution: Unbekannte Remoteverbindung und legt das Feld Publisher auf "Unbekannter publisher" fest. Dies ist dann ein Hinweis, besonders vorsichtig zu sein und den Absender der RDP-Datei zu prüfen.
Bei einer digital signierten RDP-Datei erscheint das Dialogfeld mit der Sicherheitswarnung mit dem nachfolgend gezeigten Banner. Dort wird angegeben, wer die RDP-Datei ausgestellt hat und welche Verbindung aufgebaut wird. Der Anwender muss dann bestätigen, dass er den Urheber überprüft hat und der Verbindung vertraut (Angreifer können auch digital signierte RDP-Dateien mit ähnlich klingenden Bezeichnungen missbräuchlich verteilen).
In beiden Fällen muss der Anwender aber die Kontrollkästchen der für die Remote Desktop-Versionen zulässigen Ressourcen markieren, bevor er die Verbindung aufbauen kann.
Bei digital signierten RDP-Dateien lässt sich (angeblich) über ein Kontrollkästchen einstellen, dass Windows die Auswahl für alle künftigen Verbindungen dieses Publishers beibehält. In diesem Kommentarthread schreiben Nutzer aber, dass selbst bei signierten RDP-Dateien kein "schnelles Verbinden" mehr möglich sei. Es erscheint immer ein Fenster, in dem die gewünschten Ressourcen über Kontrollkästchen auszuwählen sind. Das wird von anderen Lesern bestätigt.
Große Verunsicherung der Anwender
Die durch Microsoft durchgeführte Änderung hat zu ziemlicher Verunsicherung der Anwender geführt. In den Kommentaren zum Blog-Beitrag Patchday: Windows Server-Updates (14. April 2026) gibt es zahlreiche Rückmeldungen von Administratoren. SArmstrong schrieb:
Hat uns (fast) die halbe Firma lahmgelegt. Endanwender denken da sei ein Virus auf dem System und der übliche Kram. Diejenigen die sich einfach durchklicken sind mir da lieber. Es bringt auch überhaupt keinen Mehrwert. Für Enterprise-Umgebungen absolut nicht hinnehmbar.
Auch die Kommentare zum Blog-Beitrag Patchday: Windows 10/11 Updates (14. April 2026) greifen das Thema auf. Auf Facebook ist mir in einer Gruppe die nachfolgende Meldung untergekommen, und es wurde auf meine Blog-Beiträge verwiesen.
Den Kommentaren auf Facebook zufolge hat es auch bei vielen DATEV-Kunden, die die Smartcard in den Sitzung verwenden, einen Riesenstress verursacht. Weitere Diskussionen gibt es auf administrator.de in diesem Thread sowie in diesem Thread. Es lässt sich festhalten, dass diese Änderung einige Verwirrung bei Administratoren und Anwendern hervorgerufen hat.
Workarounds für Administratoren
Von Microsoft wird im Support-Beitrag Understanding security warnings when opening Remote Desktop (RDP) files ja vorgeschlagen, dass IT-Abteilungen die RDP-Dateien digital signieren sollen, damit das Ganze besser abgesichert ist. Den Rückmeldungen hier im Blog entnehme ich aber, dass das Ganze a) schlecht durch Microsoft implementiert wurde, und b) Administratoren nach wegen suchen, diese Warndialoge vorerst zu deaktivieren. Microsoft hat im verlinkten Support-Beitrag den Workaround genannt, um die Warnung temporär abzuschalten. Dazu ist der Registrierungseditor über Als Administrator ausführen aufzurufen. Anschließend ist im Registrierungsschlüssel:
HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services\Client
der 32-Bit-REG_DWORD Wert RedirectionWarningDialogVersion einzutragen und auf 1 zu setzen. Microsoft behält sich aber vor, diesen Mechanismus zu einem späteren Zeitpunkt zu entfernen, so dass der Registrierungseintrag nicht mehr greift.
In diesem Kommentar hier im Blog wird noch ein weiterer Schlüssel genannt, der mit folgendem PowerShell-Befehl:
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Terminal Server Client" -Name "AuthenticationLevelOverride" -Value 0gesetzt werden kann, um die Warnung Benutzer-spezifisch temporär zu deaktivieren. Derzeit ist aber unklar, ob das noch wirkt.
Auch in diesem Kommentar von Fred werden Registry-Einträge zum Unterdrücken der Meldung samt Anforderungen diskutiert.
Auf reddit.com gibt es noch diesen Post, der sich mit der digitalen Signierung von RDP-Dateien befasst und einen weiteren 32-Bit DWORD-Registrierungseintrag RdpLaunchConsentAccepted = 1 unter dem Schlüssel:
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Clientbeschreibt, um mit der Warnung umzugehen. Dieser Ansatz wird auch von Marc-André Moreau in diesem Tweet genannt.
Auf X ist mir noch nachfolgender Tweet von Marc-André Moreau untergekommen, der sich ebenfalls mit der Thematik auseinander setzt, und den ich Administratoren in Unternehmensumgebungen ans Herz legen möchte.
Wer den obigen Dialog beim Starten von RDP-Dateien, der nach dem letzten Windows-Update erscheint, nicht mehr sehen möchte, kann auch ohne Änderungen an den Registrierungsschlüsseln zum Ziel kommen. Marc-André Moreau verweist auf die auf GitHub abrufbaren Microsoft RDP Extensions (MsRdpEx) von Devolutions. Ich habe es selbst nicht getestet, aber mit den Extensions sollen sich die Warndialoge verhindern lassen.
Ähnliche Artikel:
Microsoft Security Update Summary (14. April 2026)
Patchday: Windows 10/11 Updates (14. April 2026)
Patchday: Windows Server-Updates (14. April 2026)
Patchday: Microsoft Office Updates (14. April 2026)
MVP: 2013 – 2016
Bei uns kann man die Ausnahme nicht mehr erstellen er will das CERT importiert haben! Oder er will manuell in der REG:
reg add "HKCU\Software\Microsoft\Terminal Server Client" /v AuthenticationLevelOverride /t REG_DWORD /d 0 /f
code:
try {
# HKLM (systemweit für alle Benutzer) – empfohlen
$PathHKLM = "HKLM:\SOFTWARE\Microsoft\Terminal Server Client"
if (-not (Test-Path $PathHKLM)) {
New-Item -Path $PathHKLM -Force | Out-Null
}
Set-ItemProperty -Path $PathHKLM -Name "AuthenticationLevelOverride" -Value 0 -Type DWord -Force -ErrorAction Stop
# Optional: auch für aktuellen User (HKCU)
$PathHKCU = "HKCU:\Software\Microsoft\Terminal Server Client"
if (-not (Test-Path $PathHKCU)) {
New-Item -Path $PathHKCU -Force | Out-Null
}
Set-ItemProperty -Path $PathHKCU -Name "AuthenticationLevelOverride" -Value 0 -Type DWord -Force
– Das "try {" ist überflüssig.
– es fehlt eine geschweifte Klammer zu ("}") am Ende, falls man "try {" benutzt.
– try ohne catch ist sinnlos
yo ich hab nur das "Beispiel" snipplet rauskopiert, danke , war nicht abgeschlossen ;)
Naja, in Unternehmensumgebungen sollte Phishing mit .rdp Dateien aus fremden Quellen nicht möglich sein.
Die sollte schon der Spamproxy aus den Mails herausfiltern.
Und genau das passiert hier in der Firma:
Alle ausführbaren Dateien wie z.B. .exe, .com, .vbs, .bat, etc. etc. und auch .rdp entfernt der Spamproxy aus Emails, auch aus denen, die nicht im Spamfilter hängen bleiben.
Und auch alle Officedokumente mit Makros, und PDFs mit Javascript, etc.
Ein Phishing mit .rdp Dateien ist hier also schon organisatorisch nicht möglich.
Und die Microsoft-Geschichte ist keine Lösung, sondern nur Augenwischerrei.
Ein DAU klickt eh immer alles an und fühlt sich durch solche Dialoge höchstens genervt. Lesen, was da steht, tut er nicht. Und erst Recht nicht darüber nachdenken.
Wie so oft ist nicht die .rdp das Problem, sondern die Person vor dem Bildschirm.
"Ein DAU klickt eh immer alles an und fühlt sich durch solche Dialoge höchstens genervt. Lesen, was da steht, tut er nicht. Und erst Recht nicht darüber nachdenken."
DAS ist der Punkt .. es ist neu und verstehen können Sie es auch nicht. Mal ehrlich gesprochen .. die wollen nur, das es per DoppelKlick funktioniert und am Besten transparent. Wir als IT können da nicht gewinnen.
"Augenwischerei seitens Microsoft" finde ich treffend.
Meine Erfahrung bei der Beschäftigung mit dem Thema ist ebenfalls die, dass bei einer signierten RDP Datei die Meldung "Vorsicht: Unbekannte Remoteverbindung" verschwindet und man stattdessen die Warnung "Bestätigen Sie den Herausgeber dieser Remoteverbindung" erhält.
Das Häkchen unten links setzen bewirkt nur, dass die gewählten Einstellungen bzgl. "Zwischenablage", "Drucker", etc. beim nächsten Aufruf gemerkt werden und der Haken dann bereits gesetzt ist. "Bestätigen Sie den Herausgeber" kommt weiterhin bei jedem Aufruf der RDP-Datei.
Ich habe auch Tests gemacht, explizit ein "Code Signing" Zertifikat zum Signieren der RDP-Datei zu verwenden und dies auch im Client Zertifikatspeicher "Vertrauenswürdige Herausgeber" zu hinterlegen.
Keine Änderung.
Das einzige, was die Meldungen bislang komplett verschwinden lässt ist es, zusätzlich noch den Reg Key am Client zu setzen:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
TrustedCertThumbprints (Reg_SZ) und da den Thumbprint des Zertifikats zu hinterlegen.
Dann war wirklich Ruhe. Aber irgendwie erscheint mir das nicht als die Richtige Lösung für dieses neue Sicherheitsfeature zu sein.
Doch, das ist EXAKT die richtige Lösung.
Administrative Vorlagen\\Windows-Komponenten\\Remotedesktopdienste\\Remotedesktopverbindungs-Client\\SHA1-Fingerabdrücke von Zertifikaten angeben, die vertrauenswürdige RDP-Herausgeber darstellen
Client nicht in der Domäne und signierte RDP-Datei(en) – Lösungsmöglichkeiten:
Direkt auf dem Client in der Gruppenrichtlinie „SHA-1-Fingerabdrücke von Zertifikaten angeben, die vertrauenswürdige RDP-Herausgeber darstellen" (Specify SHA1 Thumbprints of certificates representing trusted .rdp publishers) den SHA-1-Fingerabdruck des Herausgeberzertifikats eintragen.
Oder direkt diesen Registry-Eintrag erstellen:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]
"TrustedCertThumbprints"="SHA-1-Fingerabdruck des Herausgeberzertifikats"
(Typ REG_SZ, mehrere Zertifikate Komma getrennt eintragen).
Letzteres eignet sich gut, wenn die Client mit einer Geräteverwaltungssoftware verwaltet werden.
UND in beiden Fällen muss das CA-Root-Zertifikat der CA die das Herausgeberzertifikat signiert hat auf dem Client vorhanden sein. Falls nicht, muss dies auch über die Geräteverwaltung verteilt werden. Fehlt das CA-Root-Zertifikat wird die RDP-Datei als unsigniert betrachtet auch wenn der Fingerabdruck des Herausgeberzertifikats in der Registry eingetragen ist.
Nachdem heute früh zum ersten mal die Sicherheitswarnung beim Aufbau einer RDP-Verbindung aufkam (Doppelklick auf gespeicherte RDP-Datei) musste ich anschließend feststellen, dass mein Yubikey nicht mehr über die RDP-Verbindung durchgereicht wurde. Das passiert auch dann, wenn in der neuen Sicherheitsabfrage explizit noch einmal die Hardware zum durchreichen ausgewählt wurde. Die Auswahl scheint hier nicht richtig zu greifen – oder zumindest nicht für den Yubikey.
Entsprechende Versuche zeigten, dass der Yubikey bei manuell initiierten RDP-Verbindung per mstsc sofort klaglos durchgereicht wurde und nur bei der gespeicherten RDP-Verbindung nicht funktioniert.
Glücklicherweise bringt das deaktivieren der Sicherheitswarnung über den o.a. Registry-Key den erwünschten Erfolg. Der Start der RDP-Verbindung über die RDP-Datei erzeugt keine Nachfrage mehr und der Yubikey wird wieder durchgereicht. Fragt sich nur, wie lange noch… :(
Hast Du hier nicht 2 Themen vermengt? Die allgemeine Warnung ist neu ja – da kann man über die Aussagen auch streiten. Der komplette (größere Part) ist aber nichts als die übliche Cert-Warnung, wenn man keine eigenes PKI und in seinem AD auch kein Cert-Autoenrolling eingerichtet hat. Eine eigene PKI mit CA ist mit jedem Linux schnell hochgezogen. In den meisten freien und unfreien Firewalls meist integriert. Das Autoenrolling im AD per GPO schon etwas aufwändiger, sollte aber zum Handwerk eines jeden Admins gehören.
Bei der Sache erwähnenswert: Mein Pentesting Tool Clipboard-Auditor, der (Text)Inhalte der Zwischenablage in eine kleine Textdatei, pollt wurde noch nie von einem Schlangenöl als Schadsoftware identifiziert, insbesondere nicht, wenn dieser direkt am betroffenen Rechner compiliert wurde.
https://codeberg.org/tomas-jakobs/clipboard-auditor
Wieso, sorgt der Remote Desktop-Phishing-Schutz jetzt für Verwirrung?
Wenn man Microsoft ein bisschen kennt, weiß man doch das Microsoft nicht erst seit letztem Jahr ein paar Probleme hat, der ersten Hinweistext bekam ich auch heute Morgen nach dem Update auch erst in Englisch und den Zweiten dann in Deutsch, obwohl der Server mit dem ich mich verbunden habe, ein Deutscher ist. Aber nur so kennt man diese Firma.
Wenn man überlegt, wie einfach (vor dieser Änderung) auf diese Weise Zugriffe auf Laufwerke des Opfers erreicht werden konnte, wird man schwach. Sobald ich Adminrechte auf dem Angriffs-RD-Host habe, kann ich sofort im Namen des Opfers den Autostart der Opfer mit bösen Skripten beschreiben lassen – auf deren Platte via \\tsclient\c\users\… Selbst, wenn die sich sofort wieder abmelden ist da schon was platziert. Diese Maßnahme ist richtig, wie ich finde.
Dass es vorher Nutzern überlassen wurde, sich mit unsignierten .rdp-Dateien ohne dauerhaft bestehende Warnung zu verbinden, war riskant.