FYI - Microsoft RDP Changes With April Cumulative Update
Posted by whatsforsupa@reddit | sysadmin | View on Reddit | 121 comments
FYI, Microsoft changed some of the verbiage for the login windows for RDP, including a new caution message when trying to login, a checkbox for users when setting up a new RDP session, as well as other changes about "what you bring" with an RDP session (ie: clipboard).
DB_Ivessy85@reddit
Anyone else seeing this bullshit. Bottom options are unusable after RDP signed. cant select options.
derpman86@reddit
This is a fun pain in the arse that came out of no where, I am glad I found this thread quickly to answer question to save me a lot of time which is awesome.
AforAnonymous@reddit
Cool. When will they re-document OIDs 1.3.6.1.5.5.7.3.1, 1.3.6.1.5.5.7.3.2 (at least that one still has SOME documentation), 1.3.6.1.5.5.7.3.3, & 1.3.6.1.4.1.311.54.1.1 and re-integrate proper support for it so certificate based security for RDP stops being a fucking joke requiring one to reverse engineer half of RDP because their engineers working on it nowadays don't understand half their features nor why giving server authentication certs out left and right for stuff where it doesn't belong ain't a good idea?
Oh, right, never cuz Satya got his head way too far up his own damn as.
Don't believe me the code paths supporting those OIDs exisst in the engine, just not (anymore because they slop'd too hard already long ago) in the management clusterfuck around it forcing one to use non-documented internal cmdlets & API calls to get the proper certs forced into one's RDP Farm because the guys who wrote Server Manager never hear of the concept of "parse, don't validate"?
Go run strings.exe against rdpsign.exe (which will happily sign files properly rather than half-assedly) & mstsc.exe then, I'll wait.
And while they're at it maybe they could make getting proper certs for the Hyper-V console less of a pain in the fucking ass. Especially on Azure Local. "oooooh look at our Fancy Key Vault we so cool", meanwhile this crap doesn't even do Kerberos right and instead has one dump shotgun CredSSP delegations in everwhere.
Oh, right, never, cuz Microslop outside the core auth team is all security theater nowadays.
(with apologies to /u/SteveSyfuhs, who I know works hard to make Windows auth less of a joke, but with shit shows like RDP that ONCE UPON A TIME were designed to not be quite the opposite of a shitshow but have been ever since server manager was supposed to replace the old UI, avoiding security theater has become way too fucking hard.)
SteveSyfuhs@reddit
...huh? Those are standard client and server role EKUs. They're documented in a million places on the internet because they're the standard for everything. Hyper-V does Kerberos just fine but it requires configuring constrained delegation which is normally a domain admin role, which Hyper-V admins tend not to be. Credential delegation is inherently easier to use out of the box. Do you want it to be functional out of the box or do you want it non-functional and also have to figure out constrained delegation to make it just work? Pick your battles.
There was never the guy. The person you're probably referring to was well known in the industry because he interacted with the industry. We have dozens of PKI experts in the product groups.
I understand you're venting, and by all means vent, but lets not attack folks just trying to do their jobs. The decisions we make are rarely because we don't know any better. The decisions we make are usually making the best of a tough situation and having to live with the consequences.
Cormacolinde@reddit
There’s a checkbox to not see it again ONLY if the file is signed.
You can disable the whole thing by adding your certificate SHA signature by GPO/CSP.
Thanks Microsoft for the advance warning on a change that will confuse millions of people…
Tl9zaXh0eWZvdXI@reddit
Wrong, I verified it myself the popup still appears even with signed rdp file and the checkbox selected. The checkbox only saves the remote resources selection.
Cormacolinde@reddit
Please see my edit with more details.
Tl9zaXh0eWZvdXI@reddit
What regkey? If you mean RedirectionWarningDialogVersion then yeah no shit that reverts the entire April change and your other steps are irrelevant. If it's something else then please do share.
Cormacolinde@reddit
Please look at the details in my other comment. I’ll edit my post with it later.
Tl9zaXh0eWZvdXI@reddit
That did work, thank you.
00Boner@reddit
Ahhh, this explains the 6am ticket I got for the new rdp warning. Sigh
BrentNewland@reddit
That sounds lovely, do you have a policy name, or anything that would help to look this up?
Cormacolinde@reddit
You need to sign the RDP file with a certificate that is valid and trusted by the client, so likely using a PKI, with rdpsign (https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/rdpsign).
You then need to push the following GPO with the SHA1 thumbprint of the signing certificate:
BigSet9400@reddit
This also works if the signing certificate uses SHA256. Thank you so much. It would've taken me hours to figure this out.
BrentNewland@reddit
I see, I thought you were talking about something that would automatically sign RDP files the user creates using our ADCS.
Inside_Carpet7719@reddit
Then attackers would also sign them, defeating the security...
BrentNewland@reddit
The attacker would have to have access to a domain connected computer first, meaning they've already defeated your security...
Godcry55@reddit
I will go with the registry key method, target host is a single user AzureVM.
Thanks for the workaround!
djkretz@reddit
This fixed my issue. Thanks
torbar203@reddit
the timing also came perfectly for us, because last night we had just done an upgrade to our EHR system which is accessed via remoteapp
So this morning everyone that uses the system is freaking out about this dialog thinking there's an issue with the EHR system
VexingRaven@reddit
Why are you getting this prompt when going through remoteapp?
torbar203@reddit
I'd assume because remoteapp uses an RDP session to connect?
VexingRaven@reddit
I thought this is only supposed to show up if you open an RDP file? It certainly doesn't show up for us using Citrix, and that's just RDP sessions with a fancy broker in front of it.
Fatel28@reddit
Remoteapp is RDP and, as a result, uses RDP files
Constant-Vast519@reddit
We are using a rd web portal with web apps to a terminal server. We have a folder that is used to move files from our software to the users desktop. When they get the warning, all of the options are greyed out and they cannot choose anything. They can open the folder and copy the file, but cannot paste it. This goes for any shared folders on the terminal server being accessed this way. It has screwed us over.
NteworkAdnim@reddit
That's always how it goes... there have been SO MANY times when I thought about doing some maintenance at a certain time only to end up pushing it back further; then literally the day after the original thought of doing maintenance, we have all kinds of issues. And I'm always like, "If I would have done that maintenance when originally planned, it would look like that caused these completely unrelated issues!"
piniatadeburro@reddit
Our people thought our EHR was hacked
avgjoegeek@reddit
I have an issue where the client keeps getting the prompt even though they click the "Remember my Decision" and click Connect.
Cormacolinde@reddit
Yes, if you check the box, it will still popup. The only solution is to disable it as per the Microsoft article, or do the steps I give in my edit.
avgjoegeek@reddit
Thanks, Unfort for me my case isn't as simple. I think were stuck doing the regfix as a temporary bandaid and hope that M$ will come up with a better solution.
HDClown@reddit
The checkbox that is available on signed files does not prevent the popup, it just allows the user to save the manually set resource options for subsequent use.
ReCrunch@reddit
Is the checkbox actually to not see it again or just to save what you bring along?
crane476@reddit
Well, at least they finally aligned the username and password fields in the RDP dialog...
Zieprus_@reddit
Commenting so I can come back to the thread.
BatemansChainsaw@reddit
There is a handy little "save" link under each comment and post ya know...
Zieprus_@reddit
I was going to add context however didn’t realise this place was so “interesting”. Anyway best of luck all with the hyper vigilant users that are scared of every change with heightened security awareness. It’s hard to keep track of cloud provided solutions changes.
redvelvet92@reddit
Who cares
derpman86@reddit
All the people who have to deal with waves of confused people and the techs and admins are now dealing with a problem that wasn't until a couple of days ago that got no warning about.
Lukage@reddit
People who use RDP files. Any other questions?
palto-1@reddit
This is insane. No warning, no notice? Nothing to help administrators prepare, just drop it on a random Wednesday?
We deliver SaaS via Remote Desktop Gateway/RemoteApps. This will disrupt thousands of users and cause an incredible headache for our support staff to field the inevitable calls and emails from freaked out users.
Even if we sign now, we'll have to push out to thousands of workstations somehow, then have those company's workstation admins add the publisher to the trusted publishers, add the cert hash to the registry, maybe install the cert in each computer's certificate store as well?
But what with the new requirements for TLS certificate validity duration going down to as short as 47 days or fewer, how does that impact re-signing the RDP files? Will we have to push out a new file every time the cert renews?
And even with all of that, somehow, the users will still see the big popup prompting to accept devices? Every single time, no matter what? That's just ridiculous.
There are so many questions, and I feel like there's no way Microsoft actually thought this through, otherwise there would have been some kind of bulletin or advisory. This is a huge deal and it's not being talked about enough.
Nicko265@reddit
If pushing a cert to a cert store on your devices is a hassle, you really need to rework your entire set up. It's a simple group policy or Intune setting, it should take you 30 minutes this morning to add all the required certs.
If you're actively using unsigned RDP files in your environment, why? Plenty of alternative options to properly and securely deliver remote desktops and remote apps.
_Ivl_@reddit
Write something that generates the .rdp file and self signs it, but you got to hope your self signed thumbprint doesn't get overwritten by a GPO probably. Since being a trusted cert isn't enough and the thumprint needs to be in the registry as well, so they should at least make a way to distinguish and allow self-signed certs thumprints in the registry that don't get overwritten or multiple thumbprint keys. Unless there is already a way to just automatically comma append to already existing thumprints in the registry with GPO.
whatsforsupa@reddit (OP)
Yes, as a company who heavily leans on RDGateways and hosted RDApps, today was painful. Our ticket volume was pretty heavy, although we put out multiple PSA's.
Atleast Microsoft put out an article with halfway decent documentation this time... better than usual... I guess.
The bourbon is on me tonight, cheers.
trueg50@reddit
Great, and while you are at it Microsoft can we get native WHfB functionality with RDP? Cloud kerberos trust has been required for a while be requires some annoying cert work to try to get it to work.
DaithiG@reddit
Agreed, if should be easier with WHFB. We have this working in our (small) environment by hybrid joining the server. Staff can login via PIN with cloud kerberos, no certs needed
trueg50@reddit
Interesting, I haven't read of hybrid joining the server and having certs not be required, thanks!
agressiv@reddit
I've spent some some time with this, as we use RDP Files extensively.
I would have hoped clicking "Remember my choices for remote connections from this publisher" would bypass it, but all it does is pre-populate the check boxes next time around.
Again, it's going to nag you every single time on signed RDP files once their workaround stops working.
VexedTruly@reddit
I only had a very brief play with this today but if you have signed/verified RDP file, once you tick the box / grant consent, all it does is create
HKEY_CURRENT_USER\Software\Microsoft\Terminal Server Client
RdpLaunchConsentAccepted
REG_DWORD - 1
It doesn't SEEM to be per server/connection so there's a slim possibility you could supress it by creating that key.
Creating that key definitely prevents the 1 time consent for verified/signed files.
HDClown@reddit
That key suppresses only this one-time popup:
https://learn.microsoft.com/en-us/windows-server/remote/remote-desktop-services/media/rdp-file-first-launch-dialog.png
agressiv@reddit
Yes, there's otherwise 2 popups. The small one (this pic) - or the large one which shows all of the devices being redirected. That large one cannot be suppressed as it stands without the temporary workaround.
I went over it with procmon and didn't see anything. Not to say there isn't some other hidden setting, but I'd generally find it with procmon.
dgillz@reddit
I don't see your pic.
VexedTruly@reddit
Good to know - like I said, I only had time to briefly play with it and I figured there'd be edge cases for the many different potential scenarios.
Nomaddo@reddit
For signed RDP files it creates a key for the sha256 of the certificate and values for allowed/denied resource, but from my testing it's still prompting even after checking the box.
Nomaddo@reddit
They need to change that. Prompting again when the RDP files is signed with a new certificate is fine. Prompting again for the same certificate is not.
fieroloki@reddit
I am seeing this as well. No check box to check to not show it again.
UsersLieAllTheTime@reddit
You could always try and do the regedit in the link
PlannedObsolescence_@reddit
I really wish they would do a GPO / registry value that allows the administrator to specify a series of allowed FQDNs (also supporting wildcards i.e. *.rdp.example.com) for the TLS cert that signed the RDP file.
Nomaddo@reddit
I'd like to know what Microsoft is trying to achive with this change?
We already have GPOs to block connections to unsigned and non-trusted certs. https://i.imgur.com/6GDse2K.png
PlannedObsolescence_@reddit
They're doing it this way so it warns by default, especially important for the general public who are not going to be making modifications to harden the OS via policies.
spin_kick@reddit
Gen pop will just click through all this though. Microsoft trying to solve training with technology which never does well. 🤷♂️
Nomaddo@reddit
I guess that makes sense.
HDClown@reddit
I'm pretty certain this whole change was dropped last minute, at least as far as public information goes. I couldn't find any reference to this prior to yesterday (4/14) when it was announced in the message center.
The FAQ indicates that AVD/W365 .RDP files should not see the new security dialog so Microsoft built in a bypass for themselves on their own signed files, which I'm sure is baked into the code.
I'm sure Microsoft is going to get a ton of complaints from small to large enterprise customers and they will have to do an update that allows you to leave the new behaviors but whitelist certain signed publishers.
This is a lot like when they decide to make a heavy-handed change in M365 and pre-announce it, then they get such negative feedback that they cancel the change, except that there was no pre-announcement.
PlannedObsolescence_@reddit
They're responding quickly to a wave of
.RDP-file-based attacks from threat actors.Microsoft are very on top of this recent issue.
Looks at calendar, you see they've just published a update to thwart this threat in record time.
...Oh wait this has been prevalent since Oct 2024. Google were even posting about it very prominently 1 year ago
iowapiper@reddit
is this a server side modify or client side?
fieroloki@reddit
Client side
UsersLieAllTheTime@reddit
The way I'm reading it is client side but since u/fieroloki actually did it maybe they can confirm
Casty_McBoozer@reddit
Of course that article then states:
"Warning
A future Windows update might remove support for this setting, even on older versions of Windows. Plan to transition your environment to work with the new security dialog."
But I don't see a fix. My RDP files are signed.
UsersLieAllTheTime@reddit
Classic Microslop, at this point I just take the solutions where I can and hope it lasts long enough that I have time to deal with it next time it pops up
Casty_McBoozer@reddit
I've been fighting with the BS all morning. SSL warnings all of a sudden. We sign everything with ADCS certs. I've reissued with new templates several times, kept adding SAN names, etc, couldn't make the SSL warning go away.
This regkey did the trick.
A thousand upvotes for you, sir.
CeC-P@reddit
I assumed that would be a thing, since random people that'd fall for a remote support scam wouldn't edit their group policies but most companies wouldn't want that to pop up ever.
PowerShellGenius@reddit
It's not about remote "support" scams. It's about giving an attacker access to local resources (all the "redirection" options).
If you're configured your Windows firewall to block outbound RDP to the internet, or outbound RDP at all when not on corporate networks - that is largely mitigated.
Otherwise, you can RDP to computers on the internet. (Exposing RDP to the internet is not secure for a computer you want to protect, but attackers do it all the time with disposable VMs)
Attackers phish people with RDP files. Open the RDP file, connect with all redirections enabled, they get local storage access to your machine, the attack service of the legacy print spooler to play with due to printer redirection, the ability to spy on your camera/mic...
The worst part is, it exposes the sole weakness of "phishing resistant MFA". WebAuthn and smartcard redirection exist to allow passkeys/FIDO2/smartcards to all be used in RDP sessions as if they were connected to the remote host. RDP to an attacker controlled host is the only known way to sign a distant attacker in with phishing-resistant methods (probably why it's called "resistant" instead of "proof"). I'm sure these attacks are on the rise as passkey adoption rises.
Mr_ToDo@reddit
Ah. OK. Sorry, it took me a while to catch on to what you were saying
For some reason it didn't click that what you bridge to the remote connection would actually be seen on the other side. That's... interesting
I think it might also be nice to have another pop up that says what you're about to forward. But that device permission protection seems to be hard for some reason, I mean look at Android. Yes it asks for some types, but there's a ton that go through unnoticed, and that's a system that loos like it's far more likely to have bad actors getting their payload onto devices
What a world we live in. We just can't have nice things without someone trying to break them
fieroloki@reddit
That worked fine. Now to look into pushing the change out with our RMM
fieroloki@reddit
I'll give that a shot. Thank you.
spin_kick@reddit
🤬 this was very annoying
CoatPersonal4545@reddit
This is so stupid, this now prevent users to save a custom rdp file (i have some users modifying the rdp to show only 2 out of 3 monitors)
CupOfTeaWithOneSugar@reddit
They can go fuck themselves.
They go through the trouble of implementing this garbage for "security" yet they don't support actual real security of their own software:
Doesn't support number matching on the authenticator app using their NPS extension for Azure MFA. Only a basic approve button.
Doesn't support Azure App Proxy.
Fuck you mstsc devs!
perfectcritic@reddit
I know somebody who works in MSFT, I now wonder how these days he has remain employed in challenging AI fire times. First push an update to inconvenience the system then sell something in a wrapper or some package to premium customers that would fix the inconvenience. The free users are left out. Great traditional way to do business but this doesn't work in these times.
RestartRebootRetire@reddit
Oddly enough I have a conference room PC on this same new build of Windows that doesn't show the secondary publisher warning for *any* RDP files but all other workstations on our domain do, and thus need to trust a signed RDP file.
mrkokkinos@reddit
For what it's worth Windows App doesn't seem affected. To be fair, almost no one uses it 😂
Verukins@reddit
if windows app supported published applications - we would use it - its actually quite good.
We use it for AVD - but cant use it for our internal RDS farm - as it simply doesnt support published apps... im sure the official line is something something legacy something something... i.e. What do you mean you dont want to fork out $100k per month for hosting apps in AVD for 800 users that would work poorly due to latency if you put them in AVD
ozzyosborn687687@reddit
What Windows App?
jmbpiano@reddit
The Windows App, obviously.
What else would they be talking about except the app with the completely unambiguous name that couldn't be mistaken for anything other than an RDP client.
/s
mrkokkinos@reddit
I should have been more clear, but then you wouldn't be able to make that hilarious comment about the name MS gave it, so I stand by my decision hahaha
Subculture1000@reddit
My theory is they've been pushing the Windows App as the replacement for Remote Desktop Connection for so long, nurfing non-signed RDP files is just a way to push people over.
And it will work, because it's more direct than making registry changes that might get overridden later.
I have tons of small business clients (1-10 systems) that don't even have a Windows Server, let alone a domain, so properly signing RDP files isn't an option. They're directly connecting to a workstation for RDP (over a mesh-overlay VPN configured for RDP-only traffic).
So Windows App it is from here on out, I guess.
moffetts9001@reddit
I can no longer connect to my GCC High W365 desktop through the Windows app as of today, having installed the April updates last night. Basically the same issues we had back in January with another fucked update.
PerceptionQueasy3540@reddit
Got several tickets about this today. Just gonna purchase a public cert for most, they're cheap. Although for one of them cause they're connecting to third party RDS that doesn't have a public cert I'm gonna setup a RD gateway and put a public cert on there, thinking that should work.
_Ivl_@reddit
# 1. Configuration$rdpFile = "C:\Users\Desktop\Default.rdp"$certSubjectName = "LocalRDPSigner"$certSubject = "CN=$certSubjectName"# 2. Check for existing certificateWrite-Host "Searching for existing certificate: $certSubjectName..." -ForegroundColor Cyan$existingCert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -eq $certSubject } | Select-Object -First 1if ($existingCert) {Write-Host "Found existing certificate with Thumbprint: $($existingCert.Thumbprint)" -ForegroundColor Green$cert = $existingCert$thumbprint = $cert.Thumbprint} else {Write-Host "No existing certificate found. Creating new one..." -ForegroundColor Yellow# Create the Self-Signed Certificate`$cert = New-SelfSignedCertificate -Subject $certSubject ``
`-CertStoreLocation "Cert:\LocalMachine\My" ``
`-Type CodeSigningCert ``
`-KeyExportPolicy None ``
-NotAfter (Get-Date).AddYears(5)$thumbprint = $cert.Thumbprint# Add to Trusted Root$rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store("Root", "LocalMachine")$rootStore.Open("ReadWrite")$rootStore.Add($cert)$rootStore.Close()# Add to Trusted Publishers$pubStore = New-Object System.Security.Cryptography.X509Certificates.X509Store("TrustedPublisher", "LocalMachine")$pubStore.Open("ReadWrite")$pubStore.Add($cert)$pubStore.Close()# Update GPO Registry Key# Update GPO Registry Key (Append Logic)$gpoPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client"if (!(Test-Path $gpoPath)) { New-Item -Path $gpoPath -Force | Out-Null }$currentRegistry = Get-ItemProperty -Path $gpoPath -Name "TrustedPublisherThumbprints" -ErrorAction SilentlyContinue$currentValues = if ($currentRegistry) { $currentRegistry.TrustedPublisherThumbprints } else { "" }if ($currentValues -notlike "*$thumbprint*") {Write-Host "Appending thumbprint to GPO trust list..." -ForegroundColor Cyan$newValue = if ([string]::IsNullOrWhiteSpace($currentValues)) { $thumbprint } else { "$currentValues,$thumbprint" }Set-ItemProperty -Path $gpoPath -Name "TrustedPublisherThumbprints" -Value $newValue} else {Write-Host "Thumbprint already exists in GPO trust list. Skipping registry update." -ForegroundColor Yellow}Write-Host "New certificate created and trusted." -ForegroundColor Green}# 3. Sign the RDP Fileif (Test-Path $rdpFile) {Write-Host "Signing RDP file: $rdpFile" -ForegroundColor Cyanrdpsign.exe /sha256 $thumbprint "$rdpFile"Write-Host "Success! RDP file is ready for use." -ForegroundColor Green} else {Write-Error "Target RDP file not found at $rdpFile"}Verukins@reddit
The article is very vague (as is standard for MS) to if the dialogue box will show up in the situation where
- RDWeb is in use (which just downloads and launched the .rdp file anyway)
- Everything is signed
- GPO is configured to trust the cert thumbprint
which would be a very common config for those of us using an RDS Farm
For those of you wondering if it will still hit this scenario - it will - you have to deploy the registry entry from the article to remove it.
Well done MS make-life-hard-for-everyone-without-any-warning department.... bunch of fucking arseholes.
_Ivl_@reddit
# 1. Configuration$rdpFile = "C:\Users\Desktop\Default.rdp"$certSubjectName = "LocalRDPSigner"$certSubject = "CN=$certSubjectName"# 2. Check for existing certificateWrite-Host "Searching for existing certificate: $certSubjectName..." -ForegroundColor Cyan$existingCert = Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Subject -eq $certSubject } | Select-Object -First 1if ($existingCert) {Write-Host "Found existing certificate with Thumbprint: $($existingCert.Thumbprint)" -ForegroundColor Green$cert = $existingCert$thumbprint = $cert.Thumbprint} else {Write-Host "No existing certificate found. Creating new one..." -ForegroundColor Yellow# Create the Self-Signed Certificate`$cert = New-SelfSignedCertificate -Subject $certSubject ``
`-CertStoreLocation "Cert:\LocalMachine\My" ``
`-Type CodeSigningCert ``
`-KeyExportPolicy None ``
-NotAfter (Get-Date).AddYears(5)$thumbprint = $cert.Thumbprint# Add to Trusted Root$rootStore = New-Object System.Security.Cryptography.X509Certificates.X509Store("Root", "LocalMachine")$rootStore.Open("ReadWrite")$rootStore.Add($cert)$rootStore.Close()# Add to Trusted Publishers$pubStore = New-Object System.Security.Cryptography.X509Certificates.X509Store("TrustedPublisher", "LocalMachine")$pubStore.Open("ReadWrite")$pubStore.Add($cert)$pubStore.Close()# Update GPO Registry Key# Update GPO Registry Key (Append Logic)$gpoPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client"if (!(Test-Path $gpoPath)) { New-Item -Path $gpoPath -Force | Out-Null }$currentRegistry = Get-ItemProperty -Path $gpoPath -Name "TrustedPublisherThumbprints" -ErrorAction SilentlyContinue$currentValues = if ($currentRegistry) { $currentRegistry.TrustedPublisherThumbprints } else { "" }if ($currentValues -notlike "*$thumbprint*") {Write-Host "Appending thumbprint to GPO trust list..." -ForegroundColor Cyan$newValue = if ([string]::IsNullOrWhiteSpace($currentValues)) { $thumbprint } else { "$currentValues,$thumbprint" }Set-ItemProperty -Path $gpoPath -Name "TrustedPublisherThumbprints" -Value $newValue} else {Write-Host "Thumbprint already exists in GPO trust list. Skipping registry update." -ForegroundColor Yellow}Write-Host "New certificate created and trusted." -ForegroundColor Green}# 3. Sign the RDP Fileif (Test-Path $rdpFile) {Write-Host "Signing RDP file: $rdpFile" -ForegroundColor Cyanrdpsign.exe /sha256 $thumbprint "$rdpFile"Write-Host "Success! RDP file is ready for use." -ForegroundColor Green} else {Write-Error "Target RDP file not found at $rdpFile"}Script to sign any .rdp file and have it be trusted. Source Gemini._Ivl_@reddit
Typical microsoft, not providing warnings or a simple script to easily sign existing .rdp files.
Anyways I asked Gemini to create a one-shot a powershell script that creates a self-signed cert, imports it to trusted root and trusted publishers, configures the thumbprint GPO (via registry) and then signs the .rdp file with the thumbprint. Seems to work well, just needed to nudge it a bit (haven't tested it fully yet since I'm at home), but a test .rdp file to localhost worked perfectly fine after I ran the powershell script on it. Probably useful for MSPs who might be getting a lot of calls soon because of Microsoft.
Outside-Banana4928@reddit
Just create a batch file (or link) that starts mstsc...
:: Launch RDP directly to Machine1 start "" "C:\Windows\System32\mstsc.exe" /v:Machine1
ZoBook@reddit
Can you set things like window size/position from command line too?
ZoBook@reddit
My dialog is severely broken. It's in spanish but you get the idea, it should be a lot taller and show several checkboxes. The first checkbox even obscure the "Connect" button when you hover it!!
DaithiG@reddit
We use SCEPman to publish device certs for endpoints. All the devices trust the ScePman root cert of course. Can we use that to sign the RDP file. I doubt it works like this
veloce-dragon@reddit
Is anyone having issues RDP redirected printing?
TemperedTyrant@reddit
What issues are you facing?
Just today we've had reports cases of remote apps closing when printing to a redirected printer, or not following saved preferences...
Rataplan626@reddit
Yep. KB5082142 on Server 2022 killed RDP printer redirection for us.
this_is_my_epiphany@reddit
ALL THE FUCKING TIME.
This time though, users will need to check the box to share the Printer. The settings that were saved to the rdp file now default to zero.
veloce-dragon@reddit
Unbelievable man..
neometallic@reddit
I'm seeing redirected printers disappear from the settings menu, but appear when printing from Outlook/Office.
Nomaddo@reddit
Is the length of the client's hostname 15 characters or more?
Significant_Pen2804@reddit
Better fix a stupid behavior when RDP connecting dialog jumps to background after entering a password
Godcry55@reddit
Already experiencing this on a users Entra joined windows 11 device. Anyway to disable it?
Lukage@reddit
What's annoying about this is that establishing the trusted publisher for these is simply adding the certificate's thumbprint as a trusted publisher. Is there honestly any difference between adding the cert as a trusted publisher vs adding it as a trusted root certificate authority?
zatset@reddit
This is actually rather useful information. Thank you.
The good thing is that creating self-signed certificates, signing the RDP files and pushing the certificates via Active Directory should solve the issue while increasing security. The only thing I consider kind of...excessive...is printer redirection. Especially if universal print is not used and drivers are print server drivers are required, this means that the attacker much have the drivers for any and every printer added to the driver store/print server
admlshake@reddit
Can't wait for our developers to start voicing their outrage at this changing with out their approval. Because obviously we changed the code on something with out consulting them.
Fallingdamage@reddit
Got the notice a couple days ago!
MDL1983@reddit
Hit with it this morning. I'm pushing out the registry setting via GPO for now lol.
Casty_McBoozer@reddit
Yeah that's what I just did. I don't know what the permanent fix is. Our RDP file points to a DNS round robin that contains our 2 connection brokers. All RDP files are signed. ADCS certs are assigned to RDP on all connection brokers and session hosts.
I don't know what the permanent fix is.
Happy_Macaron5197@reddit
good heads up, worth knowing before your users start freaking out about "new" security warnings they haven't seen before
the clipboard one is actually something people should read properly. a lot of folks just click through rdp prompts without thinking and the new messaging makes it clearer what youre sharing when you connect. probably overdue honestly
if youre managing this at scale just be ready for a wave of helpdesk tickets from users who think something is wrong because the login screen looks different. a quick internal communication before the update hits your machines will save you a lot of noise
QuietThunder2014@reddit
Anyone else having issues with RDPweb HTML and Firefox? We are able to log into the portal, and then we just get a the loading blue dots once an application is selected on the Connecting and launching screen. The "Show Details" refuses to un-grey which means users can't get to the Duo prompt. No issues on Edge or Chrome. It started with the 148.0 update. I posted in Firefox's official forums and their Reddit and haven't heard anything back.
jordanl171@reddit
If my users click ok will they get prompted tomorrow?
HDClown@reddit
The first popup that you have to check the box on to proceed is one time and won't come back.
The second popup occurs every time they use the RDP file.
Furthermore, if your RDP files are not signed, the user does not get the checkbox to remember the resource options, so they would also need to check the boxes like "printers" and "clipboard" (whatever is allowed/needed) every single time for unsigned RDP files.
Weird_Lawfulness_298@reddit
Powershell script that will set the key for you:
$path = "HKLM:\Software\Policies\Microsoft\Windows NT\Terminal Services\Client"
$name = "RedirectionWarningDialogVersion"
# Create Registry Key if it doesn't exist
If (-not(Test-Path $path))
{New-Item -Path $path -Force
}
# Create Registry Value
New-ItemProperty -Path $path -Name $name -Value 1 -PropertyType DWORD -Force
PlannedObsolescence_@reddit
I really wish they would do a GPO / registry value that allows the administrator to specify a series of allowed FQDNs (also supporting wildcards i.e. *.rdp.example.com) for the TLS cert that signed the RDP file.
HDClown@reddit
FYI, The registry key in the article to revert to old behavior does not require a restart, it's effectively immediately.
If you are a masochist and want to keep the new behavior, the following registry key can be set to eliminate the one-time popup that occurs. It has no impact on the second popup related to available resources:
Nomaddo@reddit
For signed RDP files when you confirm the prompt it creates dwords for the allowed/denied permissions under
so I'm going to go ahead and push those out now before we roll out the update.
yournicknamehere@reddit
Microsoft and their excellent ideas \s
bukkithedd@reddit
Yep, had the first users report this today.
Regansmash33@reddit
FYI: Per the FAQ in the Microsoft Learn Article you linked, this change only applies to RDP Files.