Link to home
Start Free TrialLog in
Avatar of cvservices
cvservicesFlag for United States of America

asked on

GPO Allow Inbound Remote Desktop Connection - UI problem

I have a bit of a weird UI problem with setting up a GPO.
I'm working on setting up a policy for :
Windows Firewall: Allow Inbound Remote Desktop exceptions, and I have a list of subnets and IPs that I need to allow for RDP, and disallow everything else.
The is that my list of IPs is longer than what the field under "Allow unsolicied incoming messages from these IP addresses" , is not long enough, and is therefore truncating my list.

I have tried splitting my IP lists into 2 different policies, one that applies to the subnets, and one that contains a host list, but only one (with the higher priority is applying), where  my purpose is for them to actually be merged and apply the entries in both policies. Is there a way to force those policies to merge their exceptions into one list?

Does anyone know of a solution to this? I don't think that editing the registry.pol is a good idea, so I'm looking for a way to do it with GPMC.
Avatar of Irwin W.
Irwin W.
Flag of Canada image

To do it in Group Policies,

Open the GPO
Expand Computer configuration
Expand Administrative Templates
Expand Group Policy
Look for the setting Group Policy Loopback Processing
Enable the policy
Set the policy to merge
Reboot your Computers
Policy should now be in effect
Avatar of cvservices


Thanks for the suggestion nappy. Unfortunately, that didn't actually merge the two policies.
To clarify, what i have is the following:
ICF - RDC - Admin Only - Subnets:
where : Computer Config / Admin Template / Network / Network Connections / Windows Firewall / Domain Profile / Windows Firewall: Allow inbound Remote Desktop exceptions: Enabled with exceptions:
x.x.x.x/24,x.x.x.x/24,x.x.x.x/24,etc ....


ICF - RDC - Admin Only - Hosts:
where : Computer Config / Admin Template / Network / Network Connections / Windows Firewall / Domain Profile / Windows Firewall: Allow inbound Remote Desktop exceptions: Enabled with exceptions:
x.x.x.x,x.x.x.x,x.x.x.x,x.x.x.x,etc ...

With or without the Loopback processing policy on, the only one that applies is that one that has the highest order wthin the policies.

Due to the length of the field for listing the allow subnets/hosts, I unfortunately cannot add all of them, as I run out of space...

I have tried to put the loop back processing policy in both GPOs, and in the one with the lesser priority, and neither seemed to work.

any other ideas?
Can you run gp result and post the output to show which policies are actually being applied to your workstations or server?
Sure... here you go.
Maybe you can reduce the number of entries by changing the masks. For example, instead of using and, use instead.

You can use a site like to figure out which adjacent networks can be notated with a supernet, and what the mask would be.
I don't think that's possible in my case, because my actual subnets are a Class A:
i.e:  --> --
and I need to target only within that subnet, hence, the

I have 34 subnets which are similar to the above. given that scenario, the subnets can't ever be adjacent ...unless there's something about this that I'm doing completely wrong, or I don't know about.
It doesn't matter what your actual subnet masks are, but only if they are adjacent and can described in a simpler statement. only if they can be If the subnets/IPs you need to allow are not adjacent, such as,,, etc. then my solution won't work. Other options include using GPO preferences to more directly modify the registry, and to use network level ACLs to filter the traffic.
Kevin, your scenario is exactly what I have, the subnets aren't adjacent. That's why I thought that it wouldn't work.

Your idea about GPO preferences or network ACLs sound like a possible alternative. Could you elaborate a bit on those?
Avatar of kevinhsieh
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Ah ... yeah, that sounds like it would be a good solution.
Let me give that a shot and I'll report back here.

Thanks Kevin.
so I checked registry as you had suggested. I was able to see all the policies, however, the scopes are not explicitely defined, except for when they target a local subnet.

The rule that I'm targeting, is the RemoteAdmin-In-TCP (among others), and though I know that the scope is currently applied (at least partially), by looking at the GUI, the registry entry doesn't seem to point to that scope within that key. perhaps there is a reference to another key that contains the scopes, but I couldn't find it anywhere by googling..  any ideas?

Here's the registry entry for the policy in question that currently has the scopes showing in the GUI:

Here's what I got when I manually created an entry for RDP-manual. You should be able to add the RA4= values.

Hmm. interesting. I wonder why it shows up differently when setup with a GPO. In my case I was trying it on Windows Server 2008 R2, I wonder if that makes a difference.
I will do a couple of tests on different clients, and see whether that would work.
That's gonna do be one long list of RA4 entries :) .. I hope there is no limit on a registry value field! yikes...
Looks like the registry piece works as you suggested.
The only problem with it, is that when it's applied, it doesn't do it like a normal GPO, meaning the firewall rule gets detected as being set by the user, as opposed to administratively, and the rules remain editable by the user.

I tried removing the rule completely, and doing a gpupdate /force just to make sure that the policy is applying correctly, and it is, the inbound policy gets set again,  but still editable.
Still trying to think if that's a compromise I'm willing to make, since this would create a security risk. Any ideas about this?
We're really close, I think if I can figure out the firewall policy lockdown via the registry, I'll be in good shape.
Sorry about the earlier post. The one by "gkhairallah" is actually cvservices.
Well, anyone with admin rights could add additional entries to the firewall policy to allow additional access anyway, so I don't think that there is much incremental risk. If you really want to lock it down, put in traffic filtering rules on your networking equipment.
I think your statement is partially true. If my memory serves me correctly, firewall policies that I had added in the past via the GPO ADM (not registry) were actually grayed out for the users (admin or not). the only difference that the admin had, was their ability to either add additional policies, but not remove existing ones (this was pertinence to Windows XP, i haven't tested the same for Windows 7 lately).

In any case, I think from this point on, I'll just have to fiddle with it to see what would be the best solution as far as that.

Thank you for pointing me in the right direction Kevin.
Thanks for the assist! much appreciated.
This is just a follow up to confirm some of the questions raised regarding GPO vs. Registry.
I have created 2 policies. One to setup the Remote Desktop scope via GPO, and the other via Registry.
When I applied the firewall via GPO, the firewall entry and the scope were grayed out for the user, even when the user was an admin on the workstation.

When I applied the firewall rule via registry push as suggested, the entry remained editable.

So, the bottom line is, while the registry push can have a lot of benefit in certain situations. I don't believe it's a viable solution to setup firewall rules on the workstations. (when the users have more than a regular user role on the workstation, which unfortunately, is the case in our environment)

It's too bad that this limitation is solely due to a UI limitation in GPMC. Wish there was a solution around that problem, to apply that policy via a the GPO adm instead of the registry push.
Your admin users can always create a new firewall entry, and allow all TCP connections from all networks, and be done with it, thereby bypassing all of your other firewall rules. A firewall GPO defining firewall exceptions isn't going to help that.
Good point. Unless I disable the : Allow local port exceptions maybe, and protect all network connections.
Of course, that may present a whole new set of problems in the cases where I do need to make local port exceptions :)
I believe I found the solution.
in GPO there are a few options for allowing port exceptions.
One, specific for Remote Desktop exception, which was the one that had the limitation of a short field, but then, there is another one: Define inbound port exceptions.
That one doesn't seem to have a field length limit. So I can just disabled the specific GPO for Remote Desktop, and enabled it explicitly within the inbound port exceptions, along with the scopes, and then disabled the "Allow local port exceptions",  and enabled "Protect all network connections", so that users can no longer change these settings.