News

Microsoft Provides More Insight Into Its June Patch Problems

• By Kurt Mackie
• 07/06/2016

Issues concerning Microsoft's June security patch and its potential to break Group Policy Object (GPO) settings were discussed yet again this week by Microsoft in a blog post.

The issue concerns June security patch MS16-072 (Knowledge Base article 3163622). It's a patch for various Windows versions that wards off potential man-in-the-middle attack scenarios. However, the patch also changes how security is applied to GPO policies. With MS16-072 installed, GPOs will now follow the computer's security context with regard to policies. Previously, before MS16-072, policies were applied based on the user's context by default.

Many IT pros were caught unaware of the consequences of MS16-072. They reported issues, such as losing network mappings for printers. Eight days later, Microsoft offered a more thorough explanation than its Knowledge Base article had offered about what occurs, and what steps to take.

It seems, though, that the explanations weren't wholly sufficient. On Tuesday, Sean Greenbaum, a premier field engineer for secure infrastructure at Microsoft, offered more details in this blog post.

In particular, Greenbaum explained what will happen to organizations that have used "security filtering" when MS16-072 is applied. This aspect hadn't been explained very well previously.

In essence, the patch makes the computer Authenticated Users group disappear when security filtering exists in a computing environment. IT pros then face the task of adding Authenticated Users read permissions delegations back again. Greenbaum offered three strategies:

• Add "Authenticated Users" to each of your user policies
• Add "Domain Computers" to each of your user policies
• Use your own custom groups

He posted a PowerShell script to automate strategy No. 1, although doing so "does grant all user accounts the ability to read the policy." Another PowerShell script is provided in Greenbaum's blog post to automate strategy No. 2. The third strategy is a hands-on manual process to restore read permissions to particular groups.

It's also possible to use Microsoft's Advanced Group Policy Management (AGPM) solution to update security on GPOs. The AGPM tool extends the capabilities of the Group Policy Management Console and is offered at extra cost for Software Assurance participants as part the Microsoft Desktop Optimization Pack. If using AGPM, organizations should "reimport your GPOs into the AGPM database," Greenbaum warned. Otherwise, organizations could face "serious problems" later, he added.

However, performing these kinds of changes is just a temporary measure. IT pros will have to remember these steps whenever new GPOs get created. Here's how Greenbaum expressed it:

Our group policy tools GPMC and AGPM will continue to create GPOs using the default permissions I showed at the beginning of this article. As you create new user GPOs, and you scope them to specific user groups, you'll need to continue to remember to add the appropriate groups to those GPOs before it can be processed.

Saunders seemed to support strategy No. 2. He also published a script in this blog post that promises that "new GPOs are created with Domain Computers having Read permissions by default," noting that "Microsoft didn't release an official script or method to do this."

Maybe Microsoft one day will release such a script, but Greenbaum didn't provide it. Nor did he say any additional fix was coming. It looks like IT pros using GPOs will have to roll up their sleeves this time around, or go unpatched.