Table of Contents

  • Introduction
  • Default Permission of a GPO
  • Security Filtering and Delegation
  • Use GPO to Selected Computers
  • Apply GPO to Selected Users
  • Link GPO to a Different Domain or Forest
    • Solution arroyo one
    • Solution Approach 2
  • Removing permission after GPO linking
  • Deny Access in GPO
  • Group Policy WMI Filtering
  • Item Level Targeting
  • Putting Everything Together
  • See Also

Introduction

Nosotros tin can ascertain the scope of a Group Policy Object (GPO) by linking information technology to specific Site, Domain or OU. When we link a GPO to a Site, Domain or OU, by default information technology would be applied to all objects within that scope, unless it is restricted by applying "Block Inheritance" at a lower level.

However, the telescopic of a GPO can be further narrowed downwardly by using dissimilar kind of filtering, which is equally follows:

i) Security Filtering along with Delegation

2) WMI Filtering

3) Item Level Targeting

In this article, we volition see how we tin can implement these filtering and take granular control on the GPO target.

Default Permission of a GPO

As per the default setting, when a new GPO (Grouping Policy Object) is created, information technology applies to all user and reckoner accounts where it is linked.

The Scope of a GPO depends in few factors:

one) Where the GPO is linked to (Site /Domain/OU/Sub-OU)

2) Whether any filtering is applied to the GPO.

For instance: If we link a GPO to a domain, it applies to all user and computer accounts inside that domain.

This happens because when we create a new GPO, be default the entity "Authenticated Users" gets "Utilise To" access to the GPO.

"Authenticated Users" is not an Advertizement group, only it is a security principle. It contains all user and computer accounts which have authenticated to the unabridged AD Forest.

"Authenticated Users" includes all user and calculator accounts in the current domain (where the GPO is located), as well as all the users and estimator accounts which are located at trusted domains.

So in other words, when we create and link a new GPO, there is no Security Filtering and information technology applies to all authenticated users and computers which are inside the scope.


Security Filtering and Delegation

Group Policy Security Filtering displays those entities on which the GPO would be applied.

The Delegation tab shows the GPO ACL (Access Control List). We can view and customize permissions of a GPO, and grant / deny permissions at a granular level.

The "Security Filtering" and "Delegation" sections are linked in the following way:

• If any entry is added to the security filtering, it will reflect in the delegation tab as "Read (from Security Filtering". This means the entry has been added through Security Filtering tab and non through Delegation Tab. One good case is "Authenticated Users" entry which is present by default.

• For such entries which are entered through the Security Filtering tab, corresponding permissions in the Delegation Tab are: "Read" and "Utilise Group Policy".

• On the opposite, when we add any new entry through the Delegation tab, it will announced in the security filtering tab merely if it has "Read" and "Apply Group Policy" permission both. This is because to apply a GPO on an object, the object should have both "Read" and "Apply Group Policy" access.

In the below two screenshots, we can see the permission of the GPO.

• The "Security Filtering" tab shows us that this GPO is applied to all "Authenticated Users".

• The "Delegation" tab shows u.s. that Enterprise Admins, Domain Admins and Creator have special access to the GPO. Yet, they do non have "Read" and "Apply Group Policy" access, and so they are not role of security filtering.

Apply GPO to Selected Computers

This is one of the most common scenarios when we work in Group Policy.

One of the most common use cases for this is, yous want to apply a GPO to selected computers in an OU. If you link the GPO to the OU, it volition be applied to all computers within that OU, which you do not desire.

How can you filter the list of computers in such example ? There are few options, and the most common approach is customizing the default security filtering to meet our need.

For this kind of scenarios, follow this approach:

  1. Create and edit the GPO, but Practice Not link the GPO to any site, domain, OU at this stage. The GPO need to be created by write clicking "Group Policy Objects���.
  2. Go to the Security Settings and add figurer accounts.
  3. Now, remove "Authenticated Users" from the security filtering.
  4. Go to Delegation tab, click 'Advanced', and grant 'Read' access to Authenticated User. Delight grant only 'Read' admission and not any other access. Brand sure that 'Use Grouping Policy' permission is not selected for Authenticated users.
  5. Wait for Replication to complete to all Domain Controllers.
  6. Link the GPO to appropriate Site / Domain / OU.
  7. Get to those computers, and check if policies are applied. A GPUPDATE might be required.

