Verbindungswarnung bei RDP-Zugriff

[teletubbieland 226]

Moin,

 

bei einem Kunden sind heute nach den April Updates Warnungen für die RDP-Verbindungen aufgepoppt. Die Zertifikate für die Server sind gültig und werden via GPO verteilt.

Bis vor dem Update gab es auch nie ein Problem damit.

https://learn.microsoft.com/de-de/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings

 

Auf die Schnelle habe ich nichts gefunden, wie man das über die GPO lösen kann.

 

Kann mir da vielleicht jemand einen Tipp geben?

 

[mwiederkehr 419]

Ja, solche Änderungen des Verhaltens machen Spass... Besonders toll finde ich die fehlende Möglichkeit für "nicht erneut fragen"! 

 

Im von Dir verlinkten Artikel steht ganz am Schluss ein Registry-Key, mit dem man zum bisherigen Verhalten zurückkehren kann. Eine spezifische GPO habe ich nicht gefunden.

[teletubbieland 226]

vor 2 Minuten schrieb mwiederkehr:

Ja, solche Änderungen des Verhaltens machen Spass... Besonders toll finde ich die fehlende Möglichkeit für "nicht erneut fragen"! 

 

Im von Dir verlinkten Artikel steht ganz am Schluss ein Registry-Key, mit dem man zum bisherigen Verhalten zurückkehren kann. Eine spezifische GPO habe ich nicht gefunden.

eben - ich auch nicht 

[Sunny61 853]

Das hier könnte Besserung bringen: https://www.windowspro.de/thomas-joos/rdp-dateien-einem-zertifikat-signieren Probiert hab ich es noch nicht.

[teletubbieland 226]

könnte funktionieren.

Ich werde es in einer ruhigen Minute testen. Danke.

[Sunny61 853]

Die Warnung kommt bei uns auch, mit dem Zertifikat kriegt man allerdings nur einen Teil weg, die Größe der Warnmeldung bleibt allerdings. Hinweis an die User, fertig.

[mwiederkehr 419]

Die Warnung kommt sogar, wenn die RDP-Datei mit einem EV-Zertifikat einer öffentlichen Zertifizierungsstelle signiert ist.

[testperson 1.988]

Moin,

 

ich habe gestern Abend drei Clients mit dem April Update versorgt und zwei Server. Bei mir kommt die Meldung nicht. Von einem Windows Server 2022 "JumpHost" auf überwiegend noch nicht gepatchte Server jedoch schon.

 

Einer der Server läuft als VM in Azure und der andere ist ein Azure Virtual Desktop (, wo ich mich testweise auch per plain RDP angemeldet habe).

 

(Der Workaround ist nicht implementiert.)

 

Gruß

Jan

[Sunny61 853]

Bei uns hat es nur Clients getroffen, die mit Settings vom gpPack beglückt sind, die Anzahl der Clients/User ist an der Stelle noch überschaubar. Welche Settings das verursachen weiß ich noch nicht.

[mwiederkehr 419]

Von meinen Kunden erhalte ich viele Meldungen, aber ob alle betroffen sind, weiss ich nicht. Gibt es allenfalls ein A/B-Testing? Oder darf man gar hoffen, dass die Änderung rückgängig gemacht wurde? 

 

Besteht die Möglichkeit, sich frühzeitig über solche Änderungen informieren zu lassen? Ich wurde von der automatischen Aktivierung von Smart App Control und den Verbindungswarnungen bei RDP kalt erwischt.

[Dominik Weber 20]

Wir haben auch grade Telefonterror von Kunden wegen dieser Meldung. 

 

Die Lösung war bis jetzt folgender Eintrag

 

Powershell:

New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" -Name "RedirectionWarningDialogVersion" -Value 1 -Type DWord

 

Ich frage mich echt, was MS geritten hat, solche Änderungen ohne Ankündigung auszurollen und dann nicht mal Lösungen zu bieten?

Signieren geht ja scheinbar nicht gemäss Aussagen

[testperson 1.988]

Ach du liebes Lieschen.. Ich *** 😅

 

Ich habe das die ganze Zeit nur per "Ausführen" -> "mstsc.exe" getestet und nicht mit einer gespeicherten RDP Datei. Was allerdings zu einem anderen, recht halbgaren Workaround führt:

mstsc.exe /v:<Server>

 

 

[testperson 1.988]

Die erste Meldung lässt sich durch diesen Registry Key beeinflussen:

 

HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client
RdpLaunchConsentAccepted
REG_DWORD
1

HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
RdpLaunchConsentAccepted
REG_DWORD
1

1 -> Meldung kommt nicht
0 -> Meldung muss bestätigt werden; Nach "Haken" + "Ok" ist der Wert 1

New-ItemProperty -Path "Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Terminal Server Client\" `
    -Name "RdpLaunchConsentAccepted" `
    -Type "Dword" `
    -Value 1 `
    -Force

New-ItemProperty -Path "Registry::HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client\" `
    -Name "RdpLaunchConsentAccepted" `
    -Type "Dword" `
    -Value 1 `
    -Force

 

 

Edit: Das funktioniert auch in HKLM!

 

bearbeitet 16. April von testperson
Das funktioniert auch in HKLM!

[Sunny61 853]

vor 2 Stunden schrieb Dominik Weber:

Signieren geht ja scheinbar nicht gemäss Aussagen

Doch, ich hab mehrere RDP-Dateien erfolgreich signiert. Sieht man dann auch Dialog.

vor 2 Stunden schrieb Dominik Weber:

Ich frage mich echt, was MS geritten hat, solche Änderungen ohne Ankündigung auszurollen und dann nicht mal Lösungen zu bieten?

https://learn.microsoft.com/de-de/windows-server/remote/remote-desktop-services/remotepc/understanding-security-warnings

Der Artikel wurde am 14.04.2026 aktualisiert, also gab es den Artikel schon vorher.

[mwiederkehr 419]

Weiss jemand, wie man eine RDP-Datei mit einem Timestamp signiert? rdpsign.exe kann es nicht, Set-AuthenticodeSignature kann nicht auf das HSM zugreifen und signtool.exe kennt den Dateityp .rdp nicht.