Experienced trivia-7, or "Mergers and acquisitions in the Group Policy"

The continuation of "experienced trifles." Previous parts: one , two , three , four , five , six .

Today we will talk about one interesting parameter in Group Policy. Yes exactly. A single parameter that can make your life easier (or complicate it, this is also possible)


The task was set very simple:
It is required that certain users, entering the terminal server, have a SuperMinimum set of permissions. Could not change anything on the desktop, did not see the disks, could run only pre-defined applications (1C, Consultant +, Word, Excel), etc. At the same time, everyone else, accessing the same terminal server, should receive a full set of rights. Well, this should only concern this particular terminal server, on the workstations all users are approximately equal.
')
It would seem that something easier - set up a group policy and forward to the tanks. However, as in the old joke, "There is a nuance!". If we are talking about setting up the user's environment (prohibiting the display of disks, customizing the desktop, etc.), then these parameters apply to users (logical!), And the question arises: where exactly to apply our policy.

If we apply to the OU, which contains users, then they will have a SuperMinimal set of rights everywhere, including on their work computers, which was not part of our plans.

If you apply this policy on the OU in which the terminal server is located, then the user settings will simply not be applied, since they are listed in the User Configuration category, and will have no effect on the server.

And here the above-mentioned interesting parameter enters into battle in Group Policy. Write: Computer Configuration - Administrative Template - System-Group Policy - User Group Policy Loopback processing mode -Merge (or Replace)

We do something like this:

• Create a group Pol_RestrictTerminalUsers and bring in it the people who need to set the specified restrictions
• Create a RestrictTerminalUsers policy
• We expose in policy all those user (!) Restrictions that we need
• Set the above parameter to Enable-Merge
• We use it on the OU, which contains the terminal server we need (it is logical, by the way, to put it in a separate OU so that the policy does not affect neighboring computers)
• In the Security Filter of this policy, remove Authenticated Users and add the Pol_RestrictTerminalUsers group, as well as (!!) the terminal server itself
• As a result, when a user in the Pol_RestrictTerminalUsers group logs into this terminal server, not only his usual user policies are applied to him, but also our new RestrictTerminalUsers policy, and its user values ​​take precedence over values ​​from other policies.
• For users who are NOT in this group, the Security Filter is triggered, and no additional settings are applied to them. Thus, we get the following: when a user logs on to a terminal, a session is configured in one way, another - another, and this is all controlled very simply through groups in AD.
• At their workstations, users still have everything.

As required. And finally, a couple of comments:

1. Merge mode "merges" all user settings, and Replace mode replaces them. We usually use Merge , because in previous policies there may be parameters (for example, pluggable disks, printers, etc.) that do not need to be changed. You can read more about Replace and Merge , for example, here.
2. When using Loopback processing in Merge mode, the policy actually runs twice, consider this if you use Logon-scripts. For example, I have long blown the roof. It is clearly seen that the script works twice, with a break of 0.5 -1 sec, but I could not understand the reason until I read in more detail about Loopback processing.

To be continued