Deploying Group Policy Security Update MS16-072 \ KB3163622

My name is Ajay Sarkaria & I work with the Windows Supportability team at Microsoft. There have been many questions on deploying the newly released security update MS16-072.

This post was written to provide guidance and answer questions needed by administrators to deploy the newly released security update, MS16-072 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. MS16-072 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.

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.

When a user group policy is retrieved using the computer's security context, the computer account will now need "read" access to retrieve the group policy objects (GPOs) needed to apply to the user.

Traditionally, all group policies were read if the "user" 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 "Read" and "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 "Authenticated Users" group from some or all Group Policy Objects (Security filtering, etc.)

In such cases, you will need to make sure of the following before you deploy the security update:

1. Check if "Authenticated Users" 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 "Authenticated Users" back with the default permissions as shown in the example screenshot above.

2. If the "Authenticated Users" permissions were removed intentionally (security filtering, etc), then as a result of the by-design change 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 "Read" Group Policy (and not "Apply group policy").

   Example Screenshot:

   

In the above example screenshot, let's say an Administrator wants "User-Policy" (Name of the Group Policy Object) to only apply to the user with name "MSFT Ajay" 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.

Notice that no other user or group is included to have "Read" or "Apply Group Policy" permissions other than the default Domain Admins and Enterprise Admins. These groups do not have "Apply Group Policy" by default so the GPO would not apply to the users of these groups & apply only to user "MSFT Ajay"

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.

Example Screenshots:

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 gpupdate /force on a Windows client computer and then run the gpresult /h new-report.html -> Open the new-report.html 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: https://gallery.technet.microsoft.com/Powershell-script-to-cc281476

Pre-Reqs:

• 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.
• The script will detect all GPOs in your domain (Not Forest) which are missing “Authenticated Users” permissions & give the option to add “Authenticated Users” with “Read” Permissions (Not Apply Group Policy). If you have multiple domains in your Active Directory Forest, you will need to run this for each domain.
  • 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):

Q1) Do I need to install the fix on only client OS? OR do I also need to install it on the Server OS?

A1) 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

Q2) Do I need to enable any registry settings to enable the security update?

A2) 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

Q3) What will change in regard to how group policy processing works after the security update is installed?

A3) 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

Q4) We already have the security update MS15-011 & MS15-014 installed which hardens the UNC paths for SYSVOL & NETLOGON & have the following registry keys being pushed using group policy:

• RequirePrivacy=1
• RequireMutualAuthentication=1
• RequireIntegrity=1

Should the UNC Hardening security update with the above registry settings not take care of this vulnerability when processing group policy from the SYSVOL?

A4) 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 (MS16-072 \ KB3163622) is installed

Q5) If we have security filtering on Computer objects, what change may be needed after we install the security update?

A5) Nothing will change in regard to how Computer Group Policy retrieval and processing works

Q6) We are using security filtering for user objects and after installing the update, group policy processing is not working anymore

A6) 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 "read" permissions on the Group Policy Object (GPO). You can add "Domain Computers" group with "Read" 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:

Q7) Will installing this security update impact cross forest user group policy processing?

A7) No, 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.

Q8) 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?

A8) Yes, just adding "Authenticated Users" with Read permissions should suffice. If you already have "Authenticated Users" added with at-least read permissions on a GPO, there is no further action required. "Domain Computers" are by default part of the "Authenticated Users" group & user group policy processing will continue to work. You only need to add "Domain Computers" to the GPO with read permissions if you do not want to add "Authenticated Users" to have "Read"

Thanks,

Ajay Sarkaria

Supportability Program Manager – Windows

Edits:
6/29/16 – added script link and prereqs
7/11/16 – added information about AGPM
8/16/16 – added note about folder redirection

Comments

