Who broke my user GPOs?

[Brink]

Hi folks. From Orlando, Florida, Sean Greenbaum here with some news about a recent set of security patches released on June 14, 2016. If you’re reading this, chances are you are having group policy issues, or you heard this patch will cause you to have issues and you want to get ahead of it. So, without further ado.

What did I miss.

We released new security patches for all currently supported Operating Systems. Among those patches was this one: MS 16-072, which is also referenced as KB 3163622. OS Specific articles are released as 3159398, 3163017, 3163018, and 3163016.

KB 3159398 – Vista, 2008, 7, 2008 R2, 2012, 8.1, 2012 R2
KB 3163017 – Windows 10 TH1
KB 3163018 – Windows 10 TH2 and Server 2016 TP4
KB 3163016 – Server 2016 TP5

After applying the appropriate patch to your systems, User group policies are retrieved from SYSVOL differently than before. Prior to the update, domain joined computers used the user’s security context to make the connection and retrieve the policies. After the update is applied, domain joined computers will now retrieve all policies using the computer security context. The users that get the policy is still controlled by the policy scope just like before. The only change is the computer is getting the policy for the user.

For group policies with the default permissions, this isn’t an issue. By default, “Authenticated Users” has Read permissions to all group policies when they are created.

But, why did you do that?

Well, it’s complicated. Insiders tell me (and by insiders I mean the very first link I supplied you with above) that this was done to prevent a possible Man-in-the-middle (MiTM) attack between the PC and the DC. Using the computer account helps mitigate this by enforcing the use of Kerberos.

Learn something new

Before I go too far, let’s make something clear. There is a difference between Group Policy scope and Group Policy permissions. The Scope is who can apply the GPO. The permissions control who can read, write, delete, or modify the permissions of a policy. These permissions are stored on the delegation tab of each policy. We are going to be focusing the rest of this article on the Delegation tab.

Let’s also make something else clear. For a policy that is scoped to Computer accounts, there is no functional change. In order for the computer to apply the policy, it needs read and apply permissions to the policy. By scoping a policy to apply to a certain group, that group automatically gets Read permissions. This functionality has not changed at all.

But for User policies, the ones that are scoped to a subset of your users, that’s where the issue is. This is a fairly common configuration for user policies, so there is great potential for problems here.

A default GPO looks like this.

As long as “Authenticated Users” has Read permissions, group policy application will continue to work after applying MS16-072 / KB 3163622. That’s because Computers are “Authenticated Users” too. Therefore, the computer that this user is logging on to has read permissions to this GPO already through “Authenticated Users”.

GPOs can be scoped to apply to a smaller audience than “Authenticated Users”. What happens if I scope this GPO down to an AD security group (or individual users) instead of “Authenticated Users”?

On the Scope tab, you typically remove “Authenticated Users” and add your own users or security group(s), populate it with users and go about your day. Like so:

Back on the delegation tab you see this:

As you can see, your user account has read permissions to the GPO through the AD Group “User Group 1”, but “Authenticated Users” is gone. That’s no longer enough permission after installing MS16-072. Since the computer account is now used to retrieve the policy, it needs Read access to the policy in order to retrieve it from SYSVOL and hand it off to the user for processing. As you can see, your computer account isn’t a member of any of these default groups.

Since I want this policy to apply to this user regardless of what computer they log on to, I need to add either “Authenticated Users” or “Domain Computers” to be able to Read this GPO as well. Here I’ve added “Domain Computers”.

If you look closely here, you’ll see “Domain Computers” has Read permissions. “User Group 1” has “Read (from Security Filtering)” permissions. That’s how you can tell User Group 1 is security filtered to apply this GPO from the Scope tab, and Domain Computers just has Read and not Apply permissions.

You: Well great. Now I have to go through each GPO and add the computers to have Read permissions. Right?
Me: Yep.

You: Well, I have hundreds of group policies. That’s going to take forever. Is there a way I can do this quickly?
Me: Yes there is. PowerShell to the rescue.

…but first….

Decisions, Decisions

Here you have some options on how to proceed, and you have to make a decision on which strategy is the best for you. The official guidance from Microsoft is to ensure the computer accounts have “Read” access to the user policies you wish to have applied. This can be done several different ways.

Strategy 1: Add “Authenticated Users” to each of your user policies. This is certainly the easiest method as it ensures that all authenticated computers and user accounts can read the settings in the policies. This works regardless of what domain, forest or trust they come from, as long as the local domain is able to authenticate it. However, it does grant all user accounts the ability to read the policy (Note: Not apply the policy, just read the settings contained in it.)

Strategy 2: Add “Domain Computers” to each of your user policies. Using “Domain Computers” will grant all member computer object the ability to read the GPOs, without also including user accounts. It too isn’t without its gotchas though:

Note: By default, when a computer is joined to the domain, it is automatically added to the “Domain Computers” AD security group. If you manually manage the membership of this group, then it’s possible “Domain Computers” won’t have a complete membership of all of your computer accounts.

Note: Remember that “Domain Computers” is exactly that – the computers in your current domain. If you have multiple domains, or trusts, and if you cross link any GPOs across those boundaries, you will also need to add the other domains “Domain Computers” group to the policies as well.​

