In Group Policy permissions, Allow is a suggestion and Deny is a verdict. A single Deny Apply Group Policy — inherited through a group nobody remembers joining — outranks every Allow on the GPO and leaves no error message behind, just a policy that politely never arrives.
Security filtering evaluation is short and ruthless: the account needs Read and Apply, and if any of its group memberships carries a Deny for Apply Group Policy (or for Read), the GPO is rejected — full stop, no matter how many Allows sit beside it. Deny exists for one good reason: exclusions. Used deliberately it is surgical. Used casually it is the hardest filtering bug to find, because the console shows your neat Allow while the Deny hides one tab deeper. This page covers both faces.
Example entries — the Deny line is the entire exemption mechanism, and the entire risk.
When the client processes a GPO, it collects every access entry that matches the account — the account itself plus every group it belongs to, including nested groups — and applies the permission rule Windows uses everywhere: an explicit Deny beats any Allow. For Group Policy there are two permissions that matter. Deny Read and the GPO cannot be fetched or evaluated at all. Deny Apply Group Policy and it can be read but will not be applied; the report records it as filtered out for security.
There is no priority list, no “but this Allow is more specific”. One Deny, from any depth of group nesting, ends the discussion. Once you accept that, both the power and the danger of the tool become obvious.
Deny earns its place when the audience is “everyone except”. Real examples that recur in real domains:
Notice what these share: a small, named, reviewed set. Deny is for exceptions you can list on one line.
All three share one trait: Deny is nearly invisible in daily console use. The Scope tab shows the filter; Deny lives in Advanced security, one layer down, where nobody browses for pleasure.
gpresult /h report.html on the affected machine as the affected user. Denied (Security) on a GPO the user should receive is your starting gun.whoami /groups in the user's session to list the full token — including the nested memberships the user picked up through other groups.House rule for this set: prefer positive filtering; reserve Deny for true exceptions. If the audience is “department X”, say so with an Allow group — do not apply to everyone and Deny the other eleven departments. Reach for Deny only when the audience genuinely is “all of these people, minus these named few”, and then make the exception discoverable: a group named for its purpose (GPO-EXEMPT-Admins), the reason and a review date in the GPO's comment, and a quarterly glance at the Advanced security of your most-filtered GPOs. An exemption you can find in thirty seconds is a tool. An exemption you cannot find is a landmine with a timer you cannot read.
The video opens the Delegation and Advanced security views where Allow and Deny actually live — the screens this page keeps sending you to.
▶️ Watch Full VideoDeny wins, always. Group Policy follows the standard Windows permission rule: any applicable Deny for Apply Group Policy (or Read) overrides every Allow, regardless of which group supplied it or how the groups are nested.
Yes. Deny Apply means the GPO is fetched and listed but skipped as filtered out. Deny Read means the account cannot read the GPO at all, so it cannot be evaluated or applied — the blunter instrument, and rarely the one an exemption actually needs.
Not directly — user settings are evaluated against the user's permissions, not the machine's. To shape what happens on one machine, the tool is loopback processing on that machine's OU, with filtering applied to the GPOs in the computer's path.