none
RemoteApp and Desktop Connection URL GPO is applying when Apply Group Policy Permission not set

    Question

  • I have been trying to get this GPO working in a post MS16-072 world, and it's not behaving consistently with all the documentation I can find.

    Basically, I am trying to follow best practice and only add Domain Computers (or even a single test machine for testing) account as Read (and not check Allow for Apply Group Policy in the permissions / delegation tab) and yet it still wants to apply every time.

    I need this work so that I can then use Group Filtering to assign this policy to certain users and groups of users, but until I can get Domain Computers added as only Read, but have it not apply, I am stuck.

    Any ideas?

    Friday, September 09, 2016 3:20 PM

Answers

  • Both - Its linked to a top level OU that has all domain objects, but is using SG Filtering to narrow it down to select user groups.

    I actually got it working now - it seems that the SG membership was not updating unless a full reboot was called so the machines security tokens could be renewed. In testing, I was using gpupdate /force after changing permissions on the policy delegation tab to test differ permutations of settings; but I have now found that anything related to machine tokens takes a full reboot to take affect (or so it seems).

    Tuesday, September 20, 2016 3:25 PM
  • > I actually got it *working *now - it seems that the SG membership was
    > not updating unless a full reboot was called so the machines security
     
    ...or running
     
    psexec -s klist purge
     
    :-)
     
    Wednesday, September 21, 2016 8:00 AM

All replies

  • Hi,
    Please have a try to also add the Authenticated Users with read access in the to the GPO’s delegation tab and see if it works:
    Please see details from:
    http://www.jhouseconsulting.com/2016/06/22/script-to-report-on-and-remediate-the-group-policy-security-change-in-ms16-072-1627
    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Monday, September 12, 2016 3:32 AM
    Moderator
  • If what works? The point is that it IS working and it shouldn't be.

    By all documentation, setting a policy to Read but NOT setting it to Apply in the delegation tab means the policy should NOT be applying, but yet it IS applying. That is the reason I posted.

    I can toggle the policy back and forth between applying and not applying simply by adding the machine account with just Read (and nothing else) permissions on the delegation tab.

    Monday, September 12, 2016 4:46 AM
  • I need this work so that I can then use Group Filtering to assign this policy to certain users and groups of users

    Hi,
    Are you using security filtering function to filter group of users or linking the GPO to OU which contains the specific groups of users?
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, September 20, 2016 1:30 AM
    Moderator
  • Both - Its linked to a top level OU that has all domain objects, but is using SG Filtering to narrow it down to select user groups.

    I actually got it working now - it seems that the SG membership was not updating unless a full reboot was called so the machines security tokens could be renewed. In testing, I was using gpupdate /force after changing permissions on the policy delegation tab to test differ permutations of settings; but I have now found that anything related to machine tokens takes a full reboot to take affect (or so it seems).

    Tuesday, September 20, 2016 3:25 PM
  • > I actually got it *working *now - it seems that the SG membership was
    > not updating unless a full reboot was called so the machines security
     
    ...or running
     
    psexec -s klist purge
     
    :-)
     
    Wednesday, September 21, 2016 8:00 AM