6

I have a Windows Server 2003 domain. One of the Group Policy Objects appears as a linked item in an OU but all I can see if the Unique ID and that the Link Status is Enabled. There is a red minus icon next to it and its name reads "Inaccessible." The message says "This Group Policy object (GPO) is inaccessible because you do not have the read-level permission on it."

There is a folder in SYSVOL that contains the Unique ID and I can browse into it without any trouble. If I view the complete list of Group Policy Objects I can't find anything that resembles this inaccessible GPO.

If I run Group Policy Results wizard against a user that the Inaccessible policy applies to then I'm able to see the real name of the GPO and see all the settings that are being applied to the user from the GPO.

What may have happened which would cause an administrator to lose almost all access to a GPO and can the access be restored?

Andrew S
  • 508
  • 3
  • 7
  • 12

6 Answers6

8

The permission on the Group Policy Container (the GPC, an Active Directory object) has been set to deny your read-level permission. The permissions on the filesystem object you've found (the "Group Policy Template", or GPT) can "come out of sync" with the permissions on the Active Directory object. (For some background, have a look at http://msdn.microsoft.com/en-us/library/aa374180(VS.85).aspx).

Fortunately, you can use a tool like ADSIEDIT to restore the permission on the GPC. Using ADSIEDIT you'll find a "groupPolicyContainer" corresponding to the GUID of the problematic GPO under the "CN=Policies" object of the "CN=System" object in the Domain NC of the domain the GPO resides in. (Install ADSIEDIT from the Support Tools on the Windows Server media, open it, drill into "Domain", then "CN=System" and "CN=Policies" and you'll find the GPC).

Using the "Security" tab of the "Properties" sheet for the GPC corresponding to the problematic GPO and use the "Default" button in the "Advanced" dialog to restore the default permissions.

If ADSIEDIT won't allow you to modify the permissions (probably displaying an oddball error message like "An invalid directory pathname was passed"), then likely someone placed a "Deny / Full Control" permission onto the object. The dsacls command with the arguments CN=GUID-OF-THE-PROBLEMATIC-GPO,CN=Policies,CN=System,DC=your,DC=domain,DC=com will report the permissions. Search for the errant "Deny" and "FULL CONTROL" entry and use the /R user-or-group-namme parameter on dsacls to remove the permissions associated with that user or group. If it's really messed up then you'll probably have to use the Windows Server 2008 ADAM / AD LDS version of dscals with the /takeownership argument to take ownership of the object).

pat o.
  • 1,949
  • 1
  • 16
  • 28
Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • This ended up being our problem. We had changed the security filtering from 'Authenticated users' to a security group. It seems that whenever we did this that the GPO then because inaccessible. We were using the GPO to map a drive for specific users in that security group. Instead what we did is change from using the security filter section to using item level targeting on common tab of the drive mapping object in the GPO. – yougotiger Jul 14 '16 at 16:12
  • 1
    If this started happening out of the blue you likely ran afoul of the new "feature" that causes the computer to read GPOs on behalf of users: https://technet.microsoft.com/library/security/ms16-072 – Evan Anderson Jul 14 '16 at 16:50
  • We figured it was something like that, we had released patches for the desktops the night before and came in to the issue in the morning. Figured that they patched a vulnerability that had been working in our favor till they fixed it... – yougotiger Jul 14 '16 at 19:04
  • @EvanAnderson this just started happening to me. We were using Security Filtering to apply a policy to a Security Group and now the policy is showing Inaccessible. Do the steps above still apply if I have run afoul of this new "feature"? – Kevin Morse Jul 20 '16 at 06:28
  • @KevinMorse - Follow Microsoft's guidance in the article I linked in my comment above. The answer above is from 2011 and isn't related to the MS16-072 behavior changes. – Evan Anderson Jul 20 '16 at 07:56
3

Alternatively login with a brand new user account setup as an Enterprise/Domain admin/other administrative group which does still have access to the GP, then open GP Management and reset the permissions for the users which get the "Inaccessible" error.

user204474
  • 31
  • 1
1

Just an addition to Evan's great answer, that you can find the GUID of the parent policy in Group Policy Manager. Choose the policy, go to the Details tab and look for Unique ID. From there, you can drill down to the exact policy component you are looking for, if you had specified permissions further down the policy.

user128688
  • 51
  • 1
  • 3
1

I had the same issue and discovered I had forgotten I targeted the GPO to a specific security group using "Security Filtering" tab in the group policy. Change this to Authenticated Users and the message disappeared!

Wichard Hartes
  • 41
  • 2
1

Sputnik is right. My GPO stopped working. I had my GPO's security filtering targeting a security group I created. When running it against the simulation via GPO management console it would fail with "inaccessible". Easy fix is to add domain computers as a delegate for the GPO and give it Read access rights.

https://support.microsoft.com/en-us/kb/3163622

user375618
  • 11
  • 1
0

Just add Domain Computers group to the security filter. Original Authenticated Users group does include all computer accounts.

Sputnik
  • 1