none
GPO 'inaccessible' but all permissions in place

    Question

  • Greetings,

      I have a simple group policy with one user setting. (w2k3 DCs)

      It is linked to the domain and filtered to one user account (removed auth users, added account)

      There is no block inheritance on any OUs

      Waited a day for replication.

      Policy not applied - running RSOP in GPMC and it says the policy is inaccessible.

      Check both the GUID folder within sysvol and the guid object in AD and they both have read permissions set for the targeted user account (which should happen normally anyway!).

      Just for fun, added the computer account to the filter (should not be necessary!). Still inaccessible.

     Any ideas please?

    Thanks

    David Z


    Wednesday, August 03, 2016 11:13 PM

Answers

  • >   It is linked to the domain and filtered to one user account (removed
    > auth users, added account)
     
    Welcome to MS16-072...
     
    • Proposed as answer by Lain Robertson Thursday, August 04, 2016 10:26 PM
    • Marked as answer by David Zemdegs Thursday, August 04, 2016 10:43 PM
    Thursday, August 04, 2016 1:49 PM

All replies

  • Hi David,

    Thanks for your post.

    In my opinion, the problem may be caused by the permission on the group policy container (Every GPO has two components, GPC and GPT. GPT part stored in the file system under SYSVOL share)

    GPT are stored in \\domainname\sysvol\policy (central store).

    GPC part stored in the AD, so you can edit their permissions with ADUC. Enable Advanced Features in the View menu, and browse System\Policies.

    The following post may be referred to for more information.

    Diagnosing why a Group Policy Object is inaccessible

    http://serverfault.com/questions/224357/diagnosing-why-a-group-policy-object-is-inaccessible

    In addition, the Windows server 2003 has stopped support, please update your OS.

    Best Regards,

    Jay


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

    Thursday, August 04, 2016 2:00 AM
    Moderator
  • I mentioned that I have confirmed that permissions are fine but it is still inaccessible.
    Thursday, August 04, 2016 2:01 AM
  • Hi,

    Would you run gpresult /h C:\gpresult.html and post it to us?

    Best Regards,

    Jay


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

    Thursday, August 04, 2016 5:26 AM
    Moderator
  • >   It is linked to the domain and filtered to one user account (removed
    > auth users, added account)
     
    Welcome to MS16-072...
     
    • Proposed as answer by Lain Robertson Thursday, August 04, 2016 10:26 PM
    • Marked as answer by David Zemdegs Thursday, August 04, 2016 10:43 PM
    Thursday, August 04, 2016 1:49 PM
  • Unfortunately I cannot do that as the system belongs to a network that has no internet access. We have hundreds of other GPOs that work just fine with filtering on the same system - it's just a few that seem to go awry. What is even stranger is that we have deleted and recreated the GPOs from scratch and it doesn't seem to fix the problem. So if the permissions on the GPC and GPT are fine then Im assuming that its a bug that cannot be fixed? What else would you look for in gpresult?
    Thursday, August 04, 2016 10:21 PM
  • As Martin alluded to above, you need to ensure Authenticated Users or Domain Computers has Read (not Apply if you have no use for it) rights to the policy.

    If neither one of these is present, you'll get the error you're seeing.

    Cheers,
    Lain

    Thursday, August 04, 2016 10:26 PM
  • That sounds like a bug. IT doesn't explain why hundreds of other filtered policies that do not have auth users read work just fine (as they should). Also, a quick read of the ms16-072 bug suggests a computer account issue but as I stated in my first post that even when I gave the computer account read on the GPO it still did not work.
    Thursday, August 04, 2016 10:39 PM
  • This has been discussed to death in numerous threads.

    The change is not a bug. It's a deliberate design change to mitigate a man-in-the-middle attack. All that's left to really ask is whether you're content to live with this known vulnerability or not.

    Rather than rehashing old points, it comes down to this:

    1. You can perpetually try and avoid the deliberate change by uninstalling this and every subsequent patch that delivers the change.
    2. You can adjust to the new order of things and put either Authenticated Users or Domain Computers back into each policy where user filtering is exclusively used with Read rights (note again: not Apply).

    Just to be clear, this only affects policies where only user accounts can read or apply the policy. Any policy where a computer account can read it is unaffected.

    Have a proper read of the update description, as this change is now present in multiple updates and will only continue to be so.

    Cheers,
    Lain

    • Edited by Lain Robertson Thursday, August 04, 2016 10:51 PM Spelling correction.
    Thursday, August 04, 2016 10:47 PM