• Anonymous
  June 22, 2016
  Good article that solves all problem regarding security filtering on policy.The only question is... Why release this kind of article AFTER Microsoft releases the updates?Those updates have cause a lot of problem for all customers that was using security filtering and the section Know Issue on the KB was updated after many gripes in IT Forums even Technet.I think that big companies like Microsoft , have to take more attention on warn customers about "design changing" BEFORE apply them.But maybe I'm wrong...
  • Anonymous
    June 22, 2016
    The comment has been removed
    • Anonymous
      June 22, 2016
      I agree. It's normal release practice for creation of new GPO's to adjust dACL security filtering from "Authenticated Users" to something else. It would of been prudent to provide this article ahead of releasing the fix! This will likely break environments. Changing the underlying behavior of GP Client is a major adjustment.
  • Anonymous
    June 22, 2016
    I completely agree with Simon’s comments. I understand there is a security vulnerability that needs to be addressed. If this was a “by-design” behavior change, Microsoft had to know that it would break GPO processing for many customers. Shame on them. A design change such as this should be communicated prior to releasing the patch.
• Anonymous
  June 22, 2016
  I just run the following PowerShell command, to make sure, all GPOs have the "Authenticted Users" read permission.Get-GPO -All | Set-GPPermission -PermissionLevel GpoRead -TargetType Group -TargetName "Authenticated Users"If "Authenticated Users" has more permissions, nothing is changed. The GPOs that do not have "Authenticated users", will get the read permission.
• Anonymous
  June 22, 2016
  Good article that is sadly late...However, even while following those recommendation I get error "Not Applied (Unknown Reason)" if the user section is empty or the computer section is empty.
  • Anonymous
    June 22, 2016
    Hi Michel,I am not sure I follow your scenario. The GPO name that is listed with the error, can you check what permissions are there on the GPO from GPMC? Please make sure the computer where you see this error has permissions to read the GPO (Domain Computers Group Membership, etc)
• Anonymous
  June 22, 2016
  On all my Filtered GPOS (and I have hundreds) I have always left Authenticated Users as READ and JUST unchecked the "Apply Group Policy". However, WINDOWS would then remove the Authenticate Users entirely from the Security Permissions. This was an extremely annoying bug because even if I don't want specific users to APPLY the setting, I want them to be able to SEE the GPO.Microsoft deploying this hotfix should automatically fix the above bug so we can actually Add Authenticated Users = READ. I have hundreds of RFC's and hundreds of GPOS now to change that should never have needed to be changed IF the bug above had been fixed prior to this KB being released.
• Anonymous
  June 22, 2016
  Great article Ajay. A much needed article for all the confusion it's caused.For anyone interested, I wrote a script to audit and remediate this: http://www.jhouseconsulting.com/2016/06/22/script-to-report-on-and-remediate-the-group-policy-security-change-in-ms16-072-1627Cheers,Jeremy
• Anonymous
  June 22, 2016
  Great article.Can someone tell me what happens, when you have a single GPO, that has both Computer and User policy enabled.Also, in security filtering, "Authenticated Users" removed, and added a custom AD group. In this custom AD group, i have a list of computers and users. Will this work as is? or does it require "Domain Computers" added?Thanks, David.
  • Anonymous
    June 22, 2016
    Hi David, the user group policy processing should continue to work as long as the "computer" where the user is logging on is part of the Custom AD group that has permissions on the GPO.
    • Anonymous
      June 22, 2016
      Thanks Ajay!!So whenever i need to remove "Authenticated Users" group from Security Filtering for User Policy enabled GPO's, i always have to remember to add "Domain Computers" into the delegation. Is there a way to make this a default setting, so whenever a new GPO is created, it will already have "Domain Computers" in the Delegation?David.
      • Anonymous
        June 23, 2016
        There is a helpful article at http://www.gpanswers.com/never-a-dull-moment-with-group-policy-or-what-to-do-about-ms16-072/which has detailed instructions on how to change the default settings for new GPOsJohannes
        • Anonymous
          June 23, 2016
          Thanks Johannes. Thats another handy article!! Cheers. David.
      • Anonymous
        June 23, 2016
        Hi David,"Domain Computers" are part of "Authenticated Users" - So the default permissions on a GPO has "Authenticated Users" added by default which gives "Domain Computers" permissions as well by default. If you remove "Authenticated Users", that is the only time you will need to add "Domain Computers" - Hope this helps!
