30 juni, 2016 at 1:42 PM

https://sdmsoftware.com/group-policy-blog/bugs/new-group-policy-patch-ms16-072-breaks-gp-processing-behavior/

Microsoft has sqeezed in a path for a vulnarability  

This security update resolves a vulnerability in Microsoft Windows. The vulnerability could allow elevation of privilege if an attacker launches a man-in-the-middle (MiTM) attack against the traffic passing between a domain controller and the target machine. 

 

It turned out that the fix was a bit problematic for folks who had set per-user security group filtering in their GPOs, as shown in the figure below. GPOs set up this way were no longer being processed after the patch was applied to client systems.

Specifically, if you’d set security group filtering for GPOs that contain per-user settings, and you’d removedAuthenticated Users completely from the GPO’s delegation, then GPO processing for per-user settings would fail after applying MS16-072.  As the day went on, I mostly ignored this issue, until tonight I read the KB articlesurrounding this patch in detail. Specifically, there’s a section called Known Issues where it says the following:

 

“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 machines security context”

Um….that’s big. What it’s saying is that per-user GP processing has fundamentally changed. It goes on to further say:

“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.”

Indeed, many people found that by adding back the Authenticated Users Access Control Entry (ACE) to the GPO’s delegation with Read access (NOTE: I AM SAYING READ ACCESS–THIS IS DIFFERENT  THAN READ AND “APPLY GROUP POLICY”, which will have the affect of nullifying any security group filtering you are using on the GPO) per-user GP processing will go back to working. The above referenced article says that you can add either Authenticated Users or Domain Computers with Read access on the GPO to solve this, because the per-user settings are running in the computer’s security context, so adding Domain Computers should give the computer the access it needs to continue processing those per-user settings.

Mitigation

OK, again, this is a BIGGGGG change, and I’m sure a lot of folks got broken by this. What I’ve done is created a quick PowerShell script for those who have a lot of GPOs in your environment and don’t want to manually make this change. What the script does is get a list of all of your GPOs in the current domain. It then iterates through them, checks to see if the Authenticated Users or Domain Computers groups are found in the GPO’s delegation. If not found, then the script adds the Read (only) permission to the GPO for Authenticated Users. You might decide you’d rather use Domain Computers, because some people have purposefully prevented Authenticated Users from reading their GPOs to prevent unwanted security posture discovery. You can easily modify the script to add Domain Computers instead of Authenticated Users by modifying line 9 of the script. Note that this script needs the Group Policy PowerShell module that is part of GPMC to be installed to function:

 

Download the Script File

 

PLEASE NOTE: THIS SCRIPT CHANGES PERMISSIONS ON YOUR GPOs. Test first in a non-production environment before running it against your live GPOs. It’s provided for you as-is, with no warranty!

 

Commentaar