AD 2003 - Empty root or Not!

[Guest]

Guys,

I'm trying to bottom out the definitive answer to creating a dedicated root
domain OR not…

Having an empty root domain seems to be AD / Win 2000 design best practice,
however since 2003 the idea appears to have faded away..

I'm looking at creating a pristine forest for the migration of 4 MUD's (2200
users approx..) and a couple of Exchange 5.5 sites.. The organisation is
largely centrally managed by a 3rd party however has a few in-house teams
responsible for their own Wintel systems..

So, for my new pristine forest should I go for a dedicated root (which will
in turn will be namespace root for subsequent children domains, which I plan
only to create one). Hardware costs aside, (the cost of 2 low end servers)
what else is holding me back? Right now I see it as a sensible step to secure
the EA and Schema forest wide groups…

If I didn't go for a dedicated root (as I've read a few people are starting
to do) how should you secure the forest wide groups? OR is the back to the
point that your Domain Admin group should contain few users and you delegate
control over OU's for specific functionality!

Comments and thoughts would be most appreciated!

Mikey.

 

[Glenn L]

Its a good question. I don't even know where I stand on this one anymore.

Pros
Seperates the sensitive enterprise admin and schema admin groups from the
rest of the forest.
Provides a convenient placeholder domain to move objects into and out of
during migration and restructuring activities.
DNS namespace politics. lets say you are contoso.com and you aquire
nwtraders.com (notice I have been trolling practice exams lately ;-)
I suspect the nwtraders.com executives would raise an eyebrow if they were
to be migrated into nwtraders.contoso.com child domain.
If you had a placeholder root domain....lets say corp.com
Then you would have contoso.corp.com, and you could migrate nwtraders into
nwtraders.corp.com Nice and pretty right.....

Cons
You must maintain 2 computers and 2 Windows server licenses.
forest wide sensitive groups in a production domain. Future divisions that
may require domains of their own may be adverse to that level of trust in
your domain administrators.
DNS namespace managment.
Take my example.
As an alternative to nwtraders.contoso.com, you could create a new tree in
the forest called nwtraders.com (actually it would have to be slightly
different to get trusts setup and to use ADMT to perform the migration)
Now you have two seperate namespaces you must manage and setup properly to
create seamless name resolution throughout your forest.
Of course it is possible to setup multiple tree roots even if there is an
empty placeholder root domain. I can't think of a good reason to have that.

my 2c

 

[Guest]

Cheers for you comments.. It's a interesting one..

Having a generic empty root is a cool idea for future acquisitions / changes
etc but raises the issue of arguably over complicating the AD design.. I want
to keep things simple and have a contiguous namespace etc.. Future
acquisitions could be handled via forest trusts etc...

The only real advantage (which is a valid one - but I would like some more
thoughts) of a dedicated root therefore is to segregate the EA / Schema
forest roles from other admins etc…

More thoughts and comments welcome!

Mikey.

 

[Guest]

Mike,
I would always have an empty forest root domain which is not visible
externally. For example: forest root domain = nwtraders.local
Then create a new domain in that forest for your resources & users which you
may or may not want to be visible externally. eg: nwtraders.com
This way you have the security of the empty root domain, but still have
"(e-mail address removed)" etc.
Iain

 

[Glenn L]

In regards to your enterprise level groups concerns.
The main problem imho is that anyone in the domain administrators group (in
the forest root domain) can elevation their privelegs and add themselves to
the enterprise admins and schema admins groups.
Forest wide operations like sites and subnets, replication topology and
control, DHCP and RIS authorization, Schema mods, etc
There is nothing you can do to prevent this. These groups are just objects,
and domain administrators implicitly own all objects.
If you set an explicit deny, then another administrator can take ownership
of the object and grant herself permissions.


You can eliminate this risk by having a dedicated empty root domain.
You can minimize the risk by having as few domain administrators as
possible, and make use of delegation.