Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Microsoft posts more details for botched permissions in MS16-072

Woody Leonhard | July 7, 2016
The patch that was infamously intended to fix Group Policy but broke it has been thoroughly rendered

That warning should've appeared before the patch was released, not a month later.

Yesterday, Brandon Wilson, posting on the Ask Premier Field Engineering Platforms blog, gave a thorough report on the condition of the patch. He even included a modified PowerShell script to fix the problem. (Microsoft first posted a version of the PowerShell script on June 16.)

What Wilson didn't post is an apology or a promise to fix the problem. Instead, he says quite clearly that the fixes he outlines will only work ...

Temporarily. 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.

If you are using a 3rd party tool to create and manage your GPOs, you'll want to reach out to that vendor to see how their product is affected and if any change is needed to your policy creation and deploy process.

Remember: If you didn't use "Authenticated Users" and you add additional domains to your forest, and if you are cross-linking GPOs between domains in your forest (the GPO exists in Domain1 and is linked to OUs in Domain2), be sure to remember you will need to grant the new domains "Domain Computers" or your custom group to the policy before it will have access in the new domain.

There's also an acknowledgment of yet another bug, this one in MS16-075/KB 3161561:

We also released MS16-075/KB 3161561 in June 2016 to patch some SMB items. SYSVOL and Netlogon use SMB. There have been reports of users getting Access Denied when trying to access \\domain.fqdn\sysvol or \\domain\sysvol.

If you are experiencing this error, the current workaround is to set the SmbServerNameHardeningLevel registry value to 0 on the DCs. It is not needed on the other servers. If you experience this issue on other DFS servers, see the KB for the updated workaround info for those servers. Specifics are detailed in the KB 3161561 article.

I tend to think of the whole escapade as a graduate course in admin sadism. At least it'll contribute to full employment in the admin ranks.

Source: Infoworld


Previous Page  1  2 

Sign up for CIO Asia eNewsletters.