MS16-072 Breaks Security Filtering on Group Policy Objects

This update makes permanent changes in the way Security Filtering on GPOs needs to be configured. First, read this. Pay close attention to this part:


All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.


This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.


To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:

  • Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
  • If you are using security filtering, add the Domain Computers group with read permission.

A note on that last item under Resolution in the quote above: You are technically always using Security Filtering on GPOs. By default, the Authenticated Users object is applied to the Security Filtering on every newly created GPO. If you are looking at a GPO in GPMC, and you notice that Security Filtering is blank, then that policy isn’t being applied to any users or computers. Due to the changes made by the update, the computer account always requires Read permission on the GPO — this is by design:

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the computer’s security context.

The bottom line is that you can grant Read permission to either the Domain Computers or Authenticated Users group under the delegation tab of the GPO, and that will fix the problem with the GPO not being applied. Neither of those groups need Apply permission unless they contain users or computers that are being targeted by the GPO, that aren’t already being targeted by Security Filtering.

When I first encountered this issue, I noticed quite a few recommendations to “just rollback the patch” — this is not the correct course of action! The trouble caused by MS16-072 was not the result of a bug or poorly tested code, it was intentional, so if you remove the patch, you risk making yourself vulnerable to whatever threat(s) that were severe enough to prompt Microsoft into making such a potentially disruptive change. Besides, the “fix” is easy.

How might this affect your processes? What does this mean from here on out?

For Security Filtering to work on GPOs, you can no longer simply remove the Authenticated Users group, and then add your targeted objects (Users, Computers, Groups). The Authenticated Users group now requires Read access to the policy 100% of the time, otherwise the policy will not apply.

Why would anyone remove Authenticated Users from Security Filtering to begin with? Because, that group includes any User or Computer account on the domain, so let’s say you wanted a GPO to a subset of Users or Computers in an OU. In the past you would remove Authenticated Users from Security Filtering, create a new Security Group, add your desired Users or Computers to that group, then add that group to Security Filtering and link that GPO to proper OU. This is a convenient way to exercise precise control over GPOs.

Note, this update does not permanently take away this precision, it just means that if you had policies where the Authenticated Users group was removed, you need to add it back with Read access via the Delegation tab in Group Policy Management:

Add authenticated users back to GPO

But my GPO only targets a tiny subset of Users — I don’t wanna grant Read permission to the Authenticated Users or Domain Computers groups!

Ugh. Fine. The following will work but I don’t recommend it. If you recall from earlier, after this update User GPOs are retrieved via the Computer security context, so the Computer account of the computer that the user is logging into needs Read access to the GPO. Warning: this might will be hard to maintain in larger environments with lots of GPOs:

  1. Create a Security Group containing the Computers that are being used by the Users who require the settings contained by your GPO. For example, if your GPO targets user1, user2, and user3; and those users use computerA, computerB, and computerC respectively, create a Security Group that contains those computer objects.
  2. Grant Read permission on the GPO to that Security Group via the Delegation tab. If you don’t want to use a Security Group, then grant read access to the computer (if “computers” then you *really* should be using a group), directly.
  3. Apply Security Filtering to the users as you normally would.

Further Reading:

One thought on “MS16-072 Breaks Security Filtering on Group Policy Objects

  1. Pingback: Removing software that was originally deployed via Group Policy | Under The Desk

Comments are closed.