First published on TechNet on Jul 20, 2016
[This post comes to us courtesy of Susan Bradley, Wayne Small and Schumann GE (from Product Group)]
On June 14, 2016 Microsoft released MS16-072 KB3159398 to fix a vulnerability in Group Policy whereby an attacker can allow elevation of privilege if an attacker launches a man-in-the-middle (MiTM) attack against the traffic passing between a domain controller and the target machine on domain-joined Windows computers. After MS16-072 is installed, user group policies are retrieved by using the computer’s security context. This by-design behavior change protects domain joined computers from a security vulnerability. Any Group policy that performs Security filtering on a per user basis will need to be adjusted now work after MS16-072.
For SBS 2008 and SBS 2011 in particular there are several group policies set up in the product for purposes of controlling the users’ desktop environment and Windows Software Update Services (WSUS) that are directly impacted by this change and will need adjustment in order to continue to work after the application of this patch.
There will be no automated patch to fix this issue on the SBS 2011 platform, thus we recommend that you take the following action to ensure that the default group polices on the SBS 2008 and SBS 2011 server are adjusted as well as checking if any group policies you have placed on the systems are impacted.
I would like to thank various blogs and resources that provided additional information that I am relying on in order to provide the information for the SBS community.
If you’d like to review these additional resources, I’d recommend reviewing Jeremy Moskowitz’s blog , and Darren Mar-Elia’s blog . Additional resources include the AskDS blog , and the JH consulting blog . I would recommend reviewing these additional resources if you manage different Server platforms as the commands and PowerShell scripts are slightly different for different versions of Windows Server.
Prior to MS16-072, Group policy could be set up with security filtering uniquely for computer users. Both the SBS 2008 and SBS 2011 systems as part of the SBSMonitoring service run a routine that every 20 minutes there is a service that synchronizes the SBS created (“stamped”) users with the Security Filtering on the “Windows SBS User Policy” so that the SBS can deploy specific settings to the users desktop environment. If you merely add the Domain computers READ right to the security filtering section in group policy (or any other manual change to security filtering), 20 minutes later you will find this right removed. So we must add this domain computer READ right in a specific way.
I’d first recommend that you review your server(s) and workstations to confirm that the patch has been deployed. Secondly, you will need to review your group policies to asses if they are impacted. An excellent PowerShell script you can use to check your systems is from the PoSHChap blog .
To begin, log into your SBS 2011 server. Find Windows PowerShell under Accessories/Windows PowerShell. Right mouse click and click on Run as Administrator.
Now copy and paste the following script to review what group polices are impacted:
Copy below this line
===============================================================================
#Load GPO module
Import-Module GroupPolicy
#Get all GPOs in current domain
$GPOs = Get-GPO -All
#Check we have GPOs
if ($GPOs) {
#Loop through GPOs
foreach ($GPO in $GPOs) {
#Nullify $AuthUser & $DomComp
$AuthUser = $null
$DomComp = $null
#See if we have an Auth Users perm
$AuthUser = Get-GPPermissions -Guid $GPO.Id -TargetName “Authenticated Users” -TargetType Group -ErrorAction SilentlyContinue
#See if we have the ‘Domain Computers perm
$DomComp = Get-GPPermissions -Guid $GPO.Id -TargetName “Domain Computers” -TargetType Group -ErrorAction SilentlyContinue
#Alert if we don’t have an ‘Authenticated Users’ permission
if (-not $AuthUser) {
#Now check for ‘Domain Computers’ permission
if (-not $DomComp) {
Write-Host “WARNING: $($GPO.DisplayName) ($($GPO.Id)) does not have an ‘Authenticated Users’ permission or ‘Domain Computers’ permission – please investigate” -ForegroundColor Red
} #end of if (-not $DomComp)
else {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Host “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) does not have an ‘Authenticated Users’ permission but does have a ‘Domain Computers’ permission” -ForegroundColor Yellow
} #end of else (-not $DomComp)
} #end of if (-not $AuthUser)
elseif (($AuthUser.Permission -ne “GpoApply”) -and ($AuthUser.Permission -ne “GpoRead”)) {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Host “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) has an ‘Authenticated Users’ permission that isn’t ‘GpoApply’ or ‘GpoRead'” -ForegroundColor Yellow
} #end of elseif (($AuthUser.Permission -ne “GpoApply”) -or ($AuthUser.Permission -ne “GpoRead”))
else {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Output “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) has an ‘Authenticated Users’ permission”
} #end of else (-not $AuthUser)
} #end of foreach ($GPO in $GPOs)
} #end of if ($GPOs)
===============================================================================
Copy above this line
Script courtesy of https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/
Either paste the script into your PowerShell window on the server or save it as a .ps1 script and run it. You should see several red warnings that several of your group policies do not have the right permissions.
In reading various scripts online – It turns out there are different PowerShell commands for GP Permissions in 2008/2008R2 vs later versions of Windows. So be aware the solution provided in this blog post specifically works on 2008 and 2008 R2 and does not work on 2012 and 2012 R2. Specially the difference is simple – for 2008 and 2008 R2, replace the Get-GPPermission and Set-GPPermission commands with Get-GPPermissions and Set-GPPermissions in the script and it will work fine.
Secondly – given we have a large number of SBS sites still, I did some specific testing with it. The results of the script means that the following policies are affected by this issue and MAY NOT APPLY if you don’t add the Authenticated Users OR Domain Computers as READ on the Delegation tab for that GPO.
Microsoft have indicated specific conditions for using either Authenticated Users OR Domain Computers with the READ permission. I’ve done quite a bit of investigation and in conversation with Group Policy MVPs, have decided that I will implement this consistently using the Domain Computers group as this works for all scenarios.
Now we need to adjust the permissions so that the group policies work after the installation of MS16-072 , the patch of KB3159398 .
For SBS 2011 in the PowerShell window cut and paste the following script:
Copy below this line
===============================================================================
Import-Module GroupPolicy
Get-GPO -All | Set-GPPermissions -TargetType Group -TargetName "Domain computers" -PermissionLevel GpoRead
===============================================================================
Copy above this line
The first line calls the Group policy module for PowerShell, the second line adds the Domain Computers READ right to the delegation tab so that the Security filtering set up by the server can continue to process.
The script should scroll through the settings and adjust the group policies.
The script has done what it needs to do. If you’d like to visually see the impact, if you go to any Group policy object you will now see Domain Computers on the delegation tab with READ rights.
On the Group policy object of Windows SBS User policy you should now see
Domain Computers with a Read right to the Group policy object.
Now run the testing script again to confirm that your group policy permissions have been adjusted.
Once again copy and paste the following script in the PowerShell window or save it as a .ps1 script:
Copy below this line
===============================================================================
#Load GPO module
Import-Module GroupPolicy
#Get all GPOs in current domain
$GPOs = Get-GPO -All
#Check we have GPOs
if ($GPOs) {
#Loop through GPOs
foreach ($GPO in $GPOs) {
#Nullify $AuthUser & $DomComp
$AuthUser = $null
$DomComp = $null
#See if we have an Auth Users perm
$AuthUser = Get-GPPermissions -Guid $GPO.Id -TargetName “Authenticated Users” -TargetType Group -ErrorAction SilentlyContinue
#See if we have the ‘Domain Computers perm
$DomComp = Get-GPPermissions -Guid $GPO.Id -TargetName “Domain Computers” -TargetType Group -ErrorAction SilentlyContinue
#Alert if we don’t have an ‘Authenticated Users’ permission
if (-not $AuthUser) {
#Now check for ‘Domain Computers’ permission
if (-not $DomComp) {
Write-Host “WARNING: $($GPO.DisplayName) ($($GPO.Id)) does not have an ‘Authenticated Users’ permission or ‘Domain Computers’ permission – please investigate” -ForegroundColor Red
} #end of if (-not $DomComp)
else {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Host “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) does not have an ‘Authenticated Users’ permission but does have a ‘Domain Computers’ permission” -ForegroundColor Yellow
} #end of else (-not $DomComp)
} #end of if (-not $AuthUser)
elseif (($AuthUser.Permission -ne “GpoApply”) -and ($AuthUser.Permission -ne “GpoRead”)) {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Host “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) has an ‘Authenticated Users’ permission that isn’t ‘GpoApply’ or ‘GpoRead'” -ForegroundColor Yellow
} #end of elseif (($AuthUser.Permission -ne “GpoApply”) -or ($AuthUser.Permission -ne “GpoRead”))
else {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Output “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) has an ‘Authenticated Users’ permission”
} #end of else (-not $AuthUser)
} #end of foreach ($GPO in $GPOs)
} #end of if ($GPOs)
===============================================================================
Copy above this line
Script courtesy of https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/
Your resulting testing screen should not show any red warnings and instead be filled with white and yellow comments:
Your SBS 2011 default group polices will now function as usual.
If you’d like to make all future group polices you set up work by default with the new behavior, you can follow the advice in the section entitled “Making the change permanent in Active Directory for future / newly born GPOs” in the Jeremy Moskowitz’s blog .
For SBS 2008, you’ll need to manually add the READ permission right to the delegation tab as shown:
On the Group policy object of Windows SBS User policy you should now see
[This post comes to us courtesy of Susan Bradley, Wayne Small and Schumann GE (from Product Group)]
On June 14, 2016 Microsoft released MS16-072 KB3159398 to fix a vulnerability in Group Policy whereby an attacker can allow elevation of privilege if an attacker launches a man-in-the-middle (MiTM) attack against the traffic passing between a domain controller and the target machine on domain-joined Windows computers. After MS16-072 is installed, user group policies are retrieved by using the computer’s security context. This by-design behavior change protects domain joined computers from a security vulnerability. Any Group policy that performs Security filtering on a per user basis will need to be adjusted now work after MS16-072.
For SBS 2008 and SBS 2011 in particular there are several group policies set up in the product for purposes of controlling the users’ desktop environment and Windows Software Update Services (WSUS) that are directly impacted by this change and will need adjustment in order to continue to work after the application of this patch.
There will be no automated patch to fix this issue on the SBS 2011 platform, thus we recommend that you take the following action to ensure that the default group polices on the SBS 2008 and SBS 2011 server are adjusted as well as checking if any group policies you have placed on the systems are impacted.
I would like to thank various blogs and resources that provided additional information that I am relying on in order to provide the information for the SBS community.
If you’d like to review these additional resources, I’d recommend reviewing Jeremy Moskowitz’s blog , and Darren Mar-Elia’s blog . Additional resources include the AskDS blog , and the JH consulting blog . I would recommend reviewing these additional resources if you manage different Server platforms as the commands and PowerShell scripts are slightly different for different versions of Windows Server.
Prior to MS16-072, Group policy could be set up with security filtering uniquely for computer users. Both the SBS 2008 and SBS 2011 systems as part of the SBSMonitoring service run a routine that every 20 minutes there is a service that synchronizes the SBS created (“stamped”) users with the Security Filtering on the “Windows SBS User Policy” so that the SBS can deploy specific settings to the users desktop environment. If you merely add the Domain computers READ right to the security filtering section in group policy (or any other manual change to security filtering), 20 minutes later you will find this right removed. So we must add this domain computer READ right in a specific way.
I’d first recommend that you review your server(s) and workstations to confirm that the patch has been deployed. Secondly, you will need to review your group policies to asses if they are impacted. An excellent PowerShell script you can use to check your systems is from the PoSHChap blog .
To begin, log into your SBS 2011 server. Find Windows PowerShell under Accessories/Windows PowerShell. Right mouse click and click on Run as Administrator.
Now copy and paste the following script to review what group polices are impacted:
Copy below this line
===============================================================================
#Load GPO module
Import-Module GroupPolicy
#Get all GPOs in current domain
$GPOs = Get-GPO -All
#Check we have GPOs
if ($GPOs) {
#Loop through GPOs
foreach ($GPO in $GPOs) {
#Nullify $AuthUser & $DomComp
$AuthUser = $null
$DomComp = $null
#See if we have an Auth Users perm
$AuthUser = Get-GPPermissions -Guid $GPO.Id -TargetName “Authenticated Users” -TargetType Group -ErrorAction SilentlyContinue
#See if we have the ‘Domain Computers perm
$DomComp = Get-GPPermissions -Guid $GPO.Id -TargetName “Domain Computers” -TargetType Group -ErrorAction SilentlyContinue
#Alert if we don’t have an ‘Authenticated Users’ permission
if (-not $AuthUser) {
#Now check for ‘Domain Computers’ permission
if (-not $DomComp) {
Write-Host “WARNING: $($GPO.DisplayName) ($($GPO.Id)) does not have an ‘Authenticated Users’ permission or ‘Domain Computers’ permission – please investigate” -ForegroundColor Red
} #end of if (-not $DomComp)
else {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Host “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) does not have an ‘Authenticated Users’ permission but does have a ‘Domain Computers’ permission” -ForegroundColor Yellow
} #end of else (-not $DomComp)
} #end of if (-not $AuthUser)
elseif (($AuthUser.Permission -ne “GpoApply”) -and ($AuthUser.Permission -ne “GpoRead”)) {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Host “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) has an ‘Authenticated Users’ permission that isn’t ‘GpoApply’ or ‘GpoRead'” -ForegroundColor Yellow
} #end of elseif (($AuthUser.Permission -ne “GpoApply”) -or ($AuthUser.Permission -ne “GpoRead”))
else {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Output “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) has an ‘Authenticated Users’ permission”
} #end of else (-not $AuthUser)
} #end of foreach ($GPO in $GPOs)
} #end of if ($GPOs)
===============================================================================
Copy above this line
Script courtesy of https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/
Either paste the script into your PowerShell window on the server or save it as a .ps1 script and run it. You should see several red warnings that several of your group policies do not have the right permissions.
In reading various scripts online – It turns out there are different PowerShell commands for GP Permissions in 2008/2008R2 vs later versions of Windows. So be aware the solution provided in this blog post specifically works on 2008 and 2008 R2 and does not work on 2012 and 2012 R2. Specially the difference is simple – for 2008 and 2008 R2, replace the Get-GPPermission and Set-GPPermission commands with Get-GPPermissions and Set-GPPermissions in the script and it will work fine.
Secondly – given we have a large number of SBS sites still, I did some specific testing with it. The results of the script means that the following policies are affected by this issue and MAY NOT APPLY if you don’t add the Authenticated Users OR Domain Computers as READ on the Delegation tab for that GPO.
- Windows SBS User Policy
- SharePoint PSConfig Notification Policy
- Update Services Server Computers Policy
- Update Services Client Computers Policy
Microsoft have indicated specific conditions for using either Authenticated Users OR Domain Computers with the READ permission. I’ve done quite a bit of investigation and in conversation with Group Policy MVPs, have decided that I will implement this consistently using the Domain Computers group as this works for all scenarios.
Now we need to adjust the permissions so that the group policies work after the installation of MS16-072 , the patch of KB3159398 .
For SBS 2011 in the PowerShell window cut and paste the following script:
Copy below this line
===============================================================================
Import-Module GroupPolicy
Get-GPO -All | Set-GPPermissions -TargetType Group -TargetName "Domain computers" -PermissionLevel GpoRead
===============================================================================
Copy above this line
The first line calls the Group policy module for PowerShell, the second line adds the Domain Computers READ right to the delegation tab so that the Security filtering set up by the server can continue to process.
The script should scroll through the settings and adjust the group policies.
The script has done what it needs to do. If you’d like to visually see the impact, if you go to any Group policy object you will now see Domain Computers on the delegation tab with READ rights.
On the Group policy object of Windows SBS User policy you should now see
Domain Computers with a Read right to the Group policy object.
Now run the testing script again to confirm that your group policy permissions have been adjusted.
Once again copy and paste the following script in the PowerShell window or save it as a .ps1 script:
Copy below this line
===============================================================================
#Load GPO module
Import-Module GroupPolicy
#Get all GPOs in current domain
$GPOs = Get-GPO -All
#Check we have GPOs
if ($GPOs) {
#Loop through GPOs
foreach ($GPO in $GPOs) {
#Nullify $AuthUser & $DomComp
$AuthUser = $null
$DomComp = $null
#See if we have an Auth Users perm
$AuthUser = Get-GPPermissions -Guid $GPO.Id -TargetName “Authenticated Users” -TargetType Group -ErrorAction SilentlyContinue
#See if we have the ‘Domain Computers perm
$DomComp = Get-GPPermissions -Guid $GPO.Id -TargetName “Domain Computers” -TargetType Group -ErrorAction SilentlyContinue
#Alert if we don’t have an ‘Authenticated Users’ permission
if (-not $AuthUser) {
#Now check for ‘Domain Computers’ permission
if (-not $DomComp) {
Write-Host “WARNING: $($GPO.DisplayName) ($($GPO.Id)) does not have an ‘Authenticated Users’ permission or ‘Domain Computers’ permission – please investigate” -ForegroundColor Red
} #end of if (-not $DomComp)
else {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Host “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) does not have an ‘Authenticated Users’ permission but does have a ‘Domain Computers’ permission” -ForegroundColor Yellow
} #end of else (-not $DomComp)
} #end of if (-not $AuthUser)
elseif (($AuthUser.Permission -ne “GpoApply”) -and ($AuthUser.Permission -ne “GpoRead”)) {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Host “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) has an ‘Authenticated Users’ permission that isn’t ‘GpoApply’ or ‘GpoRead'” -ForegroundColor Yellow
} #end of elseif (($AuthUser.Permission -ne “GpoApply”) -or ($AuthUser.Permission -ne “GpoRead”))
else {
#COMMENT OUT THE BELOW LINE TO REDUCE OUTPUT!
Write-Output “INFORMATION: $($GPO.DisplayName) ($($GPO.Id)) has an ‘Authenticated Users’ permission”
} #end of else (-not $AuthUser)
} #end of foreach ($GPO in $GPOs)
} #end of if ($GPOs)
===============================================================================
Copy above this line
Script courtesy of https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/
Your resulting testing screen should not show any red warnings and instead be filled with white and yellow comments:
Your SBS 2011 default group polices will now function as usual.
If you’d like to make all future group polices you set up work by default with the new behavior, you can follow the advice in the section entitled “Making the change permanent in Active Directory for future / newly born GPOs” in the Jeremy Moskowitz’s blog .
For SBS 2008, you’ll need to manually add the READ permission right to the delegation tab as shown:
On the Group policy object of Windows SBS User policy you should now see
Published Apr 05, 2019
Version 1.0
sbs-team
Microsoft
Microsoft
