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

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!

Hi,

Here is one which may be useful for your reference
Security Concerns for Migrations and Upgrades to Windows Active Directory
http://www.windowsecurity.com/articles/Security-Concerns-Migrations-Upgrades-Windows-Active-Directory.html

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).

Introduction
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
http://download.microsoft.com/download/4/a/2/4a28d2bb-2916-43a6-9c88-a819d3bfa70f/03_CHAPTER_1_Planning_for_Deployment.doc

http://labmice.techtarget.com/windows2000/deployment/deploymentguides.htm

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.

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.

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?

Thanks!

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.

Thanks!

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.

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.