Active Directory Design - Part 1 - Domain Design

I'm breaking out how I designed our AD structure into smaller parts, this is part 1.

When I first arrived here at Tomlinson Zisko, we were using a hybrid network of Novell and NT. I got rid of Novell as soon as I could (and there was much rejoicing...yay) and am now in the process of updating our domain security model from NT to Active Directory (AD).

Here's just a rundown of how the structure has been designed based primarily on best practices as laid out by Microsoft, past experiences and my own feelings as to the best way to go about it.

So first thing I did was figured out the domain structure, which since I'm at a relatively small firm, this was pretty easy. Now most people will go and make their AD domain have the same namespace as their external DNS namespace. In my opinion, this is not the best way to go. I have found that having a separate namespace for internal networks is much better, as you do not need to duplicate nearly as many DNS records on your external and internal DNS servers and there is a much clearer delineation between what is external and what is internal. It just makes administration of your DNS system much more foolproof.

For example, let's say that you are using smallfirm.com for both internal and external DNS. There is a firewall separating your internal and external DNS servers and no one from outside the firm without VPN access can see the internal DNS servers (how else are you going to keep your server/PC names secure?). You add a new webservice outside the firewall. This means that you now must make entries in your external DNS and internal DNS servers. What happens if you forget to make an entry or make a typo in the entries for the internal DNS server? The service will be unreachable by DNS name from inside the firewall. Why? Because your internal DNS servers have to think that they are authoritive for the domain smallfirm.com and so do not talk to the external DNS servers at all.

Now let's take the same example, but instead, use smallfirm.org for internal. Now, you don't need to make any entries at all for that new external webservice on the internal DNS servers, since they are not authoritative at all for the external domain and will look to their forwarders when queried about the external domain.

OK, so now you know why our external domainspace is tzllp.com and our internal (with some overlap of course) is tzllp.org.

OK, so now that I have the toplevel domain figured out, the next question becomes how many domains and subdomains do I need in the forest? The answer for most companies smaller than 1000 people will be one. There are reasons for having multiple domains, even in small organizations, like if there is a legal requirement for it, or if you have a need to have separate domain policies for different systems in the same site. Unlike in NT Domain design, you no longer need to break up domains into geographical areas and since the limit on the number of objects in a domain is HUGE, you no longer need to do it for that reason either.

BTW Microsoft specifies that the best practice is to leave the top level "root forest" domain unpopulated. This is so that changes to the schema for the forest can be better secured and also done without bringing down the domain that the users are in.

I did not do this here, mainly to save on costs and also because in a small network it can be a real administrative pain in the neck. I actually did it at my last job and it greatly complicated the DNS structure and caused some issues.

I should also note, that for most cases, you do not need to break up networks in separate geographical areas into separate domains. This is because AD uses Sites in order to control replication between servers in same domain but separated by slower communication links. Separate domains should be avoided if possible, because if it isn't needed it greatly increases costs as each separate domain needs to have two domain controllers, whereas if the network is just broken down into sites, you just need one DC per site (if that DC fails, user systems can still authenticate to the central DCs over the slow link).

Well, that's about it for domain design for a small to medium size business. Eventually, I'll get into policies and such, which are much more complicated, as well as Exchange and how it affects AD, plus hardware design. Oh and let's not forget any issues that I have run into and what gotchas to watch out for.

Comments

[Phil Renouf]

I agree with the empty forest root in a lot of large AD installations and agree that it has some benefits, but it is no longer a blanket recommendation from Microsoft. In fact they are fairly actively recommending against it now and only bring it up in rare cases.

Nice post though, look forward to seeing your approach to some of the other AD design issues.

Phil