View Blog

So on Patch Tuesday, Microsoft released a patch to prevent a theoretical “man in the middle attack” when  GPOs are downloaded from your servers to your endpoints.

Okay.. Fine. Sounds good. In fact, here’s the tech note on the problem. Fix for GP elevation https://technet.microsoft.com/library/security/ms16-072

But when that patch is applied, there is a “double increase” in security, one with an unintended consequence.

That consequence is that SOME GPOs will no longer apply when you expected them to. You could call this a “breaking change”, but.. stick with me, I think Microsoft wanted this behavior updated. And it’s not TERRIBLE; it’s simply somewhat inconvenient to fix and make right again.

How to expose the new behavior

Warning: I have not done the full end to end testing on this. This is simply my understanding of the issue and what’s going on here. With that disclaimer, the problem will occur for you when:

1. The patch MS16-072 is applied to your endpoint computers (the ones which PROCESSS GPOs).

2. Admin has REMOVED Authenticated Users in Security Filter.

Here’s a GPO in “normal” state: http://screencast.com/t/svZODLEpR

3. Admin has specified specific USERS (directly or via Group membership) in Security filter.

Here’s the same GPO in “revised” state, specifying a security group which contains only users: http://screencast.com/t/NyBdnAYZR

 Ergo: The COMPUTER ACCOUNT itself has no READ access to the GPO (nor should it need it.)

 

The ORIGINAL behavior is:

ALL user-side GPOs should be processed when a USER has READ/AGP rights, even if the computer itself has no read / AGP rights access to a particular GPO.

 

The UPDATED (unexpected) result is:

User-side GPOs are not processed (if the computer cannot perform the READ operation.)

 

And why is this occurring? Well, here’s the answer from the KB: “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 ”

So the big change is that in order to process USER side GPOs, the COMPUTER needs READ access. And when you remove AUTHENTICATED USERS from the GPO, the COMPUTER cannot perform the READ it needs.. and hence, user-side GPOs are not processed as expected.

What to do next: 

• If you wanted to MANUALLY update any existing GPO to then recover from this breaking change, there are two possible manual ways:
  • Manual way #1: Simply add Domain Computers to the Security Filter as seen here: http://screencast.com/t/ziB193hs
  • Manual way #2: Add Domain Computers “indirectly”, by using the Delegation | Advanced and specifying READ but NOT “Apply Group Policy” as seen here http://screencast.com/t/xfbmuCy0i
  • TIP: READ THIS BLOG ENTRY ALL THE WAY THRU TO DECIDE WHICH IS BEST FOR YOU.
• If you wanted to AUTOMATICALLY buzz thru ALL your GPOs and find the ones with problems. Here’s a quick powershell script:  https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/
•  If you wanted to AUTOMATICALLY fix all your GPOs, there are two ways to do it:
  • One-liner Powershell script as follows (thanks to  Rudi Vanden Dries in the comments of this blog for the tip):

    Get-GPO -All | Set-GPPermissions -TargetType Group -TargetName "Domain computers" -PermissionLevel GpoRead

• • Fellow Enterprise Mobility MVP Darren Mar-Elia has a somewhat more sophisticated script which will pre-verify you NEED to change before making it. You can find that blog entry here (Thanks Darren!): https://sdmsoftware.com/group-policy-blog/bugs/new-group-policy-patch-ms16-072-breaks-gp-processing-behavior/

Why ?

You might be asking WHY Microsoft made the change.

Update 6-22-16: Well, the Official Microsoft Response to the patch is here: https://blogs.technet.microsoft.com/askds/2016/06/22/deploying-group-policy-security-update-ms16-072-kb3163622/ 

Short story: It’s a prevent of a theoretical attack, and ensures that the computer does all the work with Kerberos.

Update 6-17-16 to the question “Is it better to just add ‘Read Rights’ to Domain Computers directly to the delegation tab?”

So after this post went live, I got the question (in several ways) which boiled down to

Jeremy, should I add DOMAIN COMPUTERS to the SECURITY FILTERING section? Or should I just add DOMAIN COMPUTERS to the DELEGATION TAB?

So there are advantages and disadvantages to each approach.

Method 1: Adding DOMAIN COMPUTERS to Security Filtering section advantage and disadvantage

When you add Domain Computers directly to the Security Filtering tab, you can actually *SEE* that you did that. Again, here’s the screenshot from earlier if you take my advice: http://screencast.com/t/ziB193hs

In a PERFECT world, if you followed best practices by NOT mixing USER and COMPUTER side stuff, there would be no particular consequence for adding DOMAIN COMPUTERS to the Security Filtering tab. Said another way, if NO GPOs had COMPUTER side stuff, then the computer would have nothing in particular to apply when you made this change.

