Using GPO’s to apply settings to users and computers have always been a great way to make administration and deployments more seamless for admins and users.
Working with many different customers, where IT has various experience with this, I see a lot of misconfigured Group Policies, so why not write a post about it.
Group Policy is a powerful tool, and if a GPO gets incorrectly configured it can have dramatic impact on both users, computers and servers for the organization, this can happen by simple human error as well as lack of understanding how to configure this correctly.
Now, if you want to limit the impact ration for what the GPO settings applies to, you have a few options. I will walk through the basics here.
WMI filtering
Group Policy WMI filters were introduced with Windows XP, and are supported in Windows Server 2003, Windows Vista, and Windows Server 2008. They are not supported in Windows 2000 .
WMI filters makes it possible to set common criteria for when the GPO should take effect. They can be useful if your AD structure is relatively flat and not organized with separate OU’s for different objects in AD.
They also give the possibility to apply settings based on OS version, network, server roles and various criteria.
For creating WMI code you can use the following tool (WMI Code Creator) to help you out:
https://www.microsoft.com/en-us/download/details.aspx?id=8572
For instance, you could create a policy for deploying Citrix Receiver to the computers in the organization.
With WMI filter, you can then put this policy on the top level of the domain – along with the Default Domain Policy, apply a WMI filter so the GPO only applies to computer objects with a desktop operating system.
This will ensure that all computers in the domain, regardless of OU placement for the Computer Account in AD, gets the GPO applied, while servers do not get the gpo. Simple example.
Filters are evaluated in the following order – top to bottom.
- Policies in hierarchy are located.
- WMI Filters are checked.
- Security settings are checked.
- Finally, once everything has passed, a policy is applied.
So, we find all the policies that exist in the user/computer’s Local, Site, Domain, and OU hierarchy.
Then we determine if the WMI filter evaluates as TRUE.
Then we verify that the user/computer has Read and Apply Group permissions for the GPO.
This means that WMI filters are still less efficient than hierarchical linking, but we can use filters to make decisions in a non-hierarchical Active Directory design.
OU link with Security Filtering
This is perhaps the most wildly used option, and the one where I personally see the most misconfiguration.
You create a GPO with needed settings, the GPO gets linked to a container in AD (OU), and you set the security filtering to decide who and what within the OU the GPO applies to.
When you create a GPO, the default security filtering is set to Authenticated Users – and this is where the mistakes often happen.
So, what exactly is Authanticated Users?
The following article gives some insight to this.
https://www.morgantechspace.com/2013/08/authenticated-users-vs-domain-users.html
The Authenticated Users group contains users who have authenticated to the domain or a domain that is trusted by the computer domain. Authenticated Users will contain all manually created user accounts in all trusted domains regardless of whether they are a member of the Domain Users group or not. Authenticated Users specifically does not contain the built-in Guest account, but will contain other users created and added to Domain Guests.
The following list shows the members who are fall under this group
- All the domain users and users who are in trusted domain.
- Local computers.
- Built-in system accounts.
This makes a GPO with authenticated users as the security filtering, pretty much apply to anything within the linked OU, meaning this could cause some serious mayhem if the GPO gets linked to the wrong OU, or even worse, at top domain level.
It is ok to to this if you want the GPO to apply to everything in the linked OU, but be certain about the settings in the GPO and the expected audience, before you enable the link.
If you wish to edit the Security Filtering to apply only to a selected AD Group containing users/computers/server, I regularly see that the admin just removing the Authenticated Users group from the Security Filtering like so:
They then get the following message, which they of course just answers OK to, without reading:
And then adds the other group they want to apply the settings to, they then get surprised that the GPO is not applying to their user/computers.
The reason for this is that when you remove the Authenticated Users group from Security Filtering, both read and apply permissions are removed from that group.
If you want the settings to apply to a specific group, you still need Read permissions for the Authenticated Users group on the GPO.
This can be controlled by going to the Delegation tab after you have selected a GPO.
In the security tab, select authenticated Users, and check that Read is allowed, and that the box for allow under Apply Group policy is unchecked.
After you have removed the Apply checkbox, you can go back to the Scope tab, and will see that authenticated users group no longer exists under Security Filtering, and you can add the wanted group here. Now Authenticated Users group still has Read permissions, and your GPO will apply as expected.
Another example of things I see regularly is when the Security filtering contains both authenticated users group and the administrators selected groups.
This will just not work, if you want to regulate the Security Filtering, be sure to only apply read permissions to the Authenticated Users group, otherwise your settings will most likely apply to more then what you intentionally wanted.
Group Policy Preferences – Item level targeting
The 2 previous options revolve around how you can use different approaches to apply a Group Policy to selected objects.
This goes for all settings in the specified GPO.
Now, with Group policy Preferences you can have the same GPO apply different (or same) settings to different objects based on different criteria.
This primarily goes for the settings available under the Prefrences folder under Computer/User configuration when editing a GPO.
A common example of this is drive mappings:
Go to user configuration\prefrences\windows settings\drive maps and add a new drive
Fill out as needed, and click the common tab.
Click the Item-level targeting checkbox, then the Targeting button
You then come to the Targeting editor where you can specify the criteria for when the setting should apply/not apply, and the options give you a fair share of flexibility
To make a meaningless example, you could add something like this
Making the drive only get mapped if the user is a member of Domains users, and the users computer has 512MB of free ram or 80GB free disk space on his/her computer.
This makes it possible to reduce the number of needed GPOs for similar settings, and rather use the same GPO with Item-level Targeting to specify when where and on what the polciy is to go in to effect.
As you can see there are a lot of options available for customizing GPO’s in a flexible way.
Hope this clears up some confusion for anyone.
Some other pages with information around the subject:
https://www.thewindowsclub.com/group-policy-for-beginners-guide-from-microsoft
Consultant manager & SME @ iteam, localized in Kristiansund, Norway.
Focused on EUC, security, mobility, virtualization, management and a modern workplace. Highly specialized around RDS/Citrix/EUC/Mobility.
