This morning I woke up to an email from a fellow Group Policy MVP–Martin Binder–warning that folks were seeing GP Processing issues after the recent slew of Patch Tuesday updates were applied. Indeed, I had noted late on Tuesday via Twitter that there was a fix to GP in this latest round of patches, that prevents a privilege elevation vulnerability in GP processing. Great! Well, not so great. It turned out that the fix was a bit problematic for folks who had set per-user security group filtering in their GPOs, as shown in the figure below. GPOs set up this way were no longer being processed after the patch was applied to client systems.
A GPO with no Authenticated Users in Security Filtering
Specifically, if you’d set security group filtering for GPOs that contain per-user settings, and you’d removed Authenticated Users completely from the GPO’s delegation, then GPO processing for per-user settings would fail after applying MS16-072. As the day went on, I mostly ignored this issue, until tonight I read the KB article surrounding this patch in detail. Specifically, there’s a section called Known Issues where it says the following:
“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”
Um….that’s big. What it’s saying is that per-user GP processing has fundamentally changed. It goes on to further say:
“This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.”
Indeed, many people found that by adding back the Authenticated Users Access Control Entry (ACE) to the GPO’s delegation with Read access (NOTE: I AM SAYING READ ACCESS–THIS IS DIFFERENT THAN READ AND “APPLY GROUP POLICY”, which will have the affect of nullifying any security group filtering you are using on the GPO) per-user GP processing will go back to working. The above referenced article says that you can add either Authenticated Users or Domain Computers with Read access on the GPO to solve this, because the per-user settings are running in the computer’s security context, so adding Domain Computers should give the computer the access it needs to continue processing those per-user settings.
Mitigation
OK, again, this is a BIGGGGG change, and I’m sure a lot of folks got broken by this. What I’ve done is created a quick PowerShell script for those who have a lot of GPOs in your environment and don’t want to manually make this change. What the script does is get a list of all of your GPOs in the current domain. It then iterates through them, checks to see if the Authenticated Users or Domain Computers groups are found in the GPO’s delegation. If not found, then the script adds the Read (only) permission to the GPO for Authenticated Users. You might decide you’d rather use Domain Computers, because some people have purposefully prevented Authenticated Users from reading their GPOs to prevent unwanted security posture discovery. You can easily modify the script to add Domain Computers instead of Authenticated Users by modifying line 9 of the script. Note that this script needs the Group Policy PowerShell module that is part of GPMC to be installed to function:
GPO Permission script for MS16-072
PLEASE NOTE: THIS SCRIPT CHANGES PERMISSIONS ON YOUR GPOs. Test first in a non-production environment before running it against your live GPOs. It’s provided for you as-is, with no warranty!
June 16 Edit: I made a change to the script, to have it check for GPOs that contain user settings, since we’re only interested in doing this fix for GPOs with per-user settings. Also note that Microsoft has just released an assessment-only script here.
June 17 Edit: I added a blog post to show how you can modify the default permissions that get stamped on a newly created GPO, to include Domain Computers with Read access
June 21 Edit: Another quick update to share a great blog post that fellow techie Jeremy Saunders did to enhance the script I’ve provided. Check it out!
Next Steps
I’ve been asked if this is a bug that Microsoft will fix. If you read the article I mention above, it sure doesn’t seem like they see it as a bug, but rather a change in behavior in the interests of security. I agree that making GP secure is critical to ensuring it can do it’s job of, well, securing your Windows systems. I wish they had given a little bit more notice on this so it didn’t break people’s GP environments, but, hey, at least NOW we know :-).
If you have any feedback or questions on the script, feel free to email us at info@sdmsoftware.com
Darren
Changed it a little for to make it work in Server 2008(r2) :
$allGPOs = get-gpo -all
foreach ($gpo in $allGPOs)
{
# first read the GPO permissions to find out if Authn Users and Domain Computers is missing
$perm1 = Get-GPPermissions -Guid $gpo.id -TargetName “Authenticated Users” -TargetType group -ErrorAction SilentlyContinue
$perm2 = Get-GPPermissions -Guid $gpo.id -TargetName “Domain Computers” -TargetType group -ErrorAction SilentlyContinue
if ($perm1 -eq $null -and $perm2 -eq $null) # if no authn users or domain computers is found, then add Authn Users read perm
{
Set-GPPermissions -Guid $gpo.Id -PermissionLevel GpoRead -TargetName “Authenticated Users” -TargetType Group
Write-Host $gpo.DisplayName “has been modified to grant Authenticated Users read access”
}
}
Ah yes, thanks Erik. Forgot about the different versions of Get-GPPermission(s)!
Hello,
the Script (Win08r2) from Erik not run on a Windows 2008r2 Server.
Can you help me. I need the correct Script.
Thanks
heh – Sperm1 and Sperm1
Thank you for your script. Reviewed and tested here, allworking well. Nice informative blog post too.
I found over 30 GPOs that needed changes, which was a piece of cake with your solution. 🙂
If folks need to run this on a non-English system, then you can replace the line that tests for “Domain Computers”, with this:
$perm2 = Get-GPPermission -Guid $gpo.id -TargetName (Get-ADGroup “$((Get-ADDomain).DomainSID)-515”).Name -TargetType group -ErrorAction SilentlyContinue
Here the correkt Script for non-english (i. e. german) Server 2008 r2 (“get GPPermissions” in Line6).
Start PowerShell with Option “Systemmodule importieren”:
$allGPOs = get-gpo -all
foreach ($gpo in $allGPOs)
{
# first read the GPO permissions to find out if Authn Users and Domain Computers is missing
$perm1 = Get-GPPermissions -Guid $gpo.id -TargetName “Authenticated Users” -TargetType group -ErrorAction SilentlyContinue
$perm2 = Get-GPPermissions -Guid $gpo.id -TargetName (Get-ADGroup “$((Get-ADDomain).DomainSID)-515”).Name -TargetType group -ErrorAction SilentlyContinue
if ($perm1 -eq $null -and $perm2 -eq $null) # if no authn users or domain computers is found, then add Authn Users read perm
{
Set-GPPermissions -Guid $gpo.Id -PermissionLevel GpoRead -TargetName “Authenticated Users” -TargetType Group
Write-Host $gpo.DisplayName “has been modified to grant Authenticated Users read access”
}
}
Many thanks! Perfect for a quick resolution.
Worked successfully on 2008 (non R2) domain.
Many thanks! It worked well for me on 2008R2 after adding the S to Get-GPPermission and starting the PowerShell session with import-module grouppolicy.
Thanks for the article. We are using Security Filtering to apply the policy only to a group of users. Would it be better to add the Domain Computers with read only to the Security Filtering to avoid having the policy applied to Authenticated Users?
Ron-
In either case, you have to remember that there is a difference between the Read and Apply Group Policy permissions, which is what groups gets when you add them from the security filtering dialog, and just the Read permission, which is what my script does. With just Read permission, you ensure that either Authenticated Users or Domain Computers are not processing GP.
Thank you for your reply.
Since we only have a couple of GPOs with Security Filtering, I manually added the “Domain Computers” group with Read permission in the Delegation tab. This seems to have fixed our issues. The GPOs we have are for folder redirection.
Thanks again for your article.
How do we manage this when using Change Control, AGPM?
If I run Powershell and add “Authenticated Users” or “Domain Computers” with READ access on the GP objects, then I import them into AGPM, I can’t see that this security setting is imported. If I then Deploy this GPO from AGPM to production, the security setting is gone..
Unfortunately I don’t know enough about what AGPM does with permissions to know why this is happening. I hate to say it but you might have to make this change outside of AGPM. But I’ll see if I can poke around and find out.
Darren
Hi
First of all; sorry for commenting on an old comment.
But since it seems like there is no answer to the AGPM question, I guess someone could have some benefit from knowing how to handle this with AGPM
In AGPM you choose change control, then the tab Production delegation.
Here you add domain computers with read access (or authenticated users with read access)
To set the permissions for existing controlled GPOs, go to the controlled GPOs, select all GPOs, right click and deploy.
This will update the production delegation on the controlled GPOs to what you have set in the production delegation tab.
This will also ensure that new controlled GPOs will have the correct permissions. (Read access for the computer account)
Hope this helps someone with AGPM.
Please let me know if this didn’t work for you. Worked well for me.
/Karl M S
Hi,
Thank you for a script
In our enviroment I made changes to first if:
if ($gpo.user.Enabled -contains “*True*”)
because DSversion might be greater than 0
Well, those are two separate questions–1, that the user side is enabled in the first place, and 2, that it has settings. I think for completeness, you could probably test for both 🙂
Hi
I am wondering if maybe you can help me with an issue that I am having after the patch update
I have added the authenticated users to the gpo’s and most of them are working now on windows 7 & 10 pc’s
But on win 8.1 pc’s I am having problems.
On win 7 & 10 pc’s I am having problems only with adding sites to the compatibility mode in explorer
The policy shows as applied but no effect in internet explorer
I am using: user configuration -> administrative templates -> windows components -> internet explorer -> compatibility view -> use policy list of internet explorer 7 sites
On win 8.1 pc’s I am having problems with adding sites to the compatibility mode in explorer & setting logon script by gpo
I am using: user configuration -> policies -> windows settings -> scripts -> logon
Before the installation of the latest updates all the configuration was working.
Please advise
Thank you,
You described the issue better than every MS announcement I read.
What an awesome article. Well put. My question – which I see from another comment is – why do my changes disappear. Yesterday I added authenticated users to delegates tab in GPO. Tested and the change worked. This morning however, this addition had gone missing from GPO. Also – Can I add both Authenticated Users and Domain Computers – or does it have to be just one of these options
Kathy-
I’m not sure why those permissions would disappear. But one thing you can try–add Domain Computers group with Read permission instead of Authenticated Users. Both will work and I like Domain Computers better because it doesn’t expose the GPO unnecessarily to *everyone*. See if that works any better.
Thanks for this very useful – I’ve just run the MS check script https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/
Now whilst it flags that we have GPOs to investigate, we have groups for servers\computers rather than users defined, so am I right to say this issue wouldn’t affect those GPOs?
Correct Soban. This issue only affects GPOs that have been filtered by user-based security groups.
Thxs a lot, script works like a charm
My organization experienced this issue on all physical desktops / laptops. We added the Allowed Permissions (User Authentication – Read) to all GPOs. This fixed all user based GPOs failing to be read and applied to the workstations during login. We have since applied this security patch to our VMWare Horizon View virtual desktops. As soon as we did that all our virtual workstations started failing to read and apply the Computer based GPOs under the Client Side Extension – {35378EAC-683F-11D2-A89A-00C04FBBCFA2}. This extension in the registry normally shows all workstation based GPO’s, their order of processing and detailed info. The only GPO displaying now is the Default Domain Policy. We remove this security patch and the CSE list goes back to normal and workstation GPOs are processed successfully. So we seem to be experiencing the opposite effect of the initial issue with this security patch. Anyone have any ideas? The GPO’s that are failing are linked to the parent OU to where the workstations live. The Security Filtering is set to Authenticated Users. Allowed Permissions are set to (Authenticated Users – Read), (Domain Computers – Read, Apply Group Policy). All other permissions are set to normal default. I appreciate any suggestions!
Daniel
This is news to me, but then again, I’m not sure what’s different about View desktops vs. regular ones. That CSE GUID is the core CSE, responsible for processing Admin Template settings. It’s not clear from your message if that is the only GUID that works or it’s the only GUID that DOESN’T? Also–where in the registry are you viewing this? The real test is, what does RSOP say on those machines?
Darren
Thanks for the response Darren! The only real difference would be the View Desktops are created on a needed basis. When you logout of a view desktop it is destroyed and a new machine is created. So each time that happens the GPO is applying itself to the workstation for the first and only time. Other CSEs are working that handle User Based GPO settings. All CSE’s that handle Computer Based GPOs no longer list all computer based GPOs. Only the Default Domain Policy is listed. They are essentially ignoring the other policies almost like the workstation doesn’t have permissions to them.
HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\{35378EAC-683F-11D2-A89A-00C04FBBCFA2}
In the event log the Computer Based GPO I’m interested in is not referenced. Like its being ignored. GPResult /R only lists User Based GPOs being applied, no workstation GPOs. I can’t retrieve the RSOP data at this time. I will try to get that. Just didn’t know if anyone has seen this issue.