privileges required to enable server as Global catalog

[Graham Turner]

just wanted to sound out the mailing list on the privileges required to
perform this administrative task.

as standard remote site deployment the local DC is being configured as a
Global Catalog server.

the DC is in a child domain of an empty forest root domain.

my spin on this (seem to have been using AD for months but still feel like a
lackie !!) is that forest root domain privileges (enterprise admins / domain
admins) should be required to complete this task given that it is in fact
the attribute of an "NTDSsettings" object which is in the configuration
naming context.

however the observed behaviour is that an account with Domain Admins in the
child domain is able to complete this task.

any views

GT

 

[Cary Shultz [MVP]]

-----Original Message-----
just wanted to sound out the mailing list on the privileges required to
perform this administrative task.

as standard remote site deployment the local DC is being configured as a
Global Catalog server.

the DC is in a child domain of an empty forest root domain.

my spin on this (seem to have been using AD for months but still feel like a
lackie !!) is that forest root domain privileges (enterprise admins / domain
admins) should be required to complete this task given that it is in fact
the attribute of an "NTDSsettings" object which is in the configuration
naming context.

however the observed behaviour is that an account with Domain Admins in the
child domain is able to complete this task.

any views

GT



.

Graham,

While I have honestly never really paid attention to that
this is a good question. I will throw out one piece of
information to you to see if this helps you at all! I
only hope that it does not confuse anyone.

In terms of Active Directory Replication, the Global
Catalog uses the same AD connection objects that the
Domain Naming Context uses. Similar to this fact is that
both the Configuration Naming Context and Schema Naming
Context use the same AD connection objects. Granted, not
at the same time, though!

Also, while it does typically make sense to have a DC \
GC in each remote Site it is not always necessary. You
can indeed have a DC that is a member of multiple Sites.
Naturally, you would have to deal with the WAN bandwidth
limitation - which might not be acceptable! I guess that
it all depends on the number of users in that remote Site
and how things are set up. I find that a Site-to-Site
VPN and Terminal Server in the "HQ" works really well
when you are talking about a very small number of users (
five to 10 ).

Hope that this applies to your question.

Cary

 

[Graham Turner]

Cary, thanks for the post reply.

the design of GC placement at each remote site is borne out of optimization
/ consistency of remote site configuration.

it seems we need to understand the ACL of the NTDSSETTINGS object where i
would guess that it must put child domain ACE's ?

should have checked as was at customer site last night !!

GT