Avatar of cvservices
cvservices
Flag 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.
Microsoft Server OSActive Directory

Avatar of undefined
Last Comment
cvservices

8/22/2022 - Mon
Irwin W.

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
cvservices

ASKER
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 ....

AND

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?
Irwin W.

Can you run gp result and post the output to show which policies are actually being applied to your workstations or server?
I started with Experts Exchange in 2004 and it's been a mainstay of my professional computing life since. It helped me launch a career as a programmer / Oracle data analyst
William Peck
cvservices

ASKER
Sure... here you go.
gpresult.html
kevinhsieh

Maybe you can reduce the number of entries by changing the masks. For example, instead of using 192.168.0.0/24 and 192.168.0.1/24, use 192.168.0.0/23 instead.

You can use a site like http://www.subnet-calculator.com/subnet.php?net_class=B to figure out which adjacent networks can be notated with a supernet, and what the mask would be.
cvservices

ASKER
I don't think that's possible in my case, because my actual subnets are a Class A:
i.e:
10.40.48.0/21  --> 10.40.48.0 -- 10.40.55.0
and I need to target only 10.40.52.0 within that subnet, hence, the 10.40.52.0/24

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.
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
kevinhsieh

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 10.40.52.0/24, 10.41.52.0/24, 10.44.38.0/24, 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.
cvservices

ASKER
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?
ASKER CERTIFIED SOLUTION
kevinhsieh

Log in or sign up to see answer
Become an EE member today7-DAY FREE TRIAL
Members can start a 7-Day Free trial then enjoy unlimited access to the platform
Sign up - Free for 7 days
or
Learn why we charge membership fees
We get it - no one likes a content blocker. Take one extra minute and find out why we block content.
Not exactly the question you had in mind?
Sign up for an EE membership and get your own personalized solution. With an EE membership, you can ask unlimited troubleshooting, research, or opinion questions.
ask a question
cvservices

ASKER
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.
Experts Exchange has (a) saved my job multiple times, (b) saved me hours, days, and even weeks of work, and often (c) makes me look like a superhero! This place is MAGIC!
Walt Forbes
cvservices

ASKER
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.
i.e:
v2.10|Action=Allow|Active=FALSE|Dir=Out|Protocol=6|RA4=LocalSubnet|RA6=LocalSubnet|App=%SystemRoot%\system32\svchost.exe|Svc=upnphost|Name=@FirewallAPI.dll,-32821|Desc=@FirewallAPI.dll,-32822|EmbedCtxt=@FirewallAPI.dll,-32752|

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:

v2.10|Action=Allow|Active=FALSE|Dir=In|Protocol=6|LPort=3389|App=System|Name=@FirewallAPI.dll,-28753|Desc=@FirewallAPI.dll,-28756|EmbedCtxt=@FirewallAPI.dll,-28752|
kevinhsieh

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

In|Protocol=6|Profile=Domain|LPort=3389|RA4=10.40.52.0/255.255.255.0|RA4=192.168.2.0/255.255.255.0|RA4=10.90.50.0/255.255.255.0|Name=RDP-manual|
George Khairallah

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...
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
cvservices

ASKER
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.
cvservices

ASKER
Sorry about the earlier post. The one by "gkhairallah" is actually cvservices.
kevinhsieh

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.
All of life is about relationships, and EE has made a viirtual community a real community. It lifts everyone's boat
William Peck
cvservices

ASKER
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.
cvservices

ASKER
Thanks for the assist! much appreciated.
cvservices

ASKER
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.
Get an unlimited membership to EE for less than $4 a week.
Unlimited question asking, solutions, articles and more.
kevinhsieh

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.
cvservices

ASKER
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 :)
cvservices

ASKER
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.
This is the best money I have ever spent. I cannot not tell you how many times these folks have saved my bacon. I learn so much from the contributors.
rwheeler23