More Microsoft Guidance on MS16-072

So Microsoft PFE team have just released a blog called “Who broke my user GPO?” which is rather ironically title as the answer was “Microsoft did”. But anyhow, this new post has a detail description of the problem and what can be done to fix the issues and what to do if you have AGPM deployed in your environment..

It also points out that you need to added either “Authenticated Users” or “Domain Computers” Read permission to fix the problem. But if you have a multiple domain environment you are going to need to add “Domain Computers” multiple times for the GPO’s to work cross forest.

See the full article here

Official Microsoft Guidance for MS16-072 Breaking Security Patch

Microsft has just published a post about the MS16-072 hotfix that was release this month. Needless to say there has been a lot of organisation caught off guard by this change wanting to know how to fix the problem. However what is also more confusing is there are actaully two different ways to fix this problem. You can either add back the “Authenticated Users” group with “Read” access or you can add the “Domain Computers” group with read access.

There has also been a lot of debate in the Group Policy community about what is the “best” way to fix this problem. Should you add “Authenticated Users” or “Domain Computers”? Personally i think adding “Authenticated Users” read permission back is the way to do it as this restores the original permission that was removed in the first place. It also means the permission applied to you GPO’s will be consistent which is always highly desirable attribute for supporting any envrionmnet. However, you might have some settings in your GPO that you want to obfuscate from the users. If this is the case then adding “Domain Comptuers” read access is also totally valid. Doing for security filters user Group Policy Objects will mean that that normal users will not be able to read the settings. But, be absolutley clear this will only obfuscates the GPO settings, as a local admin could still conceviable run the as the local machine system account and read the settings. Yes it is a way to hide your organisations settings from a bag guy, but it also might make troubleshooting GPO polices harder as non-domain admins will no longer be able to see all the GPO’s.

Ultimatly it is your decision as to how you want to fix the problem. Either add “Autenticated Users” or “Domain Computers” but either way, make sure you review all your security filtered Group Policy Objects to make sure the permission are added to the GPO so they work.


How to fix broken GPO because of MS16-072

So as many of you may know, yesterday Microsoft released a security hotfix that changed the behavior of Group Policy. Put simply if you have a security group filtered User Group Policy Object and you also removed the “Authenticated Users” group from the policy it will no longer apply after you install MS16-072.

In light of this Ian Farr from Microsoft has released a PowerShell script that identifies all the Group Policy Objects that have “Authenticated Users” removed. It is important to note that not all of the GPO’s are necessarily affected, only the ones that are applied to AD user objects.


In addition to this Microsoft also released a KB outlining the issues and what can be done manually to fix the problem.


Finally, fellow Group Policy MVP Darren Mar-Elia has released a PowerShell script of his own that adds back the “Authenticated Users” read permission to the GPO’s that are missing the permission.


The key take away from this is that it certainly appears that this is going to be a permanent change with how security group filtered GPO’s apply. So going forward be aware that it more than just a Bad Idea to do remove “Authenticated Users”, it could down right break the GPO.


Updated – MS16-072 may break your User Group Policies “by-design”

This is a PSA for all Group Policy administrator about MS16-072 that was release yesterday. This patch fixed a man in the middle attack using Group Policy Update however it appears that it has also changed the behavior that Group Policy is applied. If you have a security filtered group policy that are applied to users AND you have also removed “Authenticated Users” group from the GPO then this GPO will no longer apply to the user.

To workaround this problem you can either remove the patch or add “read” permissions to the “Authenticated Users” group back to the GPO. This allows the computer object to read the policy setting and the policy will then work again. As a reminder I stressed back in 2010 that you should never just remove “Authenticated Users” from your GPO’s and that you should instead simply remove the “Apply” permission for the group. See

No word yet if this is deliberate change in behavior to fix the man in the middle attack or if this is something that will be fixed.

Update: Thanks to Darren Mar-Elia he had discovered that this was actually a documented change in behavior

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.

Forum post