GPO - 'Access denied' after changing a GP setting

[Bobby Digital]

Hi Mike,

 

thanks for your help....

 

The server is the only one in the domain.  Logging on to the console itself is where I noticed the 'access denied' errors (I haven't even tried accessing or modifying the GPO from a computer logged into the domain itself).  I can log onto the domain from a workstation PC that hasn't been rebooted since this whole thing started (I guess seeing as how it doesn't lose it's IP address, it's still able to log onto the domain), but I can't print to a printer listed in the directory, and an authorized DHCP server won't service clients anymore since, I suppose, it can't properly contact the directory.

 

I've tried your suggestion of running 'dcgpofix', with the following results (just the primary output, I'm sure you already know what the utility outputs normally):

 

========================================================================

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

 

C:\>dcgpofix

...

You are about to restore Default Domain policy  and Default domain Controller po
licy for the following domain
<domain name removed>
Do you want to continue: <Y/N>? y
WARNING: This operation will replace all 'User Rights Assignments' made in the c
hosen GPOs. This may render some server applications to fail. Do you want to con
tinue: <Y/N>? y
Unable to open the GPO due to access denied.  Verify that permissions on the fil
e system path C:\WINDOWS\SYSVOL\sysvol\<domain name removed>\Policies\{31B2F340
-016D-11D2-945F-00C04FB984F9}\MACHINE\Registry.pol and the active directory path
 LDAP://<domain & computer name removed>/CN={31B2F340-016D-11D2-945F-00C04FB984
F9},CN=Policies,CN=System,DC=<domain>,DC=<domain>,DC=<domain> are sufficient to modi
fy the GPO.
Access is denied.
Warning: This tool was unable to re-create the EFS Certificates in the Default D
omain Policy GPO
Access is denied.
The restore failed.  See previous messages for more details

========================================================================

 

Since that hadn't worked, I went about removing the domain controller role from the server, using the 'Manage your server' wizards.  The role was removed successfully, and I rebooted the server, and re-installed the Active Directory role, using the same domain name and info as before.  Strange thing is, the 'access denied' errors didn't change or go away, even though, as far as the server was concerned, it was a new domain.  Another thing I noticed, is that the gpt.ini, and registry.pol files do NOT exist, and from what I understand, these are necessary to the domain.  Why would the server not recreate them, along with associated GPO's, and reset the SYSVOL access to default on creation of a new domain?

 

Moving along....

 

I then tried the following:

 

========================================================================

C:\>dcgpofix /target:domain

...

You are about to restore Default Domain policy for the following domain
<domain name removed>
Do you want to continue: <Y/N>? y
WARNING: This operation will replace all 'User Rights Assignments' made in the c
hosen GPOs. This may render some server applications to fail. Do you want to con
tinue: <Y/N>? y
Unable to open the GPO due to access denied.  Verify that permissions on the fil
e system path C:\WINDOWS\SYSVOL\sysvol\<domain name removed>\Policies\{31B2F340
-016D-11D2-945F-00C04FB984F9}\MACHINE\Registry.pol and the active directory path
 LDAP://<domain & computer name removed>/CN={31B2F340-016D-11D2-945F-00C04FB984
F9},CN=Policies,CN=System,DC=<domain>,DC=<domain>,DC=<domain> are sufficient to modi
fy the GPO.
Access is denied.
Warning: This tool was unable to re-create the EFS Certificates in the Default D
omain Policy GPO
Access is denied.
The restore failed.  See previous messages for more details

========================================================================

 

So then, finally I tried this:

 

========================================================================

C:\>dcgpofix /target:dc

...

You are about to restore Default Domain controller policy for the following domain
<domain name removed>
Do you want to continue: <Y/N>? y
WARNING: This operation will replace all 'User Rights Assignments' made in the c
hosen GPOs. This may render some server applications to fail. Do you want to con
tinue: <Y/N>? y
The Default Domain Controller Policy was restored successfully
Note: Only the contents of the Default Domain Controller Policy was restored. Gr
oup Policy links to this Group Policy Object were not altered.
By default, The Default Domain Controller Policy is linked to the Domain Control
lers OU.

========================================================================

 

