Update on KB3163622 That Breaks Group Policy: It’s Not Me, It’s You

There's now a resolution available for those affected by Patch Tuesday's KB3163622.

Rod Trent

June 16, 2016

2 Min Read
Update on KB3163622 That Breaks Group Policy: It’s Not Me, It’s You

Yesterday, I raised a red flag about a security patch from Microsoft this week that is breaking Group Policy for a number of customers. The issue, as it turns out, is due to how customers have implemented Group Policy permissions.

The KB article (KB3163622) has now been updated to show both the known issues and the resolution. Here’s the important message:

What happened: 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.

Why it happened: 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.

How to fix it: 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.

Additionally, if you need to query a large number of permissions, there’s now a PowerShell script available that… the output should be the basis for further investigation, i.e. it lists GPOs that may need the ‘Authenticated Users’ read permission or ‘Domain Computers’ read permission adding.

PowerShell script: MS16-072 – Known Issue – Use PowerShell to Check GPOs

So, while it seems Microsoft is sort of blaming customers for their implementations of Group Policy security, there's a bigger factor here I hope doesn't get lost in the shuffle. We can thank Microsoft for delivering the recommended resolutions, but those didn't deliver until AFTER the patch caused customer pain. Isn't this something that should've been identified during testing?

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like