• Anonymous
  June 23, 2016
  This was not the only security update, there was also one for AD, but the KB article doesn't say much about. Only thing is, that our multi tennant AD now lost all permissions for authenticated users and several Exchange permission on all OUs. Anything about to mitigating this issue? As even the GPO issue can be fixed by adding delegation on GPO, they are not applied cause of missing permissions on OUs now.
  • Anonymous
    June 23, 2016
    Hi Tom, The issues you describe do not seem to be happening because of MS16-072 Group Policy security update. Thanks,MSFT Ajay
    • Anonymous
      June 23, 2016
      Hi Ajay, yes, that's what I said, there was another security update for AD: MS16-081
• Anonymous
  June 23, 2016
  Great article, but still have a question.The ACL changes when changing security filtering when you remove in Authenticated Users in this window.Also when security filtering on domain computer is set and removed these rights disapears.Does someone know about a update for the DC's to solve this issue.Otherwise this will be a pain to maintain if security filtering is an issue.Thxs,Pierre
• Anonymous
  June 23, 2016
  If I removed Authenticated Users from Security Filtering, can I simply add them back under the Delegate/Advanced section with "Read" permissions? This way it doesn't apply the GPO everyone.Or do I always have to add Domain Computers when Authenticated users is removed from Security Filtering?
  • Anonymous
    June 23, 2016
    Hey Scott,Yes, you can just add "Authenticated Users" back with read permissions as Domain Computers are part of Authenticated users. MSFT Ajay
• Anonymous
  June 23, 2016
  Why can it be either Authenticated Users or Domain Computers?I suppose Computer accounts participate in the special group Authenticated Users at logon anyway?
  • Anonymous
    June 23, 2016
    Yes, it is either Authenticated Users or Domain ComputersI will add this to the main blog MSFT Ajay
    • Anonymous
      June 24, 2016
      Thanks!
• Anonymous
  June 23, 2016
  My environment has authenticated users applied from security filtering and not directly on the gpo. I'd that sufficient to avoid the issue or do I need to give domain computers read permissions since the authenticated users are coming from security filtering?
  • Anonymous
    June 23, 2016
    It should suffice MSFT Ajay
• Anonymous
  June 24, 2016
  Very Good article AJ. Thank you very much for the valuable information.
• Anonymous
  June 24, 2016
  This design is wrong, it is completely not initiative, and no one can guess these additional steps.This shows another complete disregard by MS to their clients.You should really make a patch to fix this problem rather then asking the whole world to do all these extra steps for millions of GPOs.No one in it's right mind would think that this is obvious.
• Anonymous
  June 24, 2016
  IF MS change the design, why not reflect this change in the GPMC? The GPMC Console should also by updated that further Policys that are filtered to Users only, are added the Authenticated Users Group write permission by design.
  • Anonymous
    July 11, 2016
    Completely agree, GPMC needs to be updated. By default GPMC should add Authenticated Users with read into newly created GPO ACL's (separate from security filtering).