Method 2: Adding Domain Computers “indirectly”, by using the Delegation tab advantage and disadvantage

Method two is that you use the Delegation tab and specify READ but NOT “Apply Group Policy” as seen here http://screencast.com/t/xfbmuCy0i the end result in the security filtering tab is this (when you press OK) is simply this: http://screencast.com/t/svZODLEpR

When you do this, you don’t get CLARITY that the rights are correct. You have no idea that the Group Policy will actually process.. unless you peek (again) at the Delegation tab.

But the upside here is that if you have “mixed GPOs” with COMPUTER side stuff into the same GPO, you won’t start to process “dormant items” that didn’t apply yesterday and will (uh-oh) magically apply today.

So I guess, ultimately, this is my vote.. the indirect way… with the downside that I have to verify the GPO is “ready to rock” by clicking the Delegation tab and verifying that Domain Computers is in there. (boo.)

Note also that Method 2 should be used for those still on SBS 2008 or SBS 2011; as SBS has a special process which cleans out some GPOs back to their original baseline (if you do Method 1.)

Update 6-22-16 to the question: “Should I add Authenticated Users or Domain Computers” when I choose a method?

So I got this question a lot, and here’s my vote: Use Domain Computers and not Authenticated Users. Yes, either will work, but I think Domain Computers is slightly better to add.

Authenticated Users is simply more rights than necessary. (But just a little bit.)

Domain Computers are.. well, domain computers. And Authenticated Users are… well, Authenticated Users *AND* Domain Computers.
(As I like to say… “Computers are People Too”).

So, it’s the minimum rights required are Domain Computers.. because THEY (the computers) are now in charge of the whole “Lookup and download” operation, Where before.. it was a two-part affair.

Making the change permanent in Active Directory for future / newly born GPOs

So, okay. If we’re going to go with “Method 2” .. maybe you want to make this change permanent for all future / newly born GPOs. Which, I think is a good idea. Here are the exact step-by-steps you need to do this. (Tip: If you don’t trust my advice, pre-check this out: https://support.microsoft.com/en-us/kb/321476). The steps which I verified:

1. Open ADSI Edit
2. Connect to the schema http://screencast.com/t/PnQ5if2pVpLO
3. Find the the object “CN = Group-Policy-Container” http://screencast.com/t/BdaJJ3Oimyx 
4. Find defaultSecurityDescriptor and add this at the end:  (A;CI;LCRPLORC;;;DC)

TIP: The “DC” in the string is “Domain Computers” not the “Domain Controllers”.  In case you care, Domain Controllers “short name” is “ED” which means “Enterprise Domain Controllers”.

• BEFORE screenshot: http://screencast.com/t/AZ4NU0oGKO8
• AFTER screenshot: http://screencast.com/t/6XMYzBtc3qBX

5. Close ADSI edit. Then also close the GPMC (if opened.) And re-open the GPMC.

Check to see if it worked. If it did, all new GPOs you create will have the following stamp on them: http://screencast.com/t/YUJ0k9Fw4q   

6. If it did not work, then, ensure that all DCs get the update (aka synchronize all DCS) then … reboot all your DCs. You can reboot them one by one. -or- Another option is to update the Schema Cache:

• Article 1: https://technet.microsoft.com/en-us/library/cc961572.aspx
• Article 2 with Step by Steps: https://www.safaribooksonline.com/library/view/active-directory-cookbook/0596004648/ch10s23.html 

Again: when this is over, all new GPOs you create will have the following stamp on them: http://screencast.com/t/YUJ0k9Fw4q  .

What about Microsoft AGPM (and tools like it, like NetIQ GPA , etc.? )

So another Microsoft article, posted from a Microsoft PFE is found here: https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/ which re-iterates some of my points and step-by-steps. That being said, I didn’t talk about AGPM here, and he does a pretty good job explaining what to do in AGPM land. In short, the steps are:

1. Do all the steps to the LIVE GPOs like we already talked about.
2. Mass Import from Production AFTER that.. or else AGPM doesn’t know you did anything in the real world.
3. Set AGPM’s permissions such that when a GPO is DEPLOYED it has the right stamp.

Again, the blog entry does a reasonable job of explaining that, so I’m not going to re-do the step-by-steps here.

Brief commercial message:

• Hope this information helps you out, and you’ll consider getting serious GP training from me at www.GPanswers.com/training … Live and Online training !
• And consider PolicyPak to manage the heck out of all browsers and apps: IE, Firefox, Chrome.. plus Java, Flash, and hundreds more. Thru Group Policy, SCCM or thru the cloud.

Your pal, Jeremy Moskowitz, Enterprise Mobility MVP.

Thanks to my Fellow Enterprise Mobility MVPs for technical review of this article.