Share via

Group Policy : Filtering and Permission

  • Article

Introduction

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

However, the scope of a GPO can be further narrowed down by using different kind of filtering, which is as follows:

1) Security Filtering along with Delegation

2) WMI Filtering

3) Item Level Targeting

In this article, we will see how we 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 (Group Policy Object) is created, it applies to all user and computer accounts where it is linked.

The Scope of a GPO depends in few factors:

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

2) Whether any filtering is applied to the GPO.

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

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

 

“Authenticated Users” is not an AD group, but it is a security principle. It contains all user and computer accounts which have authenticated to the entire AD Forest.

 

“Authenticated Users” includes all user and computer accounts in the current domain (where the GPO is located), as well as all the users and computer 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 it applies to all authenticated users and computers which are within 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 not through Delegation Tab. One good example 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 “Apply Group Policy”.

• On the contrary, when we add any new entry through the Delegation tab, it will appear in the security filtering tab only 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 us that Enterprise Admins, Domain Admins and Creator have special access to the GPO. However, they do not have “Read” and “Apply Group Policy” access, so they are not part 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, you want to apply a GPO to selected computers in an OU. If you link the GPO to the OU, it will be applied to all computers within that OU, which you do not want.

How can you filter the list of computers in such case ? 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 DO 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 computer accounts.
  3. Now, remove “Authenticated Users” from the security filtering.
  4. Go to Delegation tab, click 'Advanced', and grant 'Read' access to Authenticated User. Please grant only 'Read' access and not any other access. Make sure that 'Apply Group 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. Go to those computers, and check if policies are applied. A GPUPDATE might be required.

Below screenshots explain the approach that we have followed to create “Test TechNet GPO 1”, edit the security filtering and linking it to the domain subhro.com. This GPO will only be applied to the 3 computers which we have mentioned in the security filtering, and not to any other computer.

Apply GPO to Selected Users

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

But 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 apply the GPO. In addition to that, we also need to add those computer accounts from where user will login. If user will login from different systems, then we have to add “Domain Computers” entry in the security filtering.

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

So the process of selectively applying GPO to a set of user accounts is follows:

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

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

We recommend reading this article as an additional reference in this context. Also, it is always better to test the behavior before large scale production deployment. 

Some additional points :

  • There should be a matching between GPO Scope and Security Filtering. For example, we are linking a GPO with OU1. However, in the security filtering we mention some accounts which are not present in OU1 but in OU2, and OU2 is not a sub OU of OU1. So in that case, the GPO will not be applied.
  • If we configure the computer configuration section of a GPO , but in the security filtering we specify user accounts, we will not get desired result.

 

So when designing scope of a GPO all these points should be considered. We should also consider factors like GPO enforcement and Block Inheritance while designing scope of a GPO, however these topics are beyond the scope of this article.

It is possible to link a GPO to another domain within the same forest. It is also possible to link GPO to another forest as long as there is forest trust.

In the previous section, we have created two GPOs:

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

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

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

Now, let’s try to link these two GPOs in another domain abc.subhro.com, which is a child domain of subhro.com.

As we can see:

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

The reason we cannot see the second GPO from abc.subhro.com is , it does not have “Read” access to the GPO. This is because when we removed the entry “Authenticated Users” .

Is there a solution to this problem? We want that the GPO would not be applied to Authenticated Users, but Authenticated Users should have read access so that the GPO can be 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 it.


**

**

Solution Approach 2

Instead of adding “Authenticated Users”, we can also add specific group of the other domain and grant Read access. 

In this case, if we add “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.

We recommend this approach, because this is more restricted and secure.

Removing permission after GPO linking

If we remove the “Read” access AFTER linking the GPO, that GPO will not function properly in other domains, and status will be shown as “Inaccessible”. 

*Warning: Although the GPO is showing inaccessible, please make sure that it is not applied to target.
*

Deny Access in GPO

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

Group Policy is no exception, and we 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 Test TechNet GPO1. Now, we are denying one particular account which is the member of this Domain Admins group.

Now when we login to the same account (having Deny Permission) in abc.subhro.com domain, we can see that the GPO is not accessible.

The “Deny” option is very useful when we would like to add security filtering for a large set of target (Authenticated Users / AD Group) but would like to exclude very few objects from that list. 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 certain conditions, for example based on specific hardware type or OS type or Server Role.

Let’s assume a scenario, where we would like to ensure that a particular GPO would be applied to an AD group containing 100 servers, most of which are 2012 R2 servers. But that AD group also contains few 2008 R2 servers. We do not want to apply the GPO on 2008 R2 servers, and we do not have time to identify and segregate those servers from the list.

So in this case, we can configure WMI Filtering to ensure that the GPO is only applied to those servers where OS is 2012 R2, and then we can include the AD group in the security filtering and will remove “Authenticated Users”. Obviously, we also need to link the GPO to the proper site / domain /OU. 

Using a complex WMI filtering can impact Domain Controller performance, and it can also make the Group Policy processing slow. 

While applying the GPO, WMI Filtering takes place before Security Filtering. While applying a WMI Filtering, please make sure that the target computers / users have “Read” and “Apply Group Policy” access selected, or in other words they are part of Security Filtering. Otherwise, they will not receive the GPO and WMI Filtering will not work. 

WMI filters consist of two parts separated by a semicolon:

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

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


**

**
Version 6.3 : Windows 8.1 & Windows Server 2012 R2

ProductType 3 = Server OS – Not a Domain Controller

AND : True when all of the specified conditions are met. False when at least one of the conditions is not met.

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

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

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

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

For WMI Filter Examples see here: Windows: Sample WMI Filter Strings

Item Level Targeting

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

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

**In such case, we need to use Item Level Targeting. **

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

In the above picture, we can see a classic 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 be applied to a limited set of users who meet both the below two criteria’s:

  • They are member of “AWSS3Users” AD group.
  • They login from “Kolkata” AD Site.

So we have used Item Level Targeting to accomplish this.

Putting Everything Together

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

A generic order of Group Policy Processing is as follows:

  1. Policies are loaded as per the hierarchy (LSDOU).
  2. GPO Scope 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 conflict with other policies. So this can be a real complex scenario, and the best solution is to plan it well and test it before implementation. Even after successful testing, it should be deployed in a phased manner in production to minimize the impact.

See Also