Active Directory Layout help -- multiple geographic locations, need router/switch/firewall help!

Hi folks...

I'm currently going to be undertaking a project that requires the migration of about 5 domains into one or two, in a single forest.

Currently, we host many websites and have an environment which includes database servers, web servers, load balancers etc. I am a Windows guy, but not a networking guy -- that is to say, I can figure out the Active Directory layout but I need to understand how and where firewalls and routers will be used.

Anyways, here's the jist of the idea.

We have geographic locations A, B, C, D, and E. Locations A & B are production, mirrors of one another (offsite mirror, similar hardware, servers, etc). Locations C, D, and E are internal locations, where people work in the office and may potentially connect to the production environments.

Since the 'hub' of all servers reside at location A (and I'll leave B out since it's a mirror), the idea I was thinking is to place our PDC at location A. BDCs would be placed at each geographic location so that users authenticate to their local server, and the BDCs replicate on their own to the PDC. Let me know if I have anything wrong so far..

Domain A consists of production and 'outward facing' machines. Domain B is internal, with a trust to Domain A. I'm not certain if this is necessary but it will necessitate another domain controller. I was thinking perhaps to have just a single large domain -- tell me if there's anything wrong with this.

So now the problem I face, is how the networks actually connect with one another. My job is to work with our network guy however, I want a good overview before I sit down with him which is why this question is worth 500 points :) To keep the network segmented, what's the best way to go as far as a network for this? I don't know how the firewall should be set up to segment everything. Will I need a router? I want to have production and each geographic location on a separate IP segment ie, 10.10.1.x for location a, 10.10.2.x for B, etc etc.

Anyways, any help is appreciated.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

You're an NT4 man aren't you? As Windows 2000 and 2003 no longer have an PDC or BDC. (Except in NT-mixed-mode where one of the Windows 2000/2003 controllers can act as a PDC to be  backwards compatible with NT4).

Of course there is still one DC master, but it is not referred to as PDC or BDC because you can assign different master roles to different DC's so each DC can become an PDC with a specialised function. For example you can assign the Schema Master role to one of your DC's, and all updates to the LDAP-scheme will be sent to this DC before beeïng replicated to other DC's. The Infrastructure Master-role resembles most to the previous PDC function.

So what does this have to do with your question you might wonder... well, you might want to split those roles between sites A and B and move some roles to C, D or E. But that really depends on how you make your new forrest.

In Active Directory you can define sites. A site can be described as an part of the network that has an slow or dial-up connection to the rest of the network. So this is typically used to seperate geograpic locations. To setup a site, you might want to setup an bridge-end server on each site, with an DC, DNS and several other services (DHCP) running. A nice thing to know is that a site definition is independent of the domains. It is valid for the entire forest. And when you run an Windows 2003 forrest, Microsoft has made it quite easy for you because a single DC can serve multiple domains. So you can run for example 5 seperate domains and have them available on every location even when you have only one DC per location.

You can set site-boudaries and those are typically bound by IP-subnets. When an workstation boots, it will request an IP-address and will probably get the IP-adresses of the DNS servers as well. From this moment, each workstation can find an DC by looking them up in the DNS server. And once the DC is known, the workstation is able to lookup it's own physical location.  