Below screenshots explain the arroyo that nosotros accept followed to create "Examination TechNet GPO ane", edit the security filtering and linking it to the domain subhro.com. This GPO volition only be applied to the 3 computers which nosotros have mentioned in the security filtering, and not to whatever other computer.

Apply GPO to Selected Users

Before 14 June 2016, the process of applying GPO to a selected ready of users was same as the process nosotros discussed for computer account. That means, you could add those specific user accounts (or an Advertising grouping which contains those users) and and then remove "Authenticated Users" from security filtering, and so link the GPO to appropriate user OU.

B ut on 14-June-2016, Microsoft has released a patch which has changed this behavior. The Patch Name is MS16-072.

If this patch is installed in our environment, then adding user accounts / user groups in Security Filtering will not be sufficient to utilise the GPO. In addition to that, we also need to add those estimator accounts from where user volition login. If user will login from dissimilar systems, then nosotros have to add "Domain Computers" entry in the security filtering.

Microsoft released an article and confirmed that this change have been fabricated in society to resolve a vulnerability, which allowed an attacker to gain privilege and launch homo-in-the-middle (MiTM) attack confronting the traffic passing between a domain controller and the target machine.

And then the procedure of selectively applying GPO to a set of user accounts is follows:

No MS16-072 in the surroundings: Only add together user accounts in the security filtering

MS16-072 is present in the environment: Add both user business relationship and corresponding computer account.

We recommend reading this commodity as an boosted reference in this context. Also, information technology is ever better to examination the beliefs before large scale production deployment.

Some additional points :

  • In that location should be a matching between GPO Telescopic and Security Filtering. For example, nosotros are linking a GPO with OU1. However, in the security filtering we mention some accounts which are not present in OU1 simply in OU2, and OU2 is non a sub OU of OU1. So in that case, the GPO volition not be applied.
  • If we configure the computer configuration department of a GPO , but in the security filtering we specify user accounts, we volition not get desired upshot.

Then when designing scope of a GPO all these points should be considered. Nosotros should besides consider factors like GPO enforcement and Cake Inheritance while designing scope of a GPO, however these topics are beyond the scope of this article.

Link GPO to a Dissimilar Domain or Forest

It is possible to link a GPO to another domain within the aforementioned forest. It is likewise possible to link GPO to another forest every bit long equally at that place is forest trust.

In the previous department, we have created ii GPOs:

Test Technet GPO: No Security Filtering (Applied to all Authenticated Users)

Test Technet GPO1 :  Custom  Security Filtering ( Applied to selected calculator accounts)

Both these two GPOs are created in subhro.com domain.

At present, let'southward endeavor to link these 2 GPOs in another domain abc.subhro.com, which is a child domain of subhro.com.

As we can see:

  • Test TechNet GPO is nowadays in the list, and we are able to link this GPO to abc.subhro.com domain.
  • Examination TechNet GPO1 is Non present in the list, so we are unable to link it.

The reason we cannot see the 2nd GPO from abc.subhro.com is , it does not have "Read" admission to the GPO. This is because when we removed the entry "Authenticated Users" .

Is in that location a solution to this problem? We want that the GPO would not be applied to Authenticated Users, but Authenticated Users should accept read admission and then that the GPO can exist linked.


Solution approach 1

Provide 'Read" access to Authenticated Users, but not "Apply GPO" access.

This way, both the purposes would be solved. The GPO would not be applied to all computers and users, but we will be able to view it and link information technology.

Solution Approach 2

Instead of adding "Authenticated Users", we tin as well add specific grouping of the other domain and grant Read access.

In this case, if we add together "Domain Admins" group of abc.subhro.com domain, and then we login to a Domain Controller of abc.subhro.com as Domain Admin, we will be able to link the GPO.

Nosotros recommend this approach, considering this is more restricted and secure.


Removing permission after GPO linking

If we remove the "Read" admission AFTER linking the GPO, that GPO will non function properly in other domains, and status volition be shown as "Inaccessible".

Alert: Although the GPO is showing inaccessible, delight make sure that it is non applied to target.

Deny Access in GPO

One of the thumb rules of permission is: Deny access always overrides Allow admission. This means, if an object is member of multiple let groups just at least one deny group, effective access would exist deny.

Group Policy is no exception, and nosotros tin can configure "Deny" access through the delegation tab.

In the previous example, we have granted "abc.subhro.com\Domain Admins" read access to the GPO Examination TechNet GPO1. Now, we are denying 1 particular account which is the fellow member of this Domain Admins grouping.

