First published on TechNet on Jun 22, 2016
This post was written to provide guidance and answer questions needed by administrators to deploy the newly released security update,
that addresses a vulnerability. The vulnerability could 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.
The table below summarizes the KB article number for the relevant Operating System:
What does this security update change?
The most important aspect of this security update is to understand the behavior changes affecting the way User Group Policy is applied on a Windows computer.
changes the security context with which user group policies are retrieved. Traditionally, when a user group policy is retrieved, it is processed using the
user's security context
is installed, user group policies are retrieved by using the
computer's security context
behavior change protects domain joined computers from a security vulnerability.
When a user group policy is retrieved using the computer's security context, the computer account will now
“read” access to retrieve the group policy objects (GPOs) needed to apply to the user.
Traditionally, all group policies were read if the
had read access either directly or being part of a domain group e.g. Authenticated Users
What do we need to check before deploying this security update?
As discussed above, by default “Authenticated Users” have
“Apply Group Policy”
on all Group Policy Objects in an Active Directory Domain.
Below is a screenshot from the Default Domain Policy:
If permissions on any of the Group Policy Objects in your active Directory domain have not been modified, are using the defaults, and as long as Kerberos authentication is working fine in your Active Directory forest (i.e. there are not Kerberos errors visible in the system event log on client computers while accessing domain resources), there is nothing else you need to make sure before you deploy the security update.
In some deployments, administrators may have removed the
group from some or all Group Policy Objects (Security filtering,
In such cases, you will need to make sure of the following before you deploy the security update:
- Check if
group read permissions were removed intentionally by the admins. If not, then you should probably add those back. For example, if you do not use any security filtering to target specific group policies to a set of users, you could add
back with the default permissions as shown in the example screenshot above.
- If the “Authenticated Users” permissions were removed intentionally (security filtering, etc), then as a result of the
in this security update
(i.e. to now use the computer's security context to retrieve user policies)
, you will need to add the computer account retrieving the group policy object (GPO) to
Group Policy (and
“Apply group policy
In the above example screenshot, let's say an Administrator wants
(Name of the Group Policy Object) to only apply to the user with name
and not to any other user, then the above is how the Group Policy would have been filtered for other users. “Authenticated Users” has been removed intentionally in the above example scenario.
What will happen if there are Group Policy Objects (GPOs) in an Active Directory domain that are using security filtering as discussed in the example scenario above?
Symptoms when you have security filtering Group Policy Objects (GPOs) like the above example and you install the security update MS16-072:
- Printers or mapped drives assigned through Group Policy Preferences disappear.
- Shortcuts to applications on users' desktop are missing
- Security filtering group policy does not process anymore
- You may see the following change in gpresult:
Filtering: Not Applied (Unknown Reason)
- If you are using Folder Redirection and the Folder Redirection group policy removal option is set to “Redirect the folder back to the user profile location when policy is removed,” the redirected folders are moved back to the client machine after installing this security update
What is the Resolution?
Simply adding the “Authenticated Users” group with the “Read” permissions on the Group Policy Objects (GPOs) should be sufficient. Domain Computers are part of the “Authenticated Users” group. “Authenticated Users” have these permissions on any new Group Policy Objects (GPOs) by default. Again, the guidance is to add just “Read” permissions and not “Apply Group Policy” for “Authenticated Users”
What if adding Authenticated Users with Read permissions is not an option?
If adding “Authenticated Users” with just “Read” permissions is not an option in your environment, then you will need to add the “Domain Computers” group with “Read” Permissions. If you want to limit it beyond the Domain Computers group: Administrators can also create a new domain group and add the computer accounts to the group so you can limit the “Read Access” on a Group Policy Object (GPO). However, computers will not pick up membership of the new group until a reboot. Also keep in mind that with this security update installed, this additional step is only required if the default “Authenticated Users” Group has been removed from the policy where user settings are applied.
Now in the above scenario, after you install the security update, as the user group policy needs to be retrieved using the
system's security context
, (domain joined system being part of the “Domain Computers” security group by default), the client computer will be able to retrieve the user policies required to be applied to the user and the same will be processed successfully.
How to identify GPOs with issues:
In case you have already installed the security update and need to identify Group Policy Objects (GPOs) that are affected, the easy way is just to do a simple
on a Windows client computer and then run the
gpresult /h new-report.html
-> Open the
and review for any errors like:
“Reason Denied: Inaccessible, Empty or Disabled”
What if there are lot of GPOs?
A script is available which can detect all Group Policy Objects (GPOs) in your domain which may have the “Authenticated Users” missing “Read” Permissions
You can get the script from here:
- The script can run only on Windows 7 and above Operating Systems which have the RSAT or GPMC installed or Domain Controllers running Windows Server 2008 R2 and above
- The script works in a single domain scenario.
- Domain Computers are part of the Authenticated Users group
- The script can only add permissions to the Group Policy Objects (GPOs) in the same domain as the context of the current user running the script. In a multi domain forest, you must run it in the context of the Domain Admin of the other domain in your forest.
Sample Screenshots when you run the script:
In the first sample screenshot below, running the script detects all Group Policy Objects (GPOs) in your domain which has the “Authenticated Users” missing the Read Permission.
If you hit “Y”, you will see the below message:
What if there are AGPM managed Group Policy Objects (GPOs)?
Follow the steps below to add “Authenticated Users” with Read Permissions:
To change the permissions for all managed GPO's and add Authenticated Users Read permission follow these steps:
Re-import all Group Policy Objects (GPOs) from production into the AGPM database. This will ensure the latest copy of production GPO's.
Add either “Authenticated Users” or “Domain Computers” the READ permission using the Production Delegation Tab by selecting the security principal, granting the “READ” role then clicking “OK”
Grant the selected security principal the “Read” role.
Delegation tab depicting Authenticated Users having the READ permissions.
Select and Deploy GPOs again:
Note: To modify permissions on multiple AGPM-managed GPOs, use shift+click or ctrl+click to select multiple GPO's at a time then deploy them in a single operation.
CTRL_A does not select all policies.
The targeted GPO now have the new permissions when viewed in AD:
Below are some Frequently asked Questions we have seen:
Frequently Asked Questions (FAQs):
) Do I need to install the fix on only client OS? OR do I also need to install it on the Server OS?
) It is recommended you patch Windows and Windows Server computers which are running Windows Vista, Windows Server 2008 and newer Operating Systems (OS), regardless of SKU or role, in your entire domain environment. These updates only change behavior from a client (as in “client-server distributed system architecture”) standpoint, but all computers in a domain are “clients” to SYSVOL and Group Policy; even the Domain Controllers (DCs) themselves
) Do I need to enable any registry settings to enable the security update?
No, this security update will be enabled when you install the MS16-072 security update, however you need to check the permissions on your Group Policy Objects (GPOs) as explained above
What will change in regard to how group policy processing works after the security update is installed?
To retrieve user policy, the connection to the Windows domain controller (DC) prior to the installation of MS16-072 is done under the user's security context. With this security update installed, instead of user's security context, Windows group policy clients will now force local system's security context, therefore forcing Kerberos authentication
Should the UNC Hardening security update with the above registry settings not take care of this vulnerability when processing group policy from the SYSVOL?
No. UNC Hardening alone will not protect against this vulnerability. In order to protect against this vulnerability, one of the following scenarios must apply: UNC Hardened access is enabled for SYSVOL/NETLOGON as suggested, and the client computer is configured to require Kerberos FAST Armoring
– OR –
UNC Hardened Access is enabled for SYSVOL/NETLOGON, and this particular security update (
) is installed
If we have security filtering on Computer objects, what change may be needed after we install the security update?
Nothing will change in regard to how Computer Group Policy retrieval and processing works
We are using security filtering for user objects and after installing the update, group policy processing is not working anymore
As noted above, the security update changes the way user group policy settings are retrieved. The reason for group policy processing failing after the update is installed is because you may have removed the default “Authenticated Users” group from the Group Policy Object (GPO). The computer account will now need
permissions on the Group Policy Object (GPO). You can add
permissions on the Group Policy Object (GPO) to be able to retrieve the list of GPOs to download for the user
Example Screenshot as below:
Will installing this security update impact cross forest user group policy processing?
this security update will not impact cross forest user group policy processing. When a user from one forest logs onto a computer in another forest and the group policy setting “Allow Cross-Forest User Policy and Roaming User Profiles” is enabled, the user group policy during the cross forest logon will be retrieved using the user's security context.
Is there a need to specifically add “Domain Computers” to make user group policy processing work or adding “Authenticated Users” with just read permissions should suffice?
Supportability Program Manager – Windows
6/29/16 – added script link and prereqs
7/11/16 – added information about AGPM
8/16/16 – added note about folder redirection