So, now you know that AD Sites and Services are closely related to the physical infrastructure. And that services (DHCP, DNS, AD) are provided locally by one or more servers. However, keep in mind that the bridge-end server is the DC that does the (scheduled) replicating with the master-DC('s).

Another nice feature from AD Sites and Services is that you can setup the network so that every floor in the building has it's own subnet. You connect an AD-site to each subnet and if you give the site an meaningfull name, you can have your employees search for the printers that reside on their own floor or on an peticular location.

Okay, so far for Sites and Services... let's go to the domains.
I would use only one domain as you don't have to worry about the Sites anymore (AD takes care of this). Furthermore you can put the servers in another OU than the workstations so that they get other policies, don't get typical workstation-software installed etc. And, servers usually don't allow domain-users to logon locally or thru remote desktop (the latter with exception of Terminal Servers of course).

The only reason I can think of to keep two domains, is if you have two seperate groups of users, each with their own organisational structure, their own servers and so on. But if you have most of the servers shared between the two groups, you might as well create one domain and two OU's. Then assign permissions to the OU's so that members of Group A cannot acces the dedicated Group B servers and vice versa.

I hope you've got enough information right now, if not, feel free to ask!

Here is one which may be useful for your reference
Security Concerns for Migrations and Upgrades to Windows Active Directory

EXTRACTS from the site...
Most organizations are either at Windows Active Directory or they are contemplating that move now. If you fall in the latter category, you have some decisions to make. You need to decide how you will get from where you are now, possibly a Windows NT domain(s), to Windows 2000 or Server 2003 Active Directory domain(s).

The pressure and work that goes along with moving from one network operating system to another network operating system can be intense. If you are contemplating moving from your Windows NT domain to a Windows Active Directory domain, your situation is not different.

You will be required to make many decisions during your journey. Some of these decisions include:

Will you have Windows 2000 or Windows Server 2003 domain controllers?
Will you run some of each type of domain controller?
What client operating system will you run for the IT staff, executives, and other employees?
How many Active Directory domains will you end up with?
How many Active Directory forests will you end up with?
How will you get from your Windows NT domains to Windows Active Directory domains?
What tools will you use to get to your Windows Active Directory domains?
Are there any security concerns that you need to consider during your move to Windows Active Directory?

It is this last question that is going to focus on in the article. They discuss the primary options for going from Windows NT domains to Windows Active Directory domains. We will then talk about each of the options, focusing on the different security considerations that you need to contemplate. When you are done reading this article, you should be able to pinpoint the key security considerations that you will face along your journey

Other Links
Download Planning for Deployment Documentation for assisting you in your planning

overworkedopsAuthor Commented:
Okay, here are a few questions...

When I add a workstation to the domain, and it's part of site C... how does it know to go to one DHCP server over another? I figure each DC will be a DHCP for a different subnet and physical location.

As far as firewall/router setup... what's the best way to go?

I was thinking it would look something like this...

Workstation -> DC -> Firewall -> IPSEC Tunnel to location A (main DC)

Internally, I don't want the workstations to go thru the router to find each other -- If they are in the same geographic area, I want them on the same subnet so the farthest they have to go is the switch to find something internal. I don't want them bouncing around on the IPSEC tunnel to location A unless they are trying to hit a server there. Obviously I will have exchange servers working the same way the DCs do -- the master at location A, and extras at each geographic location with a replication going across the IPSEC to ensure data is local to the users.

Any other ideas, or questions you can think I *should* be asking? I am not going to be doing the IP work on the routers or switches, so if there's something there you can help me to understand, I'd appreciate it.
The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

overworkedopsAuthor Commented:
Additionally, would there be any benefit in going with two domains? My higher ups always have the notion that having the production environment on its own domain (location A) and then everything else on another domain is somehow safer or more segregated. However I know I would have to create a trust because of the necessity to let users from domain B into the production environment. At least *some* users, not all of them. That's why I like the single domain setup better because it's more integrated. However as I said, the higher ups are arguing for two domains... anything that might make them more right or more wrong? I might be overlooking something so I figured I'd ask.
overworkedopsAuthor Commented:
Another question... if say, Site B becomes infected with a virus or 0 day exploit.. then what type of prevention can there be to stop it from knocking on the door of the rest of the AD?

overworkedopsAuthor Commented:
And here's another... what's the best way to keep the WAN traffic to a minimum? If a user authenticates to a local DC that's great... but if that user tries to access a resource at location A (from location B) is there a way to stop him at the DC level, or will the request propogate across the WAN, to the resource every time? Let's say it's a file server.. if a user tries to access a file server that he doens't have access to, the request (as I understand it) will still traverse the WAN and take up the bandwith.

By default a router does not forward DHCP requests, unless there is an DHCP-relayserver active on the router. Therefore the local DHCP server will be used and you shouldn't be affraid that a host on site C connects to the DHCP server on site D.

I don't know how your inter-site connections are made, but if they go over a public network such as the internet, I would suggest something like:
Workstationsegment -> Bridge-end server -> firewall -> tunnel + DMZ -> firewall -> Serversegment
If you use the internet as communication-network, you might as well setup 3 proxyservers (for example ISA) on the bridge-end of firewall to allow the site to use internet.

If the connections are made using dedicated lines, I would skip one firewall and the tunnel:
Workstationsegment -> Bridge-end server -> inter-site link -> firewall -> Serversegment
This because you can have one have one firewall that protects all the inter-site connections. And even if you plan to have 3 firewalls, you have one single management point from which you can maintain all three of them. So if there is heavy communication on the links (because of an agressive virus-outbreak) you can close all three firewalls immediately, without having trouble connecting to them.  But this is typically something that you should discuss with your network-man.

Then Exchange... First of all, I know *something* about Exchange, but I'm not an Exchange administrator. So do not put to much weight on my opinion here. Probably an Exchange Admin can give you better advice here. Anyway, I can give you a little bit of information.

Depending on the number of users on a site, the inter-site linkspeed and other factors, there are a couple of options you might want to consider.

The first one is placing one Exchangeserver per site. This is usefull when you've got slow lines or when you want to ensure that users on the same site can still send eachother emails even if the inter-site link is down. Also the site is independent of the others, so if site C is having trouble with their emailserver, sites D and E are not affected. But the downsite is that you create a server-segment on every site and that backups should be arranged on site as well.

The second option is to split the Exchange environment into a powerfull backend on A or A/B (depending on the inter-site link of A and B) and several frontends on C, D and E (and A and/or B if there are users onsite). If the bridge-end servers are powerfull enough you can install the frontend there, saving hardware. This way you can backup the entire Exchange environment at once. The downside here is that you rely heavily on your inter-site links. If many people are sending/receiving emails, your links can be jammed as every mail that is read goes over the line.

Last not least we've got the 1/2 domain(s) question again. In my opinion, having 2 domains means much overhead. If you have 2 domains to administer, you need to establish some sort of trust between them, making it hard to manage. Besides it's easy to loose your overview. It will be harder to define the right permissions and it may end up that you or one of your colleages gives out more permissions than a user actually need, just to get rid of a problem.

While in the AD you can 'rebuild' the organisational structure of the company. It is quite some work, but it is often possible. So every (sub-) department can have it's own OU, with its own policies attached. For example, you have the OU's Users, Admins, ServerAdmins, Workstations and Servers.
->Users are only allowed to logon to Workstations, and several restrictions are in place.
->Admins are allowed to logon to Workstations, but without restrictions
->ServerAdmins are allowed to logon to Workstations (w/o restrictions) and Servers.

Now if a user becomes part of the IT department, simply move his userobject from Users to Admins or perhaps even Server Admins.
And if a machine appears to be so important that you don't want ordinary users to logon to that machine, simply move the computerobject of that machine from Workstations to Servers.

If you have two domains, you can also archieve the above, but with a little more hassle. Because if the Workstations are part of DomainW and Servers are part of DomainS, you have to move the computerobject between both domains to promote a computer to server. And it's just the same for the Admin that becomes ServerAdmin. Plus, the workstations in DomainW must allow administration from both: DomainW\Admin as well as DomainS\ServerAdmin. Servers on their part must allow Administration from DomainS\ServerAdmin, but must also grant (the right) access to DomainW\Users. It's possible ofcourse, but it's extra work and you gain nothing.

So what to say to the higher ups? 2 domains have no advantage over a single domain, and it makes it harder for you to keep the overview. It is harder to maintain and therefore less secure than one single domain.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
The AD is just an specialized LDAP database. I don't know if it is possible to write a virus for it. In any case, AD is data, not executable.

But say you have a virus that uses the user-account of a logged-in user to spread itself. In this case the virus can only get to the parts where the user has access to. There it has to wait until someone else with more or other rights picks it up and executes it.

If you're talking about worms, it does not matter how you plan your layout. Either a system is vulnerable or it is not. Worms can be stopped by the firewall in most cases. For example a worm that uses the SQL-exploit, will be stopped if it is unable to access an SQL-serverport.

In any case you need decent up-to-date virus-protection on both workstations as clients. Furthermore you should write an emergency-plan ready which describes several scenario's and the appropriate actions and risks. Have this plan approved by your management, because some actions may include shutting down one or more sites and in worst case the entire business. So if there is a huge outbreak that you could not forsee, you're not only covered, but know what to do and when!

Then your second question... One of the first things to do is to make sure ordinary users cannot browse thru the network. This way they won't find fileservers for which they don't have any drivemappings. If a user bypasses this policy or finds another way to check for fileservers, there's not much you can do about it. But rest assured that the information required to logon to a server is not much. The user probably has an accesstoken already so it will present the token to that server and the server rejects immediately.

However, if the users of site C are in NOT allowed to login to server FS-DE, you might want to stop the filesharing-requests from site C to that peticular server by using a firewall-rule. But keep in mind that nobody on site C (not even the Forrest-admin) will be able to logon to that server without adjusting the firewallsettings. Also be aware that you don't block the entire filesharing port for that site to important servers, as AD-replication (to name one) will  fail. So the DC should be able to contact it's masters at any time.
overworkedopsAuthor Commented:
I think for now, you've definately answered the question :) I'll post a separate one when I need to but this information has been *great*.

Thanks a bunch :)
You're welcome.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Operating Systems

From novice to tech pro — start learning today.