AD Forest Design issues

chrisdodds

Weaksauce
Joined
Nov 11, 2005
Messages
71
I have an Active Directory design quandary that I'd like some input on.

I recently started working for a PC manufacturing company at one of their remote sites. The current AD topology is a single forest with a single root domain.

We are hoping to resolve some political "sharing" issues with the HQ IT staff and achieve some autonomy while maintaining single-sign-on access to domain resources and not creating a beast of complexity. We'd like to be able to manage our own user accounts and internal resources without having to request every single network/AD change we want to make from the main office. They don't really like helping us, and we don't like asking them for help, but oh well. I've been researching a couple of options.

Option 1. is to create a new child domain in the existing AD forest.

Option 2. is to create a second forest with trust relationship to the first forest.

A new child domain is the easiest of the two, but I'm not sure if it will give us the separation that we are wanting. Am I correct in thinking that a member of the "Administrators" group on the child domain will only be able to function as a domain admin within the child domain and not the root domain?(this is what we are wanting)

Forest to Forest resource sharing is not something I've dealt with a lot. I know what it involves for the most-part as far as configuration goes, but I've not implemented it before. I've only dealt with it where it already existed. This option seems like it would provide for better separation, but would make resource sharing a lot more complex to configure. I'm trying to follow the KISS principle so I'm veering away from this option right now. Does anyone have any experience with doing this, and if so, any common issues?

Any input would be great. Thanks in advance.
 
I would go with a child domain. And you are correct, as long as admins are "domain admins", they can only adminster their respective domain. If they're members of the enterprise admin group, then they can administer the entire forest.
 
a child domain would work well for something over a "high-speed" (500k) connection. if it is a seperate building, you could almost create another site instead of a child domain.
 
You should create another site for separate locations not going over LAN connections (10+ Mbps).
 
Best practice would tell me you should reorg your OU structure and delegate permissions. Needing a 10+Mb connection to remote sites rediculous. We have over 10 sites some with very small <1.5Mb WAN connections. You should never create a seperate forret or domain unless you absolutely have to. learn to delegate and it will reduce your administration fuctions and simplefy your AD structure.
 
I too would recommend another site and a reord of your OU structure as this will limit trafic accross the slow wan link and if I can remember correctly you can also schedule AD replication.
 
Thanks for the input everyone. I'm glad someone brought up using a new site, because I completely got off on my forest vs. child domain tangent and somehow completely ignored it as an option.

Yay for saving me from more work.

Thanks again
 
Doing the delegation by site and OU will also save you $$$ instead of creating a whole new domain which opens a can of worms.

Remember when you ask for "major" changes to include the cost factor which in this case is a few man hours to change the current AD structure.
 
oakfan52 said:
Best practice would tell me you should reorg your OU structure and delegate permissions. Needing a 10+Mb connection to remote sites rediculous. We have over 10 sites some with very small <1.5Mb WAN connections. You should never create a seperate forret or domain unless you absolutely have to. learn to delegate and it will reduce your administration fuctions and simplefy your AD structure.

I believe you didn't read the key word in my post.

You should create another site for separate locations not going over LAN connections (10+ Mbps).

Anyways...

Creating OU's with delegation is the easiest way, but you don't get as much autonomy. You therefore have to consider child domains vs. delegations.
 
Axeldoomeyer said:
...if I can remember correctly you can also schedule AD replication.
yup, you can schedule how often AD replicates
 
Back
Top