The standard way of targeting Group Policy is by linking the GPOs to Sites, Domains or Organizational Units. This is fine for many scenarios but it has some drawbacks. An important one is when you want to have a large number of users or computers in one OU i.e. the “New York Users” OU but you also want to apply a specific GPO to a subset of users.
There are a couple of ways to do this:
- Security Filtering
- WMI Filtering
In this post I’ll explain how Security Filtering works and some of the considerations, specifically about whether to remove the “Authenticated Users” group.
First things first – the GPO must be in scope
In order for Security Filtering to have any relevance, the GPO must first be in scope. What this means is that the GPO must be linked to a Site, Domain or OU that contains the user or computer object you want the setting to apply (or not apply) to.
Remember if you have a user who is a member of a group named “Marketing Users” and the Marketing Users group is in the OU, then this will have no impact on the GPO scope. GPOs only apply if the actual user or computer account itself is in the OU.
In order to GPOs to apply to the user or computer, the user or computer must have 2 permissions on the GPO:
- Apply group policy
By default, the Authenticated Users Group is present on a GPO and has both Read and Apply group policy rights. And don’t be confused by the name, Authenticated ‘Users’ are not just user accounts, these are all authenticated objects within the domain, which include User and Computer accounts. Computer accounts are like users in many ways in that they have a username and password associated with them and they actually login to the domain when they boot up and establish a secure channel.
How to stop specific users or computers from getting the GPO applied
So in order to stop a user or computer (that is within scope) from getting a policy, you remove the rights on the GPO for that user or computer.
For example, if we had a GPO linked to the “London Users” OU which locked down the desktop, and we wanted this to apply to all users except for the “IT Support team” whose user accounts are also in the “London Users” OU . We would do the following:
- Create a security group for the “IT Support Team”
- Add this group to the GPO and DENY it permissions from applying the Group Policy (leave Read enabled)
This would ensure everyone except the IT Support Team would get the locked down settings and would look like this:Now the reason I only denied the “Apply group policy” but left the Read enabled is because if I denied the read permission and if one of the IT Support Team users was also one of the people that administers Group Policy, then they would lose the right to Read the GPO within the Group Policy Management Console. The would see a message saying inaccessible. Removing the “Apply group policy” is all I need to do to stop the policy applying. Be aware that deny takes precedence over any allow. Also be aware that we are dealing with GPO permissions on a GPO by GPO basis, so if you deny a group from having rights on one GPO, that won’t affect their rights on others.
Never remove the Authenticated Users Group”
Until June 2016 many people would remove the Authenticated Users group and just give permissions to the user accounts for example that they want the policy to apply to. However in June 2016 Microsoft released a security patch that slightly changed the way group policy filtering works. Computers now process the GPO under the computer’s security context. What this means in practice is that the computer that the policy setting is processing on, even if it’s a user setting, must have the rights to read the GPO. Therefore it’s highly recommended that the Authenticated Users group maintains Read permissions to all GPOs.
See the following articles for more information:
How to ensure only particular users or computers get the GPO
The other scenario is where you want to only allow the GPO to apply to specific user or computer groups. i.e. you only want the “Sales Users” team to get the GPO, all other users in the OU should not get it.
In this case you should do the following:
- Modify the GPO permissions so that the Authenticated Users group has Read but NOT “Apply group policy” (i.e. untick the box)
- Add the “Sales Users” group to the GPO and give then Read and Apply group policy permissions
In the examples above I’ve been going it to the GPMC, clicking on a GPO, going to the delegation tab and then modifying the ACLs directly. Within the GPMC on the Scope tab you have the ability to Add security groups. Anything you add here will automatically get the “Read” and “Apply group policy” permissions. This is the preferred and probably safer way to give groups of users or computers access to the GPO, however it’s now required to keep the Authenticated Users with Read permissions due to the change in behaviour mentioned above.
It’s worth saying that the Domain Admins group as you may have seen also have Read permissions to the GPO, so even if you removed Authenticated Users, if you were a domain admin you’d still be able to read it. But if you were a GPO Admin but NOT a domain admin then you may get the inaccessible GPO message.
If you’re adding explicit DENY permissions then you also need to modify these directly using the Security Dialog box.
So what’s best practice?
In most scenarios, if you need to apply security filtering I’d recommend:
- Keeping Authenticated Users with Read but remove the Apply group policy permissions
- Then add the groups you want to have permissions using the “Security Filtering” Add button on the Scope tab in the GPMC
Use the deny approach only where you want to apply to all except for a single explicit group and it would be too cumbersome to manually add all the groups that you want to give access.