Someone asked me recently what I thought of using Deny ACEs on GPOs for security group filtering. First, a little background.

As you probably know, you can control which users and computers will process a particular GPO by using security filtering on that GPO. The GPMC exposes this through the “security filtering” dialog on the Scope pane of a particular GPO, as shown below:

By default, the Authenticated Users group, which includes all computer and user accounts in the domain, is granted the “Read” and “Apply Group Policy” permissions on any newly created GPOs. The read permission, as the name implies, allows the user or computer to read the contents of the GPO, stored in AD & SYSVOL. The Apply Group Policy permission is really the key permission that determines whether or not the target will actually process this GPO. Without that permission, the GPO is ignored. Also, by default, when you add a user or computer (or group) to the Security Filtering dialog within GPMC, the Read and Apply Group Policy permissions are added as an “Allow” Access Control Entry (ACE). But you can also define “Deny” ACEs for a given security principal. This has the effect of preventing a particular target from processing a GPO.

Why & How: Deny ACEs

The need to define a Deny ACE on a GPO should be fairly infrequent. I usually recommend that people use Deny ACEs on an exception basis only, and only if its necessary. The most common scenario where a deny ACE comes in handy is when you are targeting a GPO to a large audience (for example, the GPO is linked at the domain and the default Authenticated Users group has Read and Apply Group Policy permissions—meaning that all users and computers in the domain will process that GPO) and you want to exclude a small subset of users or computers from that GPO. Since the GPO is linked at the domain, it is otherwise difficult to make such an exclusion without a Deny ACE.

Unfortunately, defining a Deny ACE on a GPO is not as simple as adding a normal Allow ACE. There is no option you can check when you’re adding a target group that lets you say, “hey, this is a Deny ACE”. Instead, here’s what you’ll need to do.

1. In GPMC, focused on a GPO, switch to the Delegation tab and pressed the Advanced button in the lower right corner.
2. When the familiar ACL editor comes up, press the Add button to add the computer, user or group that you want to Deny to the GPO.
3. With that security principal highlighted, you’ll notice that the Read permission is currently set to allow—you can leave that alone. But what you want to do is check the box in the “Deny” column for “Apply Group Policy”, and then select the OK button to confirm. You can see this is in the figure below, where I’ve set the “Marketing Users” group with a Deny ACE on the GPO.

The Downside

While the Deny ACE can be useful for blocking a GPO from a sub-population of users or computers, it has some downsides. The primary downside is its lack of transparency within the GPO toolset. If you look at a GPO that has a deny ACE on it, there is no obvious indication of it unless you are really looking. For example, if you look at the Security Filtering dialog on that same GPO that I set a Deny ACE on for the Marketing Users group, what do you see (below)?

Absolutely nothing! No evidence of that Marketing Users group or the Deny ACE. In fact, you have to go back to the Delegation tab to see the group and even then, all it shows is that there is a “Custom” permission for that group—no evidence of the Deny.

If you are trying to troubleshoot GP processing issues, and you aren’t the one who defined the Deny ACEs on a given GPO, it can be confusing finding the problem. If you run an RSoP report (GP Results) against a target machine, it may show a GPO denied to a target user or computer because of security filtering reasons, but it may not be obvious, in looking at the GPO, why that is, unless you specifically look at the Delegation tab.

So, in large environments or environments with many GPOs and many different people administering GPOs, over-use of Deny ACEs can result in time-consuming confusion.

But this mechanism does have value, and as long as you use it judiciously, it can provide a way to exclude populations of users or computers when you’re in a bind and need to do so. That is way I would approach it—as something you do infrequently rather than as a normal course of your job as a GPO administrator.

Darren