The permission on the Group Policy Container (the GPC, an Active Directory object) has been set to deny your read-level permission. The permissions on the filesystem object you've found (the "Group Policy Template", or GPT) can "come out of sync" with the permissions on the Active Directory object. (For some background, have a look at http://msdn.microsoft.com/en-us/library/aa374180(VS.85).aspx).
Fortunately, you can use a tool like ADSIEDIT to restore the permission on the GPC. Using ADSIEDIT you'll find a "groupPolicyContainer" corresponding to the GUID of the problematic GPO under the "CN=Policies" object of the "CN=System" object in the Domain NC of the domain the GPO resides in. (Install ADSIEDIT from the Support Tools on the Windows Server media, open it, drill into "Domain", then "CN=System" and "CN=Policies" and you'll find the GPC).
Using the "Security" tab of the "Properties" sheet for the GPC corresponding to the problematic GPO and use the "Default" button in the "Advanced" dialog to restore the default permissions.
If ADSIEDIT won't allow you to modify the permissions (probably displaying an oddball error message like "An invalid directory pathname was passed"), then likely someone placed a "Deny / Full Control" permission onto the object. The dsacls
command with the arguments CN=GUID-OF-THE-PROBLEMATIC-GPO,CN=Policies,CN=System,DC=your,DC=domain,DC=com
will report the permissions. Search for the errant "Deny" and "FULL CONTROL" entry and use the /R user-or-group-namme
parameter on dsacls
to remove the permissions associated with that user or group. If it's really messed up then you'll probably have to use the Windows Server 2008 ADAM / AD LDS version of dscals
with the /takeownership
argument to take ownership of the object).
Check the patch joeqwerty link too.
There is the important detail:
Known issues
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. This issue is applicable for the following KB articles:
- 3159398 MS16-072: Description of the security update for Group
Policy: June 14, 2016
- 3163017 Cumulative update for Windows 10: June 14, 2016
- 3163018 Cumulative update for Windows 10 Version 1511 and Windows
Server 2016 Technical Preview 4: June 14, 2016
- 3163016 Cumulative Update for Windows Server 2016 Technical Preview
5: June 14 2016
Symptoms
All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.
Cause
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.
Resolution
To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
- Add the Authenticated Users group with Read Permissions on the Group
Policy Object (GPO).
- If you are using security filtering, add the Domain Computers group
with read permission.
See this link Deploy MS16-072 which explains everything and offers script to repair the affected GPOs. The script adds Authenticated users read permissions to all GPOs which have no permission for Authenticated users.
# Copyright (C) Microsoft Corporation. All rights reserved.
$osver = [System.Environment]::OSVersion.Version
$win7 = New-Object System.Version 6, 1, 7601, 0
if($osver -lt $win7)
{
Write-Error "OS Version is not compatible for this script. Please run on Windows 7 or above"
return
}
Try
{
Import-Module GroupPolicy
}
Catch
{
Write-Error "GP Management tools may not be installed on this machine. Script cannot run"
return
}
$arrgpo = New-Object System.Collections.ArrayList
foreach ($loopGPO in Get-GPO -All)
{
if ($loopGPO.User.Enabled)
{
$AuthPermissionsExists = Get-GPPermissions -Guid $loopGPO.Id -All | Select-Object -ExpandProperty Trustee | ? {$_.Name -eq "Authenticated Users"}
If (!$AuthPermissionsExists)
{
$arrgpo.Add($loopGPO) | Out-Null
}
}
}
if($arrgpo.Count -eq 0)
{
echo "All Group Policy Objects grant access to 'Authenticated Users'"
return
}
else
{
Write-Warning "The following Group Policy Objects do not grant any permissions to the 'Authenticated Users' group:"
foreach ($loopGPO in $arrgpo)
{
write-host "'$($loopgpo.DisplayName)'"
}
}
$title = "Adjust GPO Permissions"
$message = "The Group Policy Objects (GPOs) listed above do not have the Authenticated Users group added with any permissions. Group policies may fail to apply if the computer attempting to list the GPOs required to download does not have Read Permissions. Would you like to adjust the GPO permissions by adding Authenticated Users group Read permissions?"
$yes = New-Object System.Management.Automation.Host.ChoiceDescription "&Yes", `
"Adds Authenticated Users group to all user GPOs which don't have 'Read' permissions"
$no = New-Object System.Management.Automation.Host.ChoiceDescription "&No", `
"No Action will be taken. Some Group Policies may fail to apply"
$options = [System.Management.Automation.Host.ChoiceDescription[]]($yes, $no)
$result = $host.ui.PromptForChoice($title, $message, $options, 0)
$appliedgroup = $null
switch ($result)
{
0 {$appliedgroup = "Authenticated Users"}
1 {$appliedgroup = $null}
}
If($appliedgroup)
{
foreach($loopgpo in $arrgpo)
{
write-host "Adding 'Read' permissions for '$appliedgroup' to the GPO '$($loopgpo.DisplayName)'."
Set-GPPermissions -Guid $loopgpo.Id -TargetName $appliedgroup -TargetType group -PermissionLevel GpoRead | Out-Null
}
}
If you preffer to set the read permission for Domain Computers (as I do) rather than Authenticated Users just change this 0 {$appliedgroup = "Authenticated Users"}
to that 0 {$appliedgroup = "Domain Computers"}
Best Answer
Hi Ryan looks like a classic replication issue,when editing gpos on any dc-usually it changes files in the sysvol folder on the Domain Controller holding the PDC Emulator role ,determine which DC holds the PDC role,and test replication from it to the problematic DC.