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. Ergänzung: Scheint alles mit heißer Nadel gestrickt zu sein, wie ein Blog-Leser durch Screenshots belegt.
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.
Fail bei der "Gateway-Klippe"
Ergänzung: Blog-Leser Heiko P. hat mir zum 16. April 2026 noch einen weiteren Hinweis geliefert, dass der April 2026-Patch bezüglich der RDP-Problematik "mit heißer Nadel gestrickt zu sein scheint" (danke für die Insights). Heiko schrieb mir:
Bezüglich der neuen Sicherheitsmeldungen beim Öffnen von RDP-Dateien (.rdp) ist mir noch ein peinlicher Fail von Microsoft aufgefallen. Vielleicht ist das für Ihren Blog von Interesse…
Obwohl in seiner Umgebung kein RDP-Gatewayserver für die RDP-Verbindung verwendet wird, ist in der Sicherheitswarnung der Gateway-Server enthalten (siehe Screenshoots).
Das geht dann natürlich auch in nachfolgendem Warndialog schief, wo eine RDP-Verbindung zu einem nicht vorhandenen Gateway aufgelistet wird. Damit wird die Warnung vor einer unbekannten Remoteverbindung völlig absurd.
Heiko schrieb, dass er den verwaisten Eintrag "office…" für den Gatewayserver auch nicht mit dem RDP-Client via GUI (mstsc) entfernen könne. Egal was er versuchte, der Eitnrag taucht immer wieder auf. Nur ein Bearbeiten der RDP-Datei via Editor (löschen von "gatewayhostname:") hat beim Leser geholfen.
Der Leser merkt an, dass der Gateway-Eintrag aus einer vor 2 Jahren kopierten (neuer Job) Default.rdp-Datei stamme, also eine echte Leiche sei. Für den Leser sieht es so aus, als würde der Code zur Absicherung bei der "Prüfung" nur nachschaut, welche Einträge in der RDP-Datei stehen, statt zu prüfen, welche Verbindungseinstellungen tatsächlich genutzt werden. Der Schluss, den Heike zieht: "Dann kann Microsoft das mit der Prüfung auch sparen, wenn nicht einmal die Warnmeldung korrekt ist."
Der Nutzen des Ganzen ist, so der Leser, eh sehr fraglich. Denn die Prüfung gewöhnt die User nur daran, Warnmeldungen zu ignorieren und überfordert sie mit der Ressourcen-Auswahl.
Wenn Microsoft Phishing bei RDP-Verbindungen als Sicherheitsrisiko ansieht, dann brauche es für Administratoren eine Möglichkeit, vertrauenswürdige Verbindungen automatisch herzustellen. Heiko schrieb: "Von mir aus gern mit Signatur und GPO für trusted connections". Bei den Cloud-Diensten gehe das ja auch.
Zum Hintergrund schreibt Heiko: "Wir verwenden bei uns RDP-Dateien im Autostart an den BDE-Stationen in der Produktion. Ehrlich gesagt, sind wir froh, dass die Kollegen die Terminals alleine einschalten können. Es ist halt nicht jeder Mitarbeiter IT-affin. Das ist absolut nicht abwertend gemeint, es kann ja auch nicht jeder Mensch auf der Welt einen Bagger fahren der ein Loch braucht." Zeit erneut, wie weit Microsofts Entwickler inzwischen von der Praxis entfernt sind. Ob das AI-Slop im Spiel ist?
Ergänzung 2: In nachfolgendem Kommentar von ChristopH, sowie in diesem Kommentar bei administrator.de haben Leute beschrieben, wie sie das mit der digitalen Signatur für die .RDP-Datei gelöst haben.
Ä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)
Remote Desktop-Phishing-Schutz im April 2026-Update verursacht Verwirrung
Windows 11 April 2026-Updates (KB5083769, KB5082052) triggern BitLocker Recovery
Windows Server 2025: Update KB5082063 liefert Error 0x800F0983, 0x80073712
Windows Server 2025: Fehler 0x80073712 bei KB5082063 durch Media Player-Sprachpakete
Windows Server 2016-2025: Reboot von Domain Controllern durch April 2026-Update (KB5082063 etc.)
Windows April 2026-Updates verursachen Anmelde-Probleme
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 ;)
Ist das Zertifikat als Vertrauenwürdiger Herausgeber im MaschinenSpeicher hinterlegt und ist die Kette als Trusted hinterlegt (Stammzert./Zwischenzert)?
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.
RDP-Dateien müssen nicht über den Weg einer Mail zum User finden. Und da in der Regel mindestens https-Verbindungen nicht geblockt werden, könnte dann ein Server im Internet angesteuert werden.
Phishing mit Mailanhängen? Gibt es so etwas noch? Schon einmal etwas von Hyperlinks oder Hatetepe-es gehört? Das ist der neue heiße Scheiß.
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
Danke, genau das habe ich gesucht, aber auf keiner Microsoft-Seite zu dem Thema gefunden. Dabei ist es aus meiner Sicht auch sicherer, als die Anwender mit nervigen Warnung noch mehr abstumpfen zu lassen.
ich habe da so mein Problem damit das richtige Zertifikat zu finden, zum einen habe ich den Workarround von frankys web (https://www.frankysweb.de/windows-pki-zertifikate-fuer-rdp-verbindungen-automatisch-ausrollen/) umgesetzt, das scheint auch insofern zu funktionien, dass sich der Client ein Zertifikat holt aber ob das nun wirklich für die RDP Session verwendet wird ist mir unklar. Irgenwie komme ich da nicht weiter, kann mir jemand helfen? Der Ansatz hier von EinerVonVielen scheint Mehrwert zu haben :-)
Die Anleitung von Franky beschreibt das Zertifikat, das zum Absichern der Kommunikation mit den RDSH verwendet wird (= das ist ein Transportzertifikat).
Bei dieser Sache mit den April Updates geht es aber darum, dass die RDP Datei gegen Veränderungen geschützt wird.
Die RDP Datei wird konfiguriert und dann wird sie mit einem Zertifikat signiert. Jede nachträgliche Änderung an der Datei steht dann im Widerspruch zur Signierung und ruft einen Fehler hervor.
Meinem Verständnis nach wird nach den April Updates nun geprüft, dass a) die RDP Datei signiert ist und b) dass die Datei nicht verändert wurde im Vergleich zu dem Zustand bei Signierung.
Das ist einfach zu bewerkstelligen über RDPSIGN:
https://learn.microsoft.com/de-de/windows-server/administration/windows-commands/rdpsign
Der Befehl existiert auf jedem aktuellen Windows Client- und Serverbetriebssystem.
rdpsign /sha256 [Thumbprint eines Zertifikats das auf dem System installiert ist, von dem aus die Datei signiert wird] NamederDatei.rdp
Ich habe nicht klären können, ob man hierfür ein beliebiges gültiges SSL Zertifikat nehmen kann oder ob es dediziert ein Zertifikat mit dem Zweck "CodeSigning" sein muss. Ich vermute, es muss ein Code Signing Zertifikat sein, denn ein "normales" SSL Zertifikat hat ja in der Regel nur die erweiterte Schlüsselverwendung "Server Authentication", was als Zweck ja nicht mit der Signierung einer Datei übereinstimmt.
Dieses CodeSigning Zert kann man sich aber auch über eine lokale AD CA ausstellen lassen, dies geht im Prinzip über den Weg, der auf den Bildern 2 und 3 der Franky Anleitung dargestellt ist. Man kopiert hier das Template "Code Signing" und stellt auf der Basis ein Zertifikat aus.
Nachdem meine RDP-Testdatei damit signiert war, hat sich die erste Fehlermeldung "Vorsicht: Unbekannte Remoteverbindung" nicht mehr gezeigt, es kam dann nur noch die Warnung "Bestätigen Sie den Herausgeber dieser Remoteverbindung".
Es hat hier offenbar nicht ausgereicht als Bestätigung der Remoteverbindung, dass der Client dem Code Signing Zertifikat vertraut (weil es ein Child Zert des privaten AD Root CA Zerts ist).
An dieser Stelle habe ich dann den Reg Key (oder eben über die besagte GPO) gesetzt und dann kamen gar keine Meldungen mehr.
Ich konnte das Thema also letztlich nicht für mich zufriedenstellend und zweifelsfrei klären, ob es eigentlich so sein sollte, dass der RDP Datei vertraut wird, wenn sie über ein valides Zert signiert ist oder ob hier noch irgendwas fehlt.
Ich habe beim Test auch dafür gesorgt, dass das Zert mit dem die RDP Datei signiert ist auf den Clients im Zert Speicher "Vetrauenswürdige Herausgeber" installiert wird. Das hat die Warnmeldung auch nicht beseitigt. Der Reg Key hat dies getan.
Ich würde mir von Microsoft hier eine etwas ausführlichere Dokumentation zu dem Thema wünschen. Es gibt diesen Artikel hier:
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings
Dort steht ja eigentlich im Abschnitt "RDP files with a verifiable publisher", dass die Warnung nach Signieren der RDP Datei mit einem korrekten Zertifikat dann diese Warnmeldung hervorruft. In dem Artikel steht aber nicht explizit drin, was man damit dann anfangen soll.
Man könnte rauslesen, wenn man es so will, dass die Warnmeldung das gewünschte Zielergebnis ist und die Anwender dann jedes Mal eine bewusste Entscheidung treffen sollen.
Weiter heißt es in dem Artikel:
"Your IT department might configure your computer to trust specific publishers. When an RDP file is signed by a trusted publisher, the experience might differ based on your organization's policies."
=> Das, was das IT Department festlegt, könnte genau der Reg Key oder die GPO sein.
Ich habe mir mit Claude eine Anleitung schreiben lassen, damit verschwinden alle Warnmeldungen. Habe sie weiter unten gepostet.
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… :(
Gleiches galt hier bei einigen Kunden mit den Kartenlesern von ReinerSCT – nach setzen des Registry-Eintrags funktionierten die wieder.
Ich hoffe langsam, dass der Druck auf MS durch diesen Unfug gross genug wird, den Müll wieder abzuschalten…
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
Was empfiehlst du für die PKI? Habe einige Samba AD als Nachfolger von Windows AD und befasse mich demnächst mit dem Umzug/Ein ichten der PKI
Verstehe deine Frage nicht. Fragst Du nach einem Produkt?
Nimm das in jedem Linux enthaltene openSSL.
https://pki-tutorial.readthedocs.io/en/latest/simple/
Mittlerweile gibt es ja für fast alles schöne und sinnvolle Frontends (meist auf Docker-Basis), die im Kern zwar mit den Basictools arbeiten, aber eine schönere Userexpierence bieten – darum ging es mir. OpenSSL kenne ich und nutze ich, trotzdem danke für den Hinweis.
Die meisten Anwendungen, die SSL beherrschen müssen binden irgendeine Form von OpenSSL oder einen Fork davon (LibreSSL, BoringSSL) ein. Deswegen gibt es auch immer eine große Update-Welle, wenn in OpenSSL eine neue Lücke gefunden wird.
Es gibt aber auch unabhängige Implentierungen, neben Microsofts libCrypto z.B. GnuTLS. Auch fefe hatte sich mal an einer eigenständigen Implementation für seinen Webserver gatling versucht, kann die aber aus bekannten Gründen nicht pflegen.
Zu einer PKI gehört neben den der eigentlichen SSL-Bibliothek aber mindestens noch eine OCSP-Implementation und optimalerweise ein SCEP-Server, so wie es Microsoft mit seinen Zertifikatsdiensten implementiert.
Auch da gibt es Open-Souce-Alternativen wie etwa Smallstep oder Dogtag.
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.
Ich hatte den Sachverhalt vom Wortlaut des Patches auch falsch eingeschätzt.
Die Warnungen werden auch angezeigt, wenn man RDS WebApps über die RemoteApp- und Desktopverbindungen nutzt. Das ist dann schon wirklich blödsinnig, denn die werden ja in der Regel mit Group Policies verbunden.
Die Vermutung liegt nahe, dass die WebApps entweder versteckt als RDP-Dateien abgelegt sind oder zur Laufzeit erzeugt werden.
Was aber wirklich doof ist:
Der User kann da zur Kenntnis nehmen was er möchte, die Warnung kommt bei jedem einzelnen Aufruf immer wieder.
Ich hoffe Signieren wird's richten.
Ich werfe mal was anderes in den Raum, zum Thema "Schnell verbinden" und "bequemer Start einer RDP Verbindung"
Remote Guard kann eine gute Option für die Benutzer sein. [1]
Wir können die erste Nachfrage unterdrücken (RdpLaunchConsentAccepted), der Thumbprint des Herausgebers kann über die "SHA-1 Fingerprint" Policy verteilt werden.
Wer jetzt den Remote Guard erzwingt, der umgeht dann sogar noch die Network Level Authentication (NLA) und erhält eine SSO. Der aktuell angemeldete Benuzter wird direkt zum RDS durchgereicht.
CompKonf/AdmVorlagen/System/Delegierung von Anmeldeinformationen
Delegierung von Anmeldeinformationen an Remoteserver einschränken
[1]
Für Admins in der Praxis selten, da sie sich meist mit anderen Credentials zum Server verbinden. Das ist aber ein anderes Thema, das Fass machen wir hier jetzt nicht auf. :-)
Hallo Mark, könntest du das mal ein wenig ausführlicher schreiben, was im einzelnen zu tun wäre? Vielen Dank für deine Unterstützung LG Daniel
An welcher Stelle der Stichpunkte hast du Fragen?
Zertifikate erstellen, ohne PKI:
https://www.gruppenrichtlinien.de/artikel/selfsigned-certificate-selbsterstellte-pki-powershell-v5
oder https://www.gruppenrichtlinien.de/artikel/selfsigned-certificate-selbsterstelltes-zertifikat-makecertexe
Zertifikate verteilen
https://www.gruppenrichtlinien.de/artikel/zertifikate-verteilen
https://www.gruppenrichtlinien.de/artikel/remoteapp-zertifikatsfehler-sha1-fingerprint
Remote Guard
https://learn.microsoft.com/de-de/windows/security/identity-protection/remote-credential-guard
zzgl:
CompKonf/AdmVorlagen/System/Delegierung von Anmeldeinformationen
Delegierung von Anmeldeinformationen an Remoteserver einschränken
Bis hier ist alles eine Computer Richtlinie.
HKCU\Software\Microsoft\Terminal Server Client
RdpLaunchConsentAccepted muss in eine Benutzerrichtlinie. Darin kannst du auch die ShortCuts zu den auf einer Netzwerkshare bereitgestellten RDP Datei verteilen.
Gemäß https://learn.microsoft.com/de-de/windows/security/identity-protection/remote-credential-guard
greift die Funktion nicht bei Session-Broker und Remotedesktopgateway. Zitat "Remote Credential Guard wird nur für direkte Verbindungen zu den Zielcomputern unterstützt. Verbindungen über den Remotedesktop-Verbindungsbroker und das Remotedesktopgateway werden nicht unterstützt."…
"Zertifikate erstellen, ohne PKI:
https://www.gruppenrichtlinien.de/artikel/selfsigned-certificate-selbsterstellte-pki-powershell-v5
oder https://www.gruppenrichtlinien.de/artikel/selfsigned-certificate-selbsterstelltes-zertifikat-makecertexe"
Tertium datur!
Das geht seit Windows 7 dummerweise auch ohne PoserShell oder MAKECERT.exe mit Bordwerkzeug: siehe https://skanthak.hier-im-netz.de/certificate.html
RDP-Dateien auf Rechner ohne die Hilfe einer PKI für lokalen Gebrauch signieren –
Ich möchte auf meinem Entwicklungsrechner, der nicht in der Domäne ist, signierte RDP-Dateien erstellen können damit auch weiterhin Warnungen bei „fremden" RDP-Dateien angezeigt werden. Die Signatur der Datei muss nicht portabel sein. Nehme in Kauf diese Dateien nach dem kopieren auf einen anderen Rechner neu signieren zu müssen.
Fragt man die Google-Suche „generate publisher certificate for local machine" liefert einem die KI-Zusammenfassung folgende Befehle:
Step-by-Step Guide (Windows 10/11)
1. Open PowerShell as Administrator.
2. Generate Self-Signed Certificate: Run the following command, changing -Subject to your desired publisher name:
$cert = New-SelfSignedCertificate -Type CodeSigningCert -Subject "CN=MyLocalPublisher" -KeyUsage DigitalSignature -FriendlyName "Local Publisher" -CertStoreLocation "Cert:\LocalMachine\My"
3. Export Certificate to File: Create a .cer file for the certificate:
Export-Certificate -Cert $cert -FilePath "C:\Temp\LocalPublisher.cer"
4. Install Certificate to Trusted Stores: Import the certificate into Trusted Root and Trusted Publisher stores:
Import-Certificate -CertStoreLocation "Cert:\LocalMachine\Root" -FilePath "C:\Temp\LocalPublisher.cer"
Import-Certificate -CertStoreLocation "Cert:\LocalMachine\TrustedPublisher" -FilePath "C:\Temp\LocalPublisher.cer"
Den Fingerabdruck dieses Zertifikates trägt man dann zusätzlich mit gpedit.msc 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) direkt auf dem Rechner ein.
Die RDP-Dateien mit Hilfe von rdpsign mit dem erstellten Herausgeber-Zertifikat signieren. Dann ist für 1 Jahr Ruhe, dann läuft das erstellte Zertifikat ab.
Ergänzung:
Wenn man das Zertifikat, inkl. private Key, auf einem anderen Rechner importiert, anstelle dort ein neues zu erzeugen, kann man die signierten RDP-Dateien auch dort verwenden (GPO anpassen nicht vergessen). Im Sinne von „MyHomeLabPublisher"- oder „MyFamiliyPublisher"-Zertifikat.
Danke schön!
Für alle denen ein Jahr auch zu kurz ist:
Mit einem angehängten "-NotAfter (Get-Date).AddYears(y)" am Ende von "New-SelfSignedCertificate" kann man die Gültigkeit des Zertifikats auch auf y Jahre festlegen.
Hier eine Claude Anleitung im MD Format:
# RDP-Zertifikatsauthentifizierung im LAN – Komplettanleitung
Ziel: RDP-Verbindungen ohne Sicherheitswarnungen, auch wenn die RDP-Hosts nicht in der Domäne sind. Es werden drei Zertifikate benötigt:
1. **Root-CA** – die eigene Zertifizierungsstelle
2. **Server-Zertifikat** – pro RDP-Host eins, damit der Client die Identität des Servers prüfen kann
3. **Signing-Zertifikat** – zum Signieren der .rdp-Dateien, damit die "Unbekannter Herausgeber"-Warnung verschwindet
—
## Voraussetzungen
– Linux-Rechner mit OpenSSL 3.x
– Windows-Clients (Domäne mit GPO oder einzeln konfiguriert)
– RDP-Hosts (können außerhalb der Domäne sein, auch Windows 7)
—
## Teil 1: CA erstellen (einmalig, auf Linux)
"`bash
# Verzeichnisstruktur anlegen
mkdir -p ~/rdp-ca/{certs,newcerts,private}
cd ~/rdp-ca
touch index.txt
echo 1000 > serial
# CA-Schlüssel erzeugen (Passphrase >= 4 Zeichen!)
openssl genrsa -aes256 -out private/ca-key.pem 4096
# Root-Zertifikat erstellen (10 Jahre gültig)
openssl req -x509 -new -key private/ca-key.pem \
-days 3650 -out ca-root.crt -sha256 \
-subj "/CN=RDP-CA/O=MeineFirma"
"`
### OpenSSL-Konfiguration erstellen
"`bash
cat > openssl.cnf < **Wichtig:** Den Pfad bei `dir` an den eigenen Benutzer anpassen!
—
## Teil 2: Server-Zertifikat erstellen (pro RDP-Host)
Für jeden RDP-Host wiederholen. HOSTNAME und IP anpassen:
"`bash
cd ~/rdp-ca
# Key + CSR erzeugen
openssl req -new -newkey rsa:2048 -nodes \
-keyout HOSTNAME.key -out HOSTNAME.csr \
-subj "/CN=HOSTNAME"
# Mit der CA signieren (5 Jahre gültig)
SAN="DNS:HOSTNAME,IP:192.168.x.x" openssl ca \
-config openssl.cnf \
-extensions v3_rdp \
-in HOSTNAME.csr -out HOSTNAME.crt -notext
# PFX für Windows erstellen
# Für Windows 7: -legacy -descert ist PFLICHT (sonst "falsches Passwort")
# Für Windows 10/11: kann weggelassen werden
openssl pkcs12 -export -out HOSTNAME.pfx \
-inkey HOSTNAME.key -in HOSTNAME.crt \
-certfile ca-root.crt \
-legacy -descert
"`
> **Wichtig:** Der CN und der DNS-Eintrag im SAN müssen exakt dem Hostnamen oder der IP entsprechen, die im RDP-Client als Ziel eingegeben wird. Wenn per IP verbunden wird, muss die IP im SAN stehen.
### Server-Zertifikat auf dem RDP-Host installieren (Windows)
"`cmd
REM PFX importieren
certutil -importpfx C:\Pfad\HOSTNAME.pfx
REM Thumbprint anzeigen
certutil -store My
REM Thumbprint dem RDP-Listener zuweisen
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"
REM Dienst neu starten (in CMD, nicht PowerShell!)
net stop TermService & net start TermService
"`
In **PowerShell** den Dienst so neu starten (& funktioniert dort nicht):
"`powershell
net stop TermService
net start TermService
"`
### Prüfen ob alles korrekt zugewiesen ist
"`cmd
REM Zeigt den zugewiesenen Thumbprint
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Get SSLCertificateSHA1Hash
REM Zeigt Zertifikatdetails inkl. SAN
certutil -v -store My THUMBPRINT
"`
—
## Teil 3: Signing-Zertifikat erstellen (einmalig)
Dieses Zertifikat wird zum Signieren der .rdp-Dateien verwendet:
"`bash
cd ~/rdp-ca
openssl req -new -newkey rsa:2048 -nodes \
-keyout rdp-sign.key -out rdp-sign.csr \
-subj "/CN=RDP Signing/O=MeineFirma"
SAN="DNS:rdpsigning" openssl ca \
-config openssl.cnf \
-extensions v3_sign \
-in rdp-sign.csr -out rdp-sign.crt -notext
openssl pkcs12 -export -out rdp-sign.pfx \
-inkey rdp-sign.key -in rdp-sign.crt \
-certfile ca-root.crt \
-legacy -descert
"`
### Signing-Zertifikat auf dem Client installieren
"`cmd
REM PFX importieren (privater Schlüssel wird zum Signieren gebraucht)
certutil -importpfx rdp-sign.pfx
REM Thumbprint des Signing-Zertifikats anzeigen
certutil -store My "RDP Signing"
"`
### RDP-Datei signieren
"`cmd
rdpsign /sha256 SIGNING_THUMBPRINT "C:\Pfad\verbindung.rdp"
"`
Für Windows 7 als Client:
"`cmd
rdpsign /sha1 SIGNING_THUMBPRINT "C:\Pfad\verbindung.rdp"
"`
> **Hinweis:** Nach jeder Änderung der .rdp-Datei muss sie neu signiert werden!
—
## Teil 4: Verteilung per GPO
### 4a: Root-CA-Zertifikat verteilen
Damit alle Clients der CA vertrauen:
**Computerkonfiguration → Richtlinien → Windows-Einstellungen → Sicherheitseinstellungen → Richtlinien öffentlicher Schlüssel → Vertrauenswürdige Stammzertifizierungsstellen**
→ `ca-root.crt` importieren (nur das öffentliche Zertifikat, ohne privaten Schlüssel)
### 4b: Signing-Zertifikat als vertrauenswürdigen Herausgeber verteilen
Damit die Clients den RDP-Datei-Signierer kennen:
**Computerkonfiguration → Richtlinien → Windows-Einstellungen → Sicherheitseinstellungen → Richtlinien öffentlicher Schlüssel → Vertrauenswürdige Herausgeber**
→ `rdp-sign.crt` importieren (nur das öffentliche Zertifikat)
### 4c: Signing-Thumbprint als vertrauenswürdig konfigurieren
Damit die Bestätigungsmeldung komplett verschwindet:
**Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Remotedesktopdienste → Remotedesktopverbindungs-Client → "SHA1-Fingerabdrücke von Zertifikaten angeben, die vertrauenswürdige RDP-Herausgeber darstellen"**
→ Thumbprint des `rdp-sign.crt` eintragen
### Manuell (ohne GPO)
Falls ein Client nicht in der Domäne ist:
"`cmd
REM Root-CA vertrauen
certutil -addstore Root ca-root.crt
REM Signing-Zertifikat als vertrauenswürdigen Herausgeber hinzufügen
certutil -addstore TrustedPublisher rdp-sign.crt
REM Optional: Thumbprint per Registry
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" /v TrustedCertThumbprints /t REG_SZ /d "SIGNING_THUMBPRINT" /f
"`
—
## Teil 5: Neuen RDP-Host hinzufügen (Kurzfassung)
Wenn die CA und das Signing-Zertifikat bereits existieren:
### 1. Auf Linux – Zertifikat erstellen
"`bash
cd ~/rdp-ca
openssl req -new -newkey rsa:2048 -nodes \
-keyout HOSTNAME.key -out HOSTNAME.csr \
-subj "/CN=HOSTNAME"
SAN="DNS:HOSTNAME,IP:192.168.x.x" openssl ca \
-config openssl.cnf \
-extensions v3_rdp \
-in HOSTNAME.csr -out HOSTNAME.crt -notext
openssl pkcs12 -export -out HOSTNAME.pfx \
-inkey HOSTNAME.key -in HOSTNAME.crt \
-certfile ca-root.crt \
-legacy -descert
"`
### 2. Auf dem RDP-Host – Zertifikat installieren
"`cmd
certutil -importpfx HOSTNAME.pfx
certutil -store My
wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="THUMBPRINT"
net stop TermService
net start TermService
"`
### 3. Auf dem Client – RDP-Datei signieren
"`cmd
rdpsign /sha256 SIGNING_THUMBPRINT "verbindung.rdp"
"`
Fertig – keine Warnungen mehr.
—
## Dateien-Übersicht
| Datei | Zweck | Geheim? | Aufbewahrung |
|——-|——-|———|————–|
| `private/ca-key.pem` | CA-Privatschlüssel | **JA** | Nur auf CA-Rechner |
| `ca-root.crt` | CA-Zertifikat (öffentlich) | Nein | Per GPO verteilen |
| `openssl.cnf` | CA-Konfiguration | Nein | Auf CA-Rechner |
| `index.txt` / `serial` | CA-Datenbank | Nein | Auf CA-Rechner |
| `HOSTNAME.key` | Host-Privatschlüssel | **JA** | Nur auf dem Host |
| `HOSTNAME.crt` | Host-Zertifikat | Nein | Auf CA-Rechner |
| `HOSTNAME.pfx` | Bundle für Import | **JA** | Nach Import löschen |
| `rdp-sign.key` | Signing-Privatschlüssel | **JA** | Auf Signing-Rechner |
| `rdp-sign.crt` | Signing-Zertifikat | Nein | Per GPO verteilen |
| `rdp-sign.pfx` | Signing-Bundle | **JA** | Auf Signing-Rechner |
—
## Fehlerbehebung
**"Falsches Passwort" beim PFX-Import auf Windows 7:**
OpenSSL 3.x nutzt standardmäßig AES-256, was Win7 nicht versteht. PFX mit `-legacy -descert` neu erstellen.
**"Unbekannter Herausgeber" trotz Server-Zertifikat:**
Das ist die Warnung über die .rdp-Datei, nicht über den Server. Die .rdp-Datei muss signiert werden (Teil 3).
**"Identität kann nicht überprüft werden":**
Das Server-Zertifikat stimmt nicht mit dem Verbindungsziel überein. Prüfen: CN/SAN vs. eingegebene IP/Hostname.
**Zertifikat nicht im Store nach Import:**
`certutil -importpfx` ohne weitere Parameter importiert in den User-Store. Für RDP muss es in den Machine-Store (als Admin ausführen).
**Thumbprint wird nicht erkannt:**
Leerzeichen aus dem Thumbprint entfernen. `certutil -store My` zeigt den Thumbprint mit Leerzeichen, `wmic` braucht ihn ohne.
Mir ist soweit klar, wie die Warnung dauerhaft verschwindet. Wenn ich das Zertifikat für meine Homepage benutzte, kann klappt das ohne Probleme. Leider ist dieses jährlich zu erneuern.
Ich hätte mir mit folgendem Befehl selbst ein 20 Jahre gültiges Zertifikat ausgestellt:
openssl req -x509 -nodes -sha256 -days 7305 -newkey rsa:2048 -keyout rdp.key -out rdp.crt
Dieses kann ich zwar wunderbar bei certmgr.msc importieren (Eigene Zertifikate und Vertrauenswürdige Stammzertifizierungsstellen), es wird als gültig angezeigt. rdpsign.exe gibt aber folgenden Fehler aus: "Das angegebene Zertifikat kann nicht zum Signieren verwendet werden. Fehlercode: 0x8007000d".
Bin ratlos, vielleicht kann mir jemand helfen?
Danke, Daniel
Prüfe folgendes: Wurde ein Codesignatur-Zertifikat erstellt?
Felder:
Schlüsselverwendung: Digitale Signatur (80)
Erweiterte Schlüsselverwendung: Codesignatur (1.3.6.1.5.5.7.3.3)
UND
dieses Zertifikat muss auch in den Zertifikatsspeicher „Vertrauenswürdige Herausgeber" importiert werden.
Vielen herzlichen Dank für deine Rückmeldung, ich habe deine Ergänzungen berücksichtigt. Jetzt leider Fehlercode: 0x8009200b
Ich habe weiter oben eine Anleitung gepostet. Sie hat in 2 Umgebungen funktioniert. Würde einfach das versuchen.
Habe jetzt den private key und das certificate nur in Eigene Zertifikate als PFX-Datei importiert. Jetzt hat es geklappt! Somit sind nur zwei openSSL Befehle nötig und man hat die nächsten 20 Jahre Ruhe:
openssl req -x509 -nodes -sha256 -days 7305 -newkey rsa:2048 -keyout rdp.key -out rdp.crt -addext "keyUsage = critical, digitalSignature" -addext "extendedKeyUsage = critical, codeSigning"
openssl pkcs12 -export -out rdp.pfx -inkey rdp.key -in rdp.crt
Danke für den Tipp mit dem Github-Tool. Kannte ich gar nicht und ist denke ich besser als alle von mir erwogenen Alternativtools.
Wir hatten auch Probleme weil viele Leute den Dialog zwar durchgewunken hatten aber das Häkchen bei Zwischenablage nicht an hatten. Da dann kein Copy&Paste mehr ging wurden alle möglichen Netzwerkshares zweckentfremdet.
Wir hatten als mal Phishing-Popus (echte Versuche) die täuschend echt Defender-Warnungen oder Windows-Meldungen imitierten (durch Vollbild-Edge-Fenster) und deswegen haben sich einige gar nicht getraut das anzufassen.
Windows ist mit dem AD und dem Software-Support eigentlich der Gold-Standard für Unternehmen (zwangsweise) und ich verstehe nicht wieso gerade der Sektor so belästigt wird. Privat wird RDP wohl ja meistens nur von „Power Usern" gebraucht und in Unternehmen gibt es irgendeinen Admin, der den Zielserver laufen lässt. In dem Zusammenhang ist diese Zwangsbeglückung ein krasser Missgriff, weil man das angeblich sichere Verhalten als Default nimmt. Andersherum, dem Admin ein neues Werkzeug zu geben, wäre es OK. Mir kommt das Ganze so vor als habe in Amerika mal wieder jemand ein Baby in die Mikrowelle gelegt und den Hersteller verklagt weil keine Warnung kam… (Sarkasmus.)
Unser Tiroler Systemhaus hat das auch gleich betroffen, da wir zahlreiche Kunden im KMU-Bereich mit Terminalservern oder anderen RDP-Zugängen haben.
Den Workaround mit Abschalten der neuen Sicherheitsfeatures haben wir für uns gleich ausgeschlossen, also zuerst auch mit händischen Scripten und fehleranfälligen Routinen mit zahlreichen manuellen Schritten beholfen. Dann haben wir uns "aus der Not heraus" die Zeit genommen, ein ordentliches Webtool für die einfache und bequeme Signatur von RDP-Dateien zu erstellen, und herausgekommen ist https://rdpsign.com.
Damit können RDP-Dateien bequem über eine Weboberfläche sowohl mit selbstsignierten als auch mit vom Benutzer "mitgebrachten" offiziellen Signing-Zertifikaten signiert werden. Es handelt technisch sich um eine Lösung auf Linux-Basis, selbst für die Signatur der RDP-Dateien wird kein Windows Server benötigt.
Beim Fall von selbstsignierten Zertifikaten müssen diese noch importiert und über GPO für die Verwendung im Remotedesktopclient freigegeben werden, dafür sind wir noch beim Entwickeln eines kleinen Tools, das als Open Source zur Verfügung gestellt wird.
Wir freuen uns über Tests und Rückmeldungen!
Bisschen spät für einen Aprilscherz. Habe trotzdem gelacht.
Kleiner Hinweis noch zu RDPSign – ist mir heute aufgefallen, ich habe es nicht bis zum Ende durchrecherchiert, aber vielleicht hilft es wem:
Wenn ich eine RDP-Datei auf einem Windows-Server 2019 mit RDPSign signiere, versteht ein aktuelles Win11 (25H2) die Signatur nicht.
Wenn ich auf einem Win11 Client signiere funktioniert das File.
Falls wer weiß ab welcher Serverversion das Ganze auch mit dem RDPSign auf dem Server-OS geht, würde ich mich über einen Kommentar freuen.
Aus meiner Sicht wieder einmal ein nicht ausgereifter Zwang für alle Systeme, welcher die User nur zum blinden "klicke alles an ohne zu lesen" leitet.
Ein für mich sinvoller Schritt wäre, wenn zumindest differenziert wird nach IP Adresse des RD-Servers. Interne Adressen wie 192.168.*.* oder 10.0.*.* etc sollten das Verhalten ohne Warnung wie früher bewahren.
Pishing Versuche per RDP sind eher über öffentliche IP Adressen zu erwarten.
Gibt es eine Möglichkeit das Dialogfeld "Erster Start" wo der User dies bestätigen muss zu deaktivieren? Bei uns sind hier viele User verunsichert was sie dort machen sollen…
Bisher habe ich nur Lösungen gefunden die sich um die anderen Warnmeldungen drehen. Vielen Dank.
Durch bestätigen wird HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\RdpLaunchConsentAccepted als DWORD 1 gesetzt. Das kann man natürlich auch über GPO setzen…
Ja, das wird von dem im Artikel genannten Wert leider nicht mit erschlagen. Haben mich auch User Samstagmorgens um 8 Uhr für aus dem Bett geworfen…
Warum nicht das Zonenkonzept nutzen Microsoft, es wäre so einfach gewesen. Intranet Zone und Vertrauenswürdige Sites als vertrauenswürdig, alles andere nur signiert.
Wir haben unsere RDP-Datei nun signiert, dennoch erscheint bei jedem Start weiterhin die Meldung, halt diesmal unter Angabe des Herausgebers.
Was mache ich falsch?
Das Root-Zertifikat, mit dem das Code-Siging-Zertifikat signiert wurde, muss im entsprechenden Zertifikatsspeicher vorhanden sein und der Thumbprint des Code-Siging-Zertifikates muss in der Registry unter HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\TrustedCertThumbprints (siehe Beiträge weiter oben) eingetragen sein.
Funktioniert. Danke für den Hinweis.
Hallo zusammen,
ich würde mal die aktualisierte Windows App als Option in die Runde schmeißen.
Da ging bisher nur Azure Remote Desktop und wohl seit nem knappen Monat auch RDP via IP!
Redditbeitrag: https://www.reddit.com/r/homelab/comments/1s8mfs9/windows_app_finally_supports_noncloud_remote/
Hier kam bei meinen Tests bisher keine einzige Warnmeldung.
Microsoft hat wohl auch vor einiger Zeit bei Mac das Programm "Microsoft Remotedesktop" abgekündigt(nichts mitbekommen) Weil bei meiner letzten Einrichtung auf einem Kunden Macbook, ist mir vor 2-3 Wochen auf einmal "Windows App" übern Weg gelaufen. Microsoft Remotedesktop wie gewohnt gegoogelt – auf Windows App verwiesen worden.
Da haben die Damen und Herren bei MS wohl seit einiger Zeit still und heimlich einen Plan verfolgt!
Durch das RDP Problem ist das Supportaufkommen unfassbar gestiegen -.- Eine Finale Lösung wie wir damit weiter verfahren, haben wie hoffentlich kommende Woche.
LG und Wuuuusssaaaa
Tja, werfen kannst Du die Microsoft App schon, allerdings eher in den Mülleimer, als in die Runde, oder kann das Teil inzwischen auf Windows 10/11 auch RemoteApps (Work Resources) und unterstützt echte Multiscreen Setups?
RemoteApps leider nein. Ist bei unseren kleineren Umgebungen 1-100 auch eher nicht relevant.
Mal HomeOffice, RDP auf den User Client oder mal vereinzelt ein Terminalserver.
Ja kann Multiscreen.
Ich habe jetzt auch die Windows App an den Start gebracht, und was soll ich sagen für unsere Zwecke läuft es ohne Probleme auch im DATEV Bereich. Die User finden es auch besser als vorher da klicki bunti :-)
Diese ganze Signierung einzelner RDP Verbindungen in großen Umgebungen ist so nicht praktikabel.
Gruß und ein schönes WE