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

Microsoft posts more details for botched permissions in MS16-072

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


1  2  Next Page 

Sign up for CIO Asia eNewsletters.