Yesterday evening, I was at home and attempting to remotely connect to my XP desktop machine in the office to access an application which was installed there, but not installed on my laptop. This was over VPN. Now I’ve only had both machines for a few weeks since moving over here and was positive that one of the first things I did on my work machine was to allow remote desktop. However, once on VPN, I was unable to connect to that machine remotely.
My first thought was that I’d forgotten to tick that checkbox as shown above (it wasn’t, but I didn’t know better then). So my thought process was simple – it’s no problem – there’s a way round changing that setting as I had already gone through the simple checks – ping worked, net use to c$ worked. Even better, I had remote access to the registry and the event viewer to there was a relatively easy solution.
That checkbox at the end of the day is just a registry setting. So how do you find out what the registry setting is? One way would be to change the setting locally while running sysinternals RegMon utility, see what was changed and update it remotely. Not the simplest way (maybe), but it would work. As it happened, being at home with my domain in place, I’d previously created a Group Policy to ensure that all clients at home were remotely accessible.
From GPMC, the details tab will give you a GUID for that policy.
You can then go to \windows\sysvol\sysvol\<domain>\policies\GUID\Machine and type out the registry.pol file to see the setting it’s applying. You could also take a look at the associated ADM file – both work easily as well
As you can see, the registry setting is under HKLM\Software\Policies\Microsoft\Windows NT\Terminal Services and the setting is fDenyTSConnections. What isn’t clear from a binary dump here is what the value of that setting is being set to, or what the type is. However, a quick regedit on a client tells you that information – it’s a DWORD with value 0.
If you then use regedit, connect to the machine remotely, it’s trivial to change that setting. However, remote connections were still failing. Hmmm. What about a remote reboot – easy enough using the shutdown command. Still no connection. Anyway, I’m up to the challenge here.
What about forcing a refresh of policy remotely. That’s fairly straightforward using psexec from sysinternals. Start a remote command prompt and run gpupdate /force. Unfortunately, still not able to get a connection. Next thing to look at turns towards the Windows Firewall. Fortunately, through running netstat –an –P TCP via psexec, you can see what ports are listening.
So at this point, I’m pretty sure (assuming the policy had been applied correctly), it’s the Windows Firewall blocking port 3389 (RDP). Next thing to do is to use psexec again to get a dump of the Windows Firewall domain policy (this was a domain joined machine). netsh has an option “dump” which you would think would be the right option to select, but that’s not it. What you actually need to run is show config as in netsh firewall show config. This confirmed there is no port opening for Remote Desktop in the configuration
Again, you can use netsh remotely through psexec to allow that exception. The command is netsh firewall set portopening protocol=TCP port=3389 name=<arbitrary> mode=ENABLE profile=DOMAIN
And that was it. Remote connectivity enabled. Hope this helps someone!Cheers,John.
Nice work John! I can see this coming in handy.
Really good stuff, thanks for posting !
Great work, You taught us how to bypass the anooying firewall !
And I wonder how long it would have taken you to drive home and untick the box ;)
I guess thats half the fun of it...
Dan ...about 3 minutes each way plus 1 min in the office. So, combined with writing up the entry, working out what was wrong and how to fix it probably added to around 5 hours. Still it's worth the 4 hours 53 mins if it saves someone else time when they come up against a similar problem. You're right though, half the challenge of technology is in working through the problem :)
It's also possible to use WMIC to enable RDesktop remotely. And you don't have to reboot the machine afterwards...
WMIC /Node:<yourmachinename> RDTOGGLE where Servername="<yourmachinename> SetAllowTsConnections 1
This works only if you have enabled "File and Printer sharing" on firewall exceptions -tab? By default it is not enabled?
I just test this on my virtual machine and I cannot get any connections to "remote xp-machine" using psexec. After I enabled "File and Printer sharing" on exceptions -tab, then I can use psexec?
What I'm missing here? :-D
psexec requires admin$ being shared and accessible (IIRC). So yes, file & print sharing would probably be required through the firewall - would need to check up to make sure. However, the WMIC suggestion by Christian (above comment) may have mileage. I'm not sure what the firewall requirements are, but likely to be similar to DCOM. Another thing on my list to investigate....
Do You know that is there a way to enable remote registry if that is not enabled by default?
Especially I have some problems occasionally with some XP and Vista boxes in another city.
Anyhow! Thanks for the post, really good work!
Kind sir, you saved me two minutes of walking down the hall to enable RDP through Windows Firewall. You have earned my eternal gratitude.
And you have saved my bacon as well, even though it's been six years! Thank you dearly!