Permissions to GPO for Enterprise Domain Controllers
Will
selecting either Default Domain Policy or Default Domain Controllers Policy:
"The Enterprise Domain Controllers group does not have read access to this
GPO...."
c:\windows\sysvol has as one of its permissions:
Enterprise Domain Controllers Read and Execute
I could certainly force this permission to populate from the root of sysvol
on down to the subfolders, but I don't want to do that until someone here
assures me that Microsoft doesn't tinker with the permission list on some of
those child nodes.
If the above is just a known bug, then I would like to know that. I can
also go check the actual folder with those policies if someone guides me to
it, but I suspect that everything is just being inherited from the parent
ACL.
--
Will
Roger Abell [MVP]
news:89ydnfHOyNZyDqvb...@giganews.com...
> Lately when starting GPMC against our GPO, I am getting the dialog when
> selecting either Default Domain Policy or Default Domain Controllers
> Policy:
>
> "The Enterprise Domain Controllers group does not have read access to this
> GPO...."
>
Have you done this via GPMC ?
It usually will attempt to autocorrect permission deficiencies for you,
upon your consent at prompt.
> c:\windows\sysvol has as one of its permissions:
>
> Enterprise Domain Controllers Read and Execute
>
It is actually the specific policy folders that you need to be looking at.
You will notice that permission inheritance is reset at the directory
you have named, and again at its subdir sysvol\<domain>\policy,
and again at each policy directory under that.
> I could certainly force this permission to populate from the root of
> sysvol on down to the subfolders, but I don't want to do that until
> someone here assures me that Microsoft doesn't tinker with the permission
> list on some of those child nodes.
>
Notice that each individual policy directory blocks (or rather does
not enable) inheritance of permissions from its parents.
The per policy directory NTFS permissions are each potentially
unique as this carries delegation grants.
I do not know where you are in testing out intro of W2k3 into W2k
forest, but you may find interest in "adprep /domainprep /gpprep"
area's comments in
http://support.microsoft.com/kb/324392
The following is older, but does detail some of the "standard" grants
used in the sysvol tree. Notice also how tweaking Bypass traverse
user right can impact things, and how Enterprise Domain Controllers
(EDC) actually has its grant at some levels via Authenticated Users.
http://support.microsoft.com/kb/290647/
The KB does not mention, but similar issues result if one has tweaked
the Access this computer from the network (later: Logon over network)
user right to remove Authenticated Users or otherwise fail to provide
for the DCs of the forest (aka EDC group).
> If the above is just a known bug, then I would like to know that. I can
> also go check the actual folder with those policies if someone guides me
> to it, but I suspect that everything is just being inherited from the
> parent ACL.
>
default GPOs, to locate in dirs:
Default Domain Policy
31B2F340-016D-11D2-945F-00C04FB984F9
Default Domain Controllers Policy
6AC1786C-016F-11D2-945F-00C04fB984F9
You probably need to check the specific policy folders, and also
keep in mind that sysvol stores only part of a GPO (the gpt) with
the other portion (gpc) being stored in AD. You can find the latter
in AD Users and Computers if you enable Advanced view and
look in the System container.
Roger
Will
news:udp05n7i...@TK2MSFTNGP05.phx.gbl...
> "Will" <weste...@noemail.nospam> wrote in message
> news:89ydnfHOyNZyDqvb...@giganews.com...
>> Lately when starting GPMC against our GPO, I am getting the dialog when
>> selecting either Default Domain Policy or Default Domain Controllers
>> Policy:
>>
>> "The Enterprise Domain Controllers group does not have read access to
>> this GPO...."
>
> Have you done this via GPMC ?
> It usually will attempt to autocorrect permission deficiencies for you,
> upon your consent at prompt.
How do I attempt to correct permissions in GPMC? I don't see a permissions
function in the menus. After getting the notification about Enterprise
Domain Controllers being denied access, there was no offer to correct this.
>> c:\windows\sysvol has as one of its permissions:
>>
>> Enterprise Domain Controllers Read and Execute
>>
>
> It is actually the specific policy folders that you need to be looking at.
> You will notice that permission inheritance is reset at the directory
> you have named, and again at its subdir sysvol\<domain>\policy,
> and again at each policy directory under that.
I see, and thanks on that.
First, for Domain and Domain Controller default policies, we had inheritance
turned on. Probably that was a legacy thing from some system administrator
who foolishly forced inheritance from the root down to all children. I
went ahead and removed inheritance.
Then, on observing that that resetting permissions I was still getting the
errors, it occurred to me that we have in our ACL the following suspect:
ANONYMOUS LOGON DENY ALL
GUESTS DENY ALL
I removed both of those, but I still get the error.
DOMAIN1\DenyAccessGroup:(OI)(CI)N
BUILTIN\Administrators:(OI)(CI)F
NT AUTHORITY\Authenticated Users:(OI)(CI)R
DOMAIN1\Domain Computers:(OI)(CI)R
DOMAIN1\Domain Controllers:(OI)(CI)R
DOMAIN1\Domain Users:(OI)(CI)R
DOMAIN1\Enterprise Admins:(OI)(CI)F
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)R
<Account Domain not found>(OI)(CI)R
NT AUTHORITY\SYSTEM:(OI)(CI)F
The "not found" entry is Server Operators! Very strange I removed it and
then added it back again, and once again CACLS still barfs on it as above.
So with the above entries - rather explicit and overspecified as we tend to
do here - I don't see why GPMC thinks Enterprise Domain Controllers do not
have access to this GPO. Perhaps ENTERPRISE DOMAIN CONTROLLERS need entry
into the Bypass Traverse Checking security policy?
> I do not know where you are in testing out intro of W2k3 into W2k
> forest, but you may find interest in "adprep /domainprep /gpprep"
> area's comments in
> http://support.microsoft.com/kb/324392
Not there yet, but it's useful to know that ADPREP has been enhanced since
we used it a year ago on a test domain.
> user right to remove Authenticated Users or otherwise fail to provide
> for the DCs of the forest (aka EDC group).
Originally we did remove authenticated users and overspecify the DACL with
every entity we thought had a legitimate claim to access the sysvol.
Later we moved to the design of allowing authenticated users and also
explicitly allowing access to known entities (just as a form of
documentation). We also added the explicit deny to anon and guests, again
more for overkill than any real need. We add those denies on the theory
that GPO is pretty fragile and someday might break and accidentally populate
a permission to allow anonymous connections as part of Everyone group, and
we just like to have a second line of defense against that.
> default GPOs, to locate in dirs:
>
> Default Domain Policy
> 31B2F340-016D-11D2-945F-00C04FB984F9
>
> Default Domain Controllers Policy
> 6AC1786C-016F-11D2-945F-00C04fB984F9
Thanks for saving me the time to look that up.
> You probably need to check the specific policy folders, and also
> keep in mind that sysvol stores only part of a GPO (the gpt) with
> the other portion (gpc) being stored in AD. You can find the latter
> in AD Users and Computers if you enable Advanced view and
> look in the System container.
This was new for me. I went ahead and added ENTERPRISE DOMAIN CONTROLLERS
with Read access on this System object. That didn't change anything. I
do note that the child objects did not inherit their permissions from the
System object, so perhaps some of those need ENTERPRISE DOMAIN CONTROLLERS
as well.
--
Will
Roger Abell [MVP]
have only seen a GPMC launch of the GPO editor popup message
that "permissions are incorrect, click here to have this corrected"
which it then does.
It looks like you clipped the parts about network login and bypass
traverse user rights, although you mentioned the last. Verifying
that those are allowed to EDC group or equivalent is needed.
ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)R
surely does appear to allow for read, and the failure to
show the display name for Server Operators is troubling.
I do not know if adprep /domainprep /gpprep could be used
to ONLY impact the gp permissions - sounds that way.
I did spot check and the perms listed in the KB do appear
to be the perms in effect on the system ckecked, except for
additionals that delegate policy edit.
Roger
"Will" <weste...@noemail.nospam> wrote in message
news:YM6dnXkKvNJncqvb...@giganews.com...
Will
> ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)R
> surely does appear to allow for read, and the failure to
> show the display name for Server Operators is troubling.
Is there any problem caused by the fact that ENTERPRISE DOMAIN CONTROLLERS
is not showing as a domain artifact?
For example Enterprise Admins is showing as a domain group:
DOMAIN1\Enterprise Admins:(OI)(CI)F
But ENTERPRISE DOMAIN CONTROLLERS is not showing as a group in the domain:
NT AUTHORITY\ENTERPRISE DOMAIN CONTROLLERS:(OI)(CI)R
--
Will
Roger Abell [MVP]
"Will" <weste...@noemail.nospam> wrote in message
EA is a domain global for forestroot domain
EDC is a built-in, aka well-known
Part of the difference is that human can manage membership of EA,
but OS manages "membership" of EDC. I use "membership" as it
is not so much a group as it is a SID placed into token of its "members"
(something also done for true groups).