• Anonymous
  June 24, 2016
  I use security filtering for:1. Ease the load of policy processing, multiple policies applied directly or indirectly to an OU (just like disabling Policy User or computer settings)2. Added level of security resource security settings and policy filtering (does not prevent manual mapping to resource but most users don't have a clue on that one).The downside of this is;1. All user logons will attempt to apply all group policies and their settings even if they do not have permission to them unless we security filter by computer accounts.2. Implementations of resource mapping which have everyone granted permission to the resource can now be accessed just by logging onto another computer that does have permission to the resource mapping policy.3. We have to create additional security groups which contain computer accounts to security filter in addition to the user resource security group.
  • Anonymous
    June 24, 2016
    It seems like this powershell command works fine and could be applied to all GPOs as long as you do not use the -replace switch. It looks like it will add the group in with only read permissions on a GPO. It does not look like it will impact how a policy is applied even if "Domain Computers" is already in the DACL with Read and Apply permissions - Set-GPPermission -All -TargetName "Domain Computers" -TargetType Group -PermissionLevel GpoRead It obviously will not impact the default on the GPOs that get created in the future. I am still testing, but if anyone sees an issue with this let me know.Dan
• Anonymous
  June 25, 2016
  It seems the subtext of this article is almost blaming administrators for removing read permission from "Authenticated Users". But, this is not what happened. I had some GPOs in which it was incorrect for them to apply to all users. I made a change in GPMC where it says "The settings in this GPO can only apply to the following groups, users, and computers" removing Authenticated Users and adding the appropriate security group in order to change who the GPOs apply to. As far as I know, this is/was the 100% supported way to change the apply permission. It was GPMC that removed the read permission when my intention was to change the apply permission.Now I have fixed this in my environment by adding "Domain Computers" with read permissions to all GPOs and I have adjusted the default security applied to new GPOs to include "Domain Computers" with read permission on all new GPOs. I believe the Directory Services Team should make a change so that this second item is standard on new domains. Otherwise admins of new domains will be confused when they try to set up GPOs specific to a subset of users and it doesn't work.
• Anonymous
  June 27, 2016
  Dear Microsoft staff responsible for TechNet articles,Please update the official documentation on how to use security filtering feature on a GPO, since it will not work for user account filters after installing this update: https://technet.microsoft.com/en-us/library/cc752992(v=ws.11).aspxOn this page you still have the following instructions which are wrong:"In order to ensure that only members of the group or groups you added in Step 3 can receive the settings in this GPO, you will need to remove Authenticated Users if this group appears in the Scope tab. Click the Scope tab, select this group, and then click Remove"Of course, I agree with previous comments that this kind of changes in functionality must never again be introduced by publishing a patch, without any previous notice and explanations that the patch is breaking the functionality if administrators follow official TechNet instructions.
• Anonymous
  June 27, 2016
  Hi Ajay, Thanks for this nice article, I have one question --- there are more than 100 + group policy, where we have applied GP on specific users and computers. When we add authenticated users in delegation tab----Automatically Apply group policy will get applied as by default. Once authenticated users added, same time this will get replicated to other AD servers and the users who are part of OU, which the group policy applied and having folder redirection, users might lost the data.
  • Anonymous
    June 27, 2016
    Hi Raviraj,If you have 100+ GPOs, best solution may be to use the script method as mentioned in the blog. Do test fist if that may work better for you.MSFT Ajay
• Anonymous
  June 29, 2016
  I just published a script to modify the defaultSecurityDescriptor attribute on the Group-Policy-Container schema class object: http://www.jhouseconsulting.com/2016/06/29/script-to-modify-the-defaultsecuritydescriptor-attribute-on-the-group-policy-container-schema-class-object-1668Hope people find that helpful.Cheers,Jeremy
  • Anonymous
    July 05, 2016
    Hi JeremyI just saw your past after publish my post. So, I have the same solution to set the defaultSecurityDescriptor to the Group-Policy-Conainer Class but set it manually.
• Anonymous
  July 03, 2016
  While Ajay Sarkaria does speak for Microsoft he's still just a lowly employee of the behemoth. When you exercise all but monopolistic power you do what you what, when you what, how you want, and you justify it so you can sleep at night. "Absolute power . . . ". Just deal with it.
  • Anonymous
    July 05, 2016
    That's true. But one would hope that Ajay does have some level of communication with the team or that someone from the team might actually read our comments.
• Anonymous
  July 05, 2016
  Very good article. We use AGPM and create new policy within AGPM console. Is it an option to change the defaultSecurityDescriptor of the classSChema CN=Group-Policy-Container and add the Group "Domain Computers" to the defaultSecurityDescriptor. I think the security rights should be the same as ENTERPRISE DOMAIN CONTROLLERS. When I create a new GPO in AGPM the group ENTERPRISE DOMAIN CONTROLLERS has Read rights.The additional ACE string should look like that:(A;CI;LCRPLORC;;;DC)Syntax: ace_type;ace_flags;rights;object_guid;inherit_object_guid;account_sidhttps://msdn.microsoft.com/en-us/library/windows/desktop/aa374928(v=vs.85).aspx
• Anonymous
  July 25, 2016
  After installing KB3159398 we've discovered that some of our drive mapping done through Group Policy Preferences are broken, despite the GPO having Read and Apply turned on for Authenticated Users. I've verified the uninstalling the KB allows the drives to map properly. In addition we're seeing a warning message in the System eventlog ID 1112 'The Group Policy Client Side Extension Group Policy Drive Maps was unable to apply one or more settings because the changes must be processed before system startup or user logon. The system will wait for Group Policy processing to finish completely before the next startup or logon for this user, and this may result in slow startup and boot performance.'Given that we have the recommended permissions on the GPO does anyone have any idea how to fix this?
  • Anonymous
    July 25, 2016
    We use drive mapping via GPP in our environment and did not experience this issue. I suggest temporarily turning on tracing and seeing if a more detailed error is logged.https://blogs.technet.microsoft.com/askds/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat/I don't think the message about needing to be processed before user logon signifies anything. That's a normal message that often appears when everything is working correctly.
• Anonymous
  July 26, 2016
  Good article.How would one tackle locked down acls on OU's? All the articles and blogs on how to resolve the permissions pertain to the GPO permissions themselves. What if the computers account doesn’t have permissions to read the OU where the user object resides, i.e. authenticated users have been removed from the OU acl and replaced with a different group on the OU and Authenticated users is not a member of Pre-Windows 2000 compatibility group, the computer account wouldn’t be able to read the OU or gplink so wouldn’t apply the GPO? Giving the computer account (or Domain computers group) read access to the OU would give away the ability to browse/search AD and find the “hidden” objects via the computer account context.Anyone come across a scenario like this?
• Anonymous
  August 09, 2016
  Five hours searching for the solution and finally found thanks to your blog.
  • Anonymous
    August 16, 2016
    After applied June 2016 patches we are getting event id 1030 continously in for cross our domain users (they are login using citrix to access apps and resources)Our infrastructure configuration as bellow. We have one way trust configured with different domian/forest, GPO configured in Domain1. Com and Domain2.Org users login and access domain1.com servers and access apps through citrix. We have configured multiple gpo and authenticated uses added with read and apply policy. As we have configured allow loopback with replace mode not a allow Allow Cross-Forest User Policy and Roaming User Profiles. We also getting multiple 1061 evert in our citrix PVS servers. What we need to change here?
• Anonymous
  August 16, 2016
  After applied June 2016 patches we are getting event id 1030 continously in for cross our domain users (they are login using citrix to access apps and resources)Our infrastructure configuration as bellow.We have one way trust configured with different domian/forest, GPO configured in Domain1. Com and Domain2.Org users login and access domain1.com servers and access apps through citrix.We have configured multiple gpo and authenticated uses added with read and apply policy.As we have configured allow loopback with replace mode not a allow Allow Cross-Forest User Policy and Roaming User Profiles.We also getting multiple 1061 evert in our citrix PVS servers. But users are not facing any license issue. What we need to change here?
• Anonymous
  September 17, 2016
  Do the permissions need to be added before or after the patch? We have not patched yet?
  • Anonymous
    September 18, 2016
    From microsoft : https://support.microsoft.com/he-il/kb/3159398:ResolutionTo 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.Or you can change the script provide in this blog to use " Domain Computers " Read Premissions.https://gallery.technet.microsoft.com/Powershell-script-to-cc281476
  • Anonymous
    September 19, 2016
    For best results, add the permissions before deploying the patch. Having the adjusted permissions on a pre-patched system will not hurt things.
• Anonymous
  October 07, 2016
  I've just spent 5+ hours reading this and related articles while testing the recommended solutions on our Windows Server 2012 R2 Standard server with Windows 7 32bit client workstations. Using a TEST GPO that has both Computer Policies and User Policies, I have concluded the following: 1) With an Active Directory Global Security User Group granted Read+Apply permissions under the GPO's Delegation tab, and Authenticated Users granted Read only (not Apply) permissions under the GPO's Delegation tab (per this aricle), ONLY the GPO's User Policies are applied, not the GPO's Computer Policies. 2) With an Active Directory Global Security User Group granted Read+Apply permissions under the GPO's Delegation tab, and an Active Directory Global Security Computer Group granted Read only (not Apply) permissions under the GPO's Delegation tab, ONLY the GPO's User Policies are applied, not the GPO's Computer Policies. (as expected) 3) With an Active Directory Global Security User Group granted Read+Apply permissions under the GPO's Delegation tab, and an "Domain Computers" granted Read+Apply permissions under the GPO's Delegation tab, the GPO's User Policies are applied to just that AD User Group and the GPO's Computer Policies are applied but to ALL domain computers (unacceptable, need GPO Computer Policies to only apply to those computers used by members of AD User Group). 4) As a result of the findings listed above, there is no way to apply a GPO's User Policies AND Computer Policies to an Active Directory User Group simply by adding that Active Directory User Group to the GPO's Security Filtering (as could be done on previous server editions such as Windows Server 2003 or on this server prior to this article's security update). In other words, I cannot configure any GPO to apply only to an A.D. User Group so that the GPO's User Policies and Computer Policies only apply to members of that specified AD User Group and only to computers used members of that AD User Group. This is unfortunate because members of our AD User Group use various computers onsite and whatever computers they use must have these GPOs applied, both the GPO's User Policies and Group Policies. 5) The best workaround is to create, in addition to the AD User Group, an AD Computer Group that includes all computers that members of AD User Group might use and to grant those two AD groups Read+Apply permission under the GPO's Delegation Tab (causing them to appear under the GPO's Security Filtering). In other words, adding Authenticated Users with Read only permissions under the Delegation tab does not solve the issue; it only enables a GPO's User Policies not the GPO's Computer Policies and adding Domain Computers with Read only permissions under the Delegation tab does not solve the issue because it forces the GPO's Computer Policies to be applied to all computers. Very annoying Microsoft because: a) members of the AD User Group may use any computer onsite so before they use another computer, I have to add that additional computer to the AD Computer Group, b) I do not want the GPO's Computer Policies applied to computers used by users who are not members of the AD User Group but this is unavoidable as a result of having to add a AD Computer Group to the Security Filtering.
  • Anonymous
    October 08, 2016
    The comment has been removed
    • Anonymous
      October 10, 2016
      No. Just grant read access to the Domain Computers group on the Delegation tab. Then on the Scope tab, set up whatever security filtering you need.
      • Anonymous
        October 12, 2016
        Read access to the Domain Computers on the Delegation tab results in the GPO's Computer Profile not running.
        • Anonymous
          October 17, 2016
          After installing the update, we added Domain Computers with read access to all GPOs and the broken ones started working again.But, I went back and re-read your original post and what you wrote is correct. If you apply a user filter, then the computer polices do not apply. It's been like this for as long as I've been working with GPOs. I think your solution for this is a good approach.
• Anonymous
  October 14, 2016
  Niϲe webⅼoǥ right here! Also your site lots up fɑst!What web hoѕt are you using? Can I am getting your affiliate hyperlink in youг host?I wish my web site loaded up ɑs quickly as yours lol