As part of last month's Patch Tuesday, Microsoft released a patch called MS16-072, a "security update for group policy." The fix appeared in security patch KB 3163622, which is linked to numerous patches for Vista, Server 2008, Win7, Server 2008 R2, Win 8.1, RT 8.1, Server 2012 and Server 2012 R2. It was also part of Windows 10 cumulative update KB 3163018, for Win10 version 1511 build 10586.420 (in other words, Win10.1.13).
The patch caused problems, though -- not with client-side computers, but in the way admins have set permissions for Group Policies -- on the server side of the fence.
Over on AskWoody.com, reader ch100 puts the onus on admins to clean things up:
Group Policies for those administrators who experience problems were not set according to the best practices in the first place.
The issue is that the security context for User Group Policy has changed from user (which can be an unprivileged/non-admin account) to computer to enhance the security overall. A computer is a user in Active Directory, i.e has its own user account and a randomly generated password which by default changes every 30 days. Being a user, the computer account, commonly seen in the permissions as followed by the dollar $ sign, is a member of Authenticated Users which needs to be able to at least read the policy, not necessary to apply it, as this will still happen in the user context as normal.
It is not a faulty patch, it is enforcing security as I believe it was always meant to be. So in that sense it resolves an issue which was never addressed until now.
The recommendation was always that Authenticated Users should have Read access at minimum, but this can be worked around by adding the exact computer accounts and Domain Controllers instead which makes the configuration complex, required sometimes for compliance reasons.
I don't think Microsoft has any reason to reissue the patch as it is not a faulty patch, unless it is for PR reasons. Technically Microsoft is not at fault.
The only thing that Microsoft could and should have done better was to post the information in the original revision of the article BEFORE administrators installing the update and experiencing problems.
An admin identified as Doug countered:
If it isn't faulty, then at the end of the patch, Microsoft should add a subroutine that scans for the GPO issue within Active Directory, and resolves it automatically by correcting the necessary permissions. I would call that expected behavior.
In general, there's been a lot of back and forth, and the admins I know aren't at all happy with the results. I think it's fair to say that Microsoft either failed to test the patch on common configurations -- whether they were set up "by the book" or not -- or if they did test it in normal conditions, they didn't bother to warn admins about the potential trouble.
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.
t/h ch100 and David on AskWoody.com, Mary Jo Foley at ZDNet, and Rod Trent at WindowsITPro