So although the domain controller restore seems to work, I still get 'access denied' messages when trying to view and/or edit it specifically.  :(

 

I'm also now seeing a new event log message in the 'Applications' event log, namely being the following:

 

========================================================================

Event Type: Error
Event Source: SclgNtfy
Event Category: None
Event ID: 1002
Date:  9/19/2003
Time:  9:14:16 AM
User:  N/A
Computer: <computer name removed>
Description:
Default group policy object cannot be created. Error 80070005 to open GPO Domain EFS Recovery Policy in domain LDAP://DC=<domain>,DC=<domain>,DC=<domain>.

 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

========================================================================

So this is where I am currently.  Nothing seems to be able to fix it, not even a AD role re-install.  I really don't want to have to rebuild this server from scratch, as I had only set this thing up a couple of weeks ago.

 

My questions to you are, after inspecting the above info:

 

1) is it possible to fix this?

2) shouldn't there be some sort of default, basic, access to Active Directory that, in the event of an emergency or catastrophic failure, automatically resets default access levels, similar to what 'dcgpofix' tries to fix but can't? (you would think I would have made a backup, but of course, I'm just learning and so did not do that, and didn't even think to do it)

3) is it possible to copy over the gpt.ini and registry.pol files from somewhere else and put them into the appropriate policy folders to try to circumvent the errors?

4) is there any way to reset the access to the SYSVOL folder, other than trying to use 'dcgpofix'?

5) is there any mechanism in AD that prevents 'lethal' combinations of policies that can cause errors such as this?

 

I'm starting to lean more towards this being an actual misconfiguration-issue-causing-required-file-deletion-with-no-backup, but I find it hard to believe that NOTHING can restore access to, or fix, the required files/folders/info, including, and especially, re-installing AD.

 

If necessary, I will rebuild the server, but I'd really hate to go that route, as it would be more props to Windows 2003 if it can recover from such an error, seeing as how it would save me time, money and effort.

 

Again, thank you for your help!  I hope the above provided info can help you shed some light on my predicament.  Let me know if you need any other info.

 

I really don't like the red X's in my event logs ;) .

 

Bobby Digital

"Mike Treit [MSFT]" <mtr...@online.microsoft.com> wrote in message news:eE11Fwkf...@TK2MSFTNGP11.phx.gbl...

Is this the only DC in your environment? If you set an IPSEC policy, it shouldn't prevent you from fixing the situation if you physically log on to the DC at the console, since you are essentially working locally, not remotely.

 

If you log on to the DC and ensure you are talking to that DC, can you access the GPO at all using a tool like GPMC? Or does that fail?

 

You might try looking at the DCGPOFix utility, which restores the default domain policy to the out-of-the-box settings. It only works on Windows Server 2003, but sounds like that is the OS you are using.

 

See:

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/prodtechnol/windowsserver2003/proddocs/standard/dcgpofix.asp

 

-Mike

 

--
This posting is provided "AS IS" with no warranties, and confers no rights.

 

"Bobby Digital" <m...@here.now> wrote in message news:egFwTOif...@TK2MSFTNGP09.phx.gbl...

Hey there,

I have a W2k3 Enterprise Server running Active Directory.  Yesterday, I
enabled (I may be remembering wrong), an IP policy in the GP to only allow
'Secured' traffic.  Since then I've rebooted the server, and now I get
access denied messages whenever I try to even view the GPO on the server.

How can I fix this?  Can I delete the default Domain Controller and Domain
policies and recreate them without rebuilding the entire server and AD, or
can I get access to the GPO another way to remove that IP policy (I believe
that is the one causing the problem, I did change some other stuff, but
nothing else should have caused this).

Of course I'm getting event's 1030 and 1058 in the System event log on the
server right now stating that access is denied to the 'gpt.ini' file.  I
tried giving the 'Everyone' group full control access to the 'sysvol' share,
but that doesn't fix this.

Any ideas anyone?

Thanks in advance...

[Bobby Digital]

Tried your suggestion and found the files.  I removed them from those locations, after backing them up, and retried running 'dcgpofix'.  No luck, same error.

 

Any other ideas what we might try?

 

At this point, I'm about ready to throw in the towel on this one... I'm thinking about demoting this server and then re-promoting it using a similar, but different, domain name.  If the errors still occur at that point, I'll have to rebuild the server as there probably won't be any potential fix other than that at that point.

 