Now when nosotros login to the aforementioned business relationship (having Deny Permission) in abc.subhro.com domain, we can run across that the GPO is non accessible.

The "Deny" choice is very useful when nosotros would similar to add security filtering for a large ready of target (Authenticated Users / Advertisement Group) merely would similar to exclude very few objects from that listing. In such cases, we can add the AD Group in the Security Filtering and then add those few objects in the Deny list.

Group Policy WMI Filtering

Group Policy WMI filtering is very useful when we would like to filter a GPO based on sure conditions, for example based on specific hardware blazon or Bone blazon or Server Role.

Permit's assume a scenario, where we would like to ensure that a item GPO would be practical to an AD grouping containing 100 servers, well-nigh of which are 2012 R2 servers. But that Advert grouping also contains few 2008 R2 servers. We do not want to apply the GPO on 2008 R2 servers, and we do non have time to place and segregate those servers from the list.

So in this instance, nosotros tin configure WMI Filtering to ensure that the GPO is only applied to those servers where Bone is 2012 R2, and so nosotros tin include the AD grouping in the security filtering and will remove "Authenticated Users". Obviously, we also demand to link the GPO to the proper site / domain /OU.

Using a complex WMI filtering can impact Domain Controller operation, and it can also brand the Grouping Policy processing irksome.

While applying the GPO, WMI Filtering takes place before Security Filtering. While applying a WMI Filtering, please make certain that the target computers / users take "Read" and "Apply Group Policy" admission selected, or in other words they are part of Security Filtering. Otherwise, they will not receive the GPO and WMI Filtering volition not work.

WMI filters consist of two parts separated by a semicolon:


  1. Namespace:  This contains the object grade, which we are going to use in the query.
  2. Query: The WQL-based query is used to ascertain the filtering criteria.

In this example, we are creating a WMI Filter , and so that the GPO would be applied simply to 2012 R2 servers , excluding Domain Controllers.

Version 6.3 :

Windows eight.ane & Windows Server 2012 R2

ProductType 3 = Server Os – Non a Domain Controller

AND : Truthful when all of the specified conditions are met. Simulated when at to the lowest degree i of the weather condition is not met.

OR : True if at least one of the conditions are met.

Once the WMI filter is created, link it to whatsoever GPO.

Please note that it is non possible to link multiple WMI filters with a single GPO. If at that place are multiple filtering criteria's, add those in a unmarried WMI filter using AND / OR Boolean operators.

WMI Filtering is a vast topic, which is beyond the telescopic of this article and requires defended discussion.

Particular Level Targeting

Using Security Filtering and WMI Filtering, we can configure whether an unabridged GPO would be applied or not applied on a specific target.

But what if nosotros want part of the GPO to apply, and part of the same GPO not to apply to specific target?

In such case, nosotros need to employ Item Level Targeting.

Delight note that Item Level Target is a feature of Grouping Policy Preference, which is nowadays in both User Configuration and Computer Configuration. Each policy within preferences can be configured for Item Level Targeting.

In the in a higher place motion-picture show, nosotros can run across a archetype deployment of Item Level Filtering. We have a GPO which has multiple policies. Out of all policies, we want that the "Drive Maps" policy would only exist practical to a express set of users who encounter both the below 2 criteria's:

  • They are member of "AWSS3Users" AD grouping.
  • They login from "Kolkata" AD Site.

So we have used Particular Level Targeting to accomplish this.


Putting Everything Together

What if we are using Security Filtering, WMI Filtering and Item Level Targeting on the aforementioned GPO? What would be the end result?

A generic gild of Group Policy Processing is as follows:

  1. Policies are loaded as per the hierarchy (LSDOU).
  2. GPO Telescopic is checked. WMI Filtering is checked.
  3. Security Filtering is checked.
  4. Item Level Targeting is checked.

However, there are other factors like Block Inheritance, Enforcement and disharmonize with other policies. So this tin can be a real complex scenario, and the best solution is to plan information technology well and test it before implementation. Fifty-fifty after successful testing, it should be deployed in a phased manner in production to minimize the impact.

Come across Also

  • MS16-072: Security update for Group Policy
  • Who broke my user GPOs?
  • Fun with WMI Filters in Group Policy
  • OS Version Queries for WMI Filters
  • Using Detail-Level Targeting with Group Policy Preferences