Score:0

Server

Restrict GPOs to RD Session Host without loopback processing

duckbjarne

4/8/23, 3:02 PM

My aim would be to divide our huge "User" OU (not the default one!) into different sub-OUs from the respective department. Then, I want to link the GPOs to the different departments, but somehow "restrict" the application of them to the RD Session Host. I wanted to know if there is a way to accomplish that without having about 15 GPOs only linked to the "RD Session Host" OU and none to the department OUs. Plus, it would be nice to be able to have as little item level targeting as possible.

The reasons are: Looks nicer, faster administration, better overview.

I would want to accomplish that without third party software, i.e. :

https://www.policypak.com/resources/pp-blog/group-policy-loopback/

Could you also comment if you had run into the same issue as well?

Tell me if you know that it's not possible.

0 + 0

windows

active-directory

group-policy

Score:0

Server

Bernd Schwanenmeister

4/9/23, 9:28 AM

Since over 95 percent of GPOs are registry based, you may use the following easy-to-apply solution: locate the registry keys that are used by the GPOs. Deploy them using group policy preference ("GPP") items (as opposed to using standard GPOs). Within GPPs, you may use "item level targeting", which is a set of predefined WMI filters which allow to distinguish where to apply those GPPs.

0 + 0

Semicolon

4/10/23, 3:02 AM

Which conflicts with request you avoid Item-Level Targeting.

Bernd Schwanenmeister

4/10/23, 8:39 AM

Hi semicolon. Please try it out and see how easy the goal is reachable using that way using the targeting filter "terminal session" (maybe combined with "computer name") compared to other ways. It's not about conflicts.

Semicolon

4/10/23, 7:29 PM

I simply pointing out that the Questioner specifically asked a question with the phrase "it would be nice to be able to have as little item level targeting as possible." Your solution - while workable - completely ignores the posters request and relies exclusively on what the OP is trying to avoid.

Bernd Schwanenmeister

4/11/23, 1:17 PM

Ok, I got you wrong, because you mistyped "you avoid Item-level-targeting" instead of "to avoid ILT". Sorry, I did not see what you were pointing out. Right, if the Author is trying to have as little as possible, I cannot be sure what that means, but still wanted to show this ITL option to limit the application to terminal services and a specific host.

Score:0

Server

Semicolon

4/8/23, 3:43 PM

You could create a security group containing all of the computers in the RD Session Host OU, and then using Delegation or Security Filtering on your GPO(s) such that Domain Computers does not have read access and only the RD Session Host group has read access and Domain Users (or another more targeted group) has read and apply. Arguably, you could just put both groups into the Security Filtering of the GPO which would achieve the same thing (though would grant the Apply permission to the computers - which should have no effect as long as the GPO is not linked to their OU). Since GPOs are retrieved by the the computer account, ensuring that only the desired computers can retrieve the policy means that the GPOs should only apply to the users when logging into these machines.

Comments / Thoughts:

You cannot/should not prevent Domain Controllers from reading these GPOs, that would lead to unintended consequences - so using this technique, the GPOs would potentially apply if users were logging into a Domain Controller. That being said - administrative accounts with access to DCs should be in an entirely separate OU anyway.
Designing GPOs based upon "looks" (in my opinion) leads to potential complications in troubleshooting, definitely when bringing in outside collaborators, skilled new hires, and seeking assistance from a community (such as Server Fault)
I believe that the reasons you've laid out are all subjective - which is fine, I don't have to administer your environment

0 + 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Restrict GPOs to RD Session Host without loopback processing

TH: Restrict GPOs to RD Session Host without loopback processing

RO: Restrict GPOs to RD Session Host without loopback processing

RU: Restrict GPOs to RD Session Host without loopback processing

VI: Restrict GPOs to RD Session Host without loopback processing

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.