The policies I had modified were the following:

 

In the Default Domain Controller policy, I modified:

 

Microsoft network server: Digitally sign communications (always) - Disabled (left this one alone as disabled was what I thought I wanted)

Domain member: Digitally encrypt or sign secure channel data (always) - Disabled (was Enabled)

Microsoft network server: Digitally sign communications (if client agrees) - Disabled (was Enabled)

Domain controller: LDAP server signing requirements - None (left this one alone)

 

- there was a couple of other policies here I may have modified but don't remember any others specifically now.

 

The catch here is that not only did I set those policy settings in the Default Domain Controller policy, and here is where my glaring inexperience with GPO's and AD will show, but I also changed the Default Domain policy to match those exact same settings, including the ones I don't remember.

 

Now, for a little background as to why I was even messing with a working domain controller and GPO's... what I was TRYING to fix in this setup was the fact that, from a workstation logging into the domain, I could see the \\<server_name>\c$ share.  From the server, however, anytime I tried to do a \\<workstation_name>\c$ I would get a 'Cannot log on to this computer locally' error (or something similar), and would not be able to see the contents of the share, even though the Administrator's group on the workstation contained Domain Admins, and I was using a Domain Admin account to login to the server.  I figured it had to be a policy issue, and proceeded to modify those settings I mentioned to try to fix the problem.  I thought to myself that it made no sense that the default GPO, which was being pushed to the clients, would disallow showing the contents of their C: drives from the server, but not the other way around, and so tried to fix it using those settings.  Well, I ended up fixing the problem, and can now see those shares both ways just fine, but now have this whole 'access denied' issue to deal with.

 

Any idea which policy that I modified would have fixed the issue I mentioned, so that when I either rebuild the domain, or fix the problem, I can re-set that same policy?

 

Again, thanks for all your help and suggestions!

 

Bobby Digital

 

"Mike Treit [MSFT]" <mtr...@online.microsoft.com> wrote in message news:eJntmHwf...@TK2MSFTNGP10.phx.gbl...

This is a strange error - do you remember exactly what you did to get you into this situation?

 

It seems like re-creating the EFS policy is failing for some reason. The recovery certificate for EFS, as well as the private keys, are actually stored in the user profile for the administrator - you might check to see that you can access the files at the following locations on your DC:

 

%userpofile%\Application Data\Microsoft\SystemCertificates\My\Certificates\*
%userprofile%\Application Data\Microsoft\Crypto\RSA\<sid>\*

 

Note that these are created on the first DC in the domain, when the domain is originally created.

 

If you can't access the above files and locations (note that they are hidden), you might try taking ownership and/or deleting any files there (copy them to a safe place first), then re-try running dcgpofix.

 

If that doesn't help, let me know.

 

-Mike

 

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Bobby Digital" <m...@here.now> wrote in message news:OKUQC8sf...@tk2msftngp13.phx.gbl...

[Bobby Digital]

Well, I'm going to try creating a new domain, with a similar, but different, domain name.  Wish me luck! :p

 

I'll still be looking for an answer as to which policy needs to be modified in order to view administrative c$ shares both ways, so I'll check back later.

 

Thanks!

"Bobby Digital .com>" <quaker666@hotmail<nospam> wrote in message news:ORM7xAyf...@tk2msftngp13.phx.gbl...

[Bobby Digital]

I rebuilt the machine (software wise) and all is ok now... now all I have to figure out is why errors 1058 and 1030 keep appearing, usually every 5 minutes, but sometimes only every 15 minutes (2 x 5 min intervals must have been ok)...

 

Thanks for all your help though Mike! :p

"Mike Treit [MSFT]" <mtr...@online.microsoft.com> wrote in message news:u2BE5x0...@tk2msftngp13.phx.gbl...

Off the top of my head, I don't see how any of the policy settings you configured should have had the effect you encountered. If anything, you were making things less secure, not more so.

 

One other thing you could try is to restore the default domain policy from a different machine. For example, try promoting a second domain controller and run dcgpofix from there.

 

-Mike

 

--
This posting is provided "AS IS" with no warranties, and confers no rights.

"Bobby Digital" <m...@here.now> wrote in message news:%23Te4psy...@TK2MSFTNGP11.phx.gbl...