Strategy 3: Use your own custom groups. If you would like to granulize exactly which computers the user policy is able to be applied to, you will want to have your own custom AD security groups populated with those computer accounts.

As my lab is a single forest, single domain with no trusts, I’ve chosen to use “Domain Computers” for the rest of this article. Any PowerShell code or step by step instructions are the same whether you use “Authenticated Users”, “Domain Computers” or your own custom groups. Simply replace any instance where I use “Domain Computers” with the group you are intending to use.

Ok, I’m ready. Let’s fix it.

Great. Now that you’ve chosen a strategy that works for you, let’s begin.

Option 1: The “Just fix it already” option

Very simple and straight forward. Get a list of all the GPOs in the domain, and add “Domain Computers” to have read permissions. This script doesn’t distinguish between user policies, computer policies, scoped, not scoped.

$gpos = get-gpo -all
foreach ($gpo in $gpos)
{
 Set-GPPermissions -Name $gpo.DisplayName -PermissionLevel GpoRead -TargetName “Domain Computers” -TargetType Group
}

That’s it! You’ve just added the “Domain Computers” group for the current domain to have GPORead permissions on all your GPOs currently in the domain. If you have other domains and are cross linking GPOs to the other domains, don’t forget to add the “Domain Computers” groups for those domains as well.

Option 2: I want to be more detailed than that. Can I get a list of all the GPOs that need my attention?

Of course. In fact, our product group published this very fine script here. This script searches for GPOs that are missing the “Authenticated Users” permissions, and prompts you to automatically fix them. Looking at the code, you could easily adjust this to use “Domain Computers” or whatever group you find appropriate in your environment.

Option 3: I prefer the personal touch with my policies

That’s the same way I prefer my fresh home baked cookies. No machinery or automation here. Start from the Delegation tab of the policy. Click Add, find the group, and make sure the permissions are Read. Easy. Now do that for each user policy.

Option 4: AGPM! Wait, I have AGPM!

AGPM (Advanced Group Policy Management)

If you already use AGPM to manage your policies, you can use the Production Delegation tab in AGPM to update the security on any GPOs you deploy going forward. See the AGPM section below for details.

Ok I fixed it, so I’m done right?

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 3[SUP]rd[/SUP] 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.

Do you use Deny:Read permissions on some of your GPOs? Read this.

When you grant the computer the ability to Read the GPOs, if your user account is in a group that grants apply rights, and in a group that denies read rights, previous to MS16-072 the user would not get the policy. Since the Read is now done by the computer context, there is a possibility that the user will now get the GPO when that is not your intention.

To fix this, update the permissions on any GPO where you are doing Deny:Read to also include Deny:Apply.

Using AGPM? Look here for some important information

Once you’ve installed the patches for MS16-072, if you are using AGPM you’ll want to make some changes here as well.

First, very important, make sure you reimport your GPOs into the AGPM database. Trust me, do this. We’ve already received reports from customers that did NOT do this step, and it caused some serious problems when they went to deploy later. This makes sure we have the latest copy of the production GPOs. Do it. Right now. I’ll wait.

All reimported? Good.

Now that you’ve reimported your GPOs in AGPM, lets configure AGPM so that it knows of the new permissions and deploys the correct security settings going forward.

From the AGPM module, select the Production Delegation tab. We need to grant “Domain Computers” Read permissions.

Only grant Read permissions.

Confirm the settings.

Now that the delegation settings are correct, redeploy your GPOs. This will make sure the permissions apply. Select all the GPOs you need, right click and Deploy.

Boom. Victory! We see that “Domain Computers” is here, “User Group 1” is the group that is scoped to apply these settings, and “User Group 2” is the group we specifically Denied Read and Apply permissions earlier.

One more thing

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.

More Info

Our Directory Services team has also published information about this update on their blog. If you have any questions, be sure to check there too.

Until next time,

Sean Greenbaum

Premier Field Engineer, Secure Infrastructure

Source: Who broke my user GPOs? | Ask Premier Field Engineering (PFE) Platforms

 

[Anak]

This is all well and good, but how does this help a user that doesn't have a GPO Editor?

From your last months [June] patch Tuesday notice:

Had to uninstall and hide kb/3159398 made my security permissions go wonky; Until I can learn how to give access to Authenticated Users in GPO without a GPO editor since I'm Home Premium, it will stay hidden.

I would rather not have to go into each and every program, folder, and file to do it manually.

Related:
https://Beware - Known Issues with update kb3159398 | community.spiceworks.com

And, I was never offered any of the other updates for win7; KB 3163622, KB 3163016

Only KB 3159398, if I reinstall 9398 do I use strategy1? I looked into using the powershell script linked at Option2 but I don't have RSAT installed, I did find one page for the RSAT download but its from win7's beta days January 10, 2009, but then I'm not even sure that's the way to go or do I wait until the usual cry from the win7 users wilderness creates an uproar and microsoft decides to change 9398; Decisions, decisions......

Do you have any suggestions Shawn?

 

[ThrashZone]

That's one heck of a quote

 

[Anak]

Mine or Shawn's?

 

[ThrashZone]

lol only one is a mile long