Microsoft

SolutionBase: Best practices for creating an Active Directory namespace

What's in a name? For Active Directory and the Internet, it's everything. How you name things determines how network resources are found. Here's how to properly choose the right names for your domains.


In an Active Directory environment, choosing your namespace is much more important that many people realize. The simple act of choosing a name can drastically impact things such as security, ease of troubleshooting, and ease of configuration. Unfortunately, it's impossible for me to tell you which name you should use, because there are trade-offs involved. There is no one namespace that will give you the best of all worlds. In this article, I will discuss these trade-offs and help you understand how to choose a namespace that is right for your organization.

Internal vs. external namespaces
When choosing a namespace for your domain, the first consideration that you will want to make is whether or not you have an external namespace that's already in place. For example, I have a personal Web site at http://www.brienposey.com. In this case, brienposey.com would be an external namespace. For the purposes of this article, I will refer to an external namespace as any domain that's registered on the Internet.

The reason you will want to stop and think about your external namespace is that, the internal namespaces used by Active Directory, like external namespaces, are DNS-based. This means that it is possible (although not necessarily desirable) to use a single name for both an internal and an external namespace. In fact, the most important decision that you will need to make during the process of choosing a namespace is whether you want to use your external namespace internally or not. There are many good arguments both for and against doing so.

Perhaps the best argument for using a single name for both your internal namespace and your external namespace is consistency. You could deploy a root domain that uses your external domain name and then create child domains that are based on that name.

For example, in my own organization, I have two primary domains that I use. One is called test.com and the other is called production.com. I don't actually use my external namespace (brienposey.com) anywhere in my internal namespace. However, that's primarily because at the time I implemented my Active Directory, my external namespace didn't exist and hadn't even been thought of.

Let's pretend for a moment, though, that I had used the same domain namespace for both my external and internal namespace. My root-level Active Directory domain would, therefore, be called brienposey.com. The two domains that I do have could then be linked as child domains beneath the parent domain. The names would be test.brienposey.com and production.brienposey.com. As you can see, having everything fall under a single namespace makes it easy to keep your Active Directory well organized because it's easy to tell just by looking at an object's Fully Qualified Domain Name (FQDN) exactly where the object falls within the Active Directory hierarchy.

If the primary advantage of using a common namespace internally and externally is consistency, then the second advantage has to be ease of deployment. Suppose for a moment that I wanted to host my own Web site and mail server instead of letting my friends at Xpressions Interactive (www.xpressions.com) handle it for me. If my internal domain namespace matched my external namespace, it would be extremely easy to set up a Web site and mail hosting. There wouldn't be any complicated routing or DNS entries to deal with. In fact, if you plan on hosting a Web site yourself, this is one of the easiest ways to do it.

Unfortunately, what having common internal and external namespaces gives you in simplicity and organization, it lacks in security. Think about this for a moment. If you host your own Web site and you use the same internal and external namespace, then you are actually publishing your Active Directory namespace and part of the DNS information on the Internet for anyone in the world to have access to. Obviously, this information is necessary for Internet users to be able to access your Web site or to send you an e-mail message, but hackers could also use the information as a starting place from which to start chipping away at your network defenses.

Right now, I'm sure some of you are saying to yourselves that this is true, but if a firewall is properly configured, then the security shouldn't even be an issue. I wholeheartedly agree; however, having a common internal and external namespace makes firewall configuration and testing much more difficult.

For example, on my personal network, I block all inbound traffic to my domains test.com and production.com. This was easy to set up and there is absolutely no mystery as to what the rule does. My firewall simply knows that if someone attempts to access either of these domains, the traffic is to be stopped, no ifs, ands, or buts.

On the other hand, imagine that I had used the model I discussed earlier in which my domains were named brienposey.com, test.brienposey.com, and production.brienposey.com. In this model, firewall-level security becomes much more difficult to configure correctly.

In this model, I could block inbound traffic to test.brienposey.com and to production.brienposey.com. That's a given. However, I can't simply tell the firewall to block all traffic to brienposey.com. Otherwise, no one would be able to access my Web site or send me an e-mail message. This means that I would have to be much more selective about which traffic I do and don't allow to access the brienposey.com domain.

Again, there is a fairly straightforward answer to this problem. I could simply open the ports used for HTTP, HTTPS, POP3, and SMTP (and any others that might be required). The problem is that, in doing so, you are essentially telling your firewall to allow anyone running these particular protocols to access your root domain. You would have to be extremely careful to make sure that nothing else within your root domain could be exploited through the use of these protocols. Remember that the root domain contains domain controllers that, if exploited, could give away lots of information about the rest of your private network.

In a situation like this, I would strongly recommend using port forwarding at the firewall-level. Port forwarding allows you to designate the forwarding location of any traffic that comes in on a specific port. For example, you could configure your firewall so that any inbound traffic on TCP port 80 is automatically directed to your Web server. This would prevent anyone from being able to explore your private network through one of the allowed protocols.

Designing an effective namespace
Earlier, I said there was no one way to set up a namespace that was clearly better than the other available techniques. In this section, I want to share with you my recommendations for how I would set up a namespace. Keep in mind, though, that the techniques I am recommending aren't necessarily what's best for your company. It's important to do what's best for your own organization rather than blindly following my instructions.

I personally recommend letting someone else host your Web site and mail services. In my particular case, I have a close friend who started a Web hosting service a few years back. Although I could host my own Web sites, I choose to allow my friend's company to do it for several reasons.

For starters, the Web site is completely disconnected from my personal network. If there is a security breach, then the hackers will have broken into a server that's 500 miles away from anything connected to my personal network.

Equally important is that the company that hosts my Web site makes sure their servers have the latest security patches and that all of the data is backed up each night. In my opinion, it's just more secure to hand over your external namespace to a trusted (trusted being the key word here) ISP and allow them to handle all external traffic for you.

Of course, there are situations where it just isn't practical to have someone else host your Web site and mail services. If you require an excessive amount of disk space or total control over the server that's hosting your site, you're probably better off hosting your own stuff. In this case, I recommend designing your Active Directory namespace accordingly.

In a situation like this, I would recommend setting up two separate Active Directory forests. One forest should be used only for externally accessible servers such as Web servers and mail servers. The other forest should contain your private network.

The forest that contains publicly accessible servers should have a single domain into which the publicly accessible servers are placed. Ideally, you will also want a domain controller placed within this domain that does nothing but act as a domain controller. Remember that you should never use a publicly accessible mail server as a domain controller. While I'm on the subject of domain controllers, I should also mention that you will want to have the bare minimum number of user accounts in the domain. You'll probably want an Administrator account and an IUSR_servername account and that's about it.

Finally, the forest with the publicly accessible servers should have a one-way trust relationship with the forest that contains your private network. This one-way trust should be applied so that the domain containing the publicly accessible servers trusts your administrative domain within the private network. Be sure to establish the trust. This will allow users from your private network to maintain servers in the other forest as necessary. Just make sure that you point the trust relationship in the right direction. Also, if you are using a Windows 2003 Active Directory, don't make the mistake of using a federated trust because doing so would establish a transitive trust between forests, which is not a good thing in this situation.

Now that I have explained the logistics of this setup, let's talk namespaces. In this particular case, you would still have an external namespace registered on the Internet. The authoritative DNS for the external namespace should point visitors to your Web site or anyone sending you e-mail to the static IP address used by your Web or mail server.

Once a visitor has acquired the final IP address from a DNS server, the physical location or the server's name is irrelevant, as long as the server is accessible via TCP/IP. This means that you can set up the forest containing the publicly accessible servers to use any namespace that you want. There is no reason why the forest's namespace has to match the external namespace. Since this is the case, I recommend using a generic namespace. For example, since the forest contains a single domain, you might call that domain something like public.com. By mismatching the internal domain name and the external domain name, you are granting access to your Web site but are preventing disclosure of your internal namespace.

Now, let's talk about the forest that contains your private network. This forest is completely disconnected from anything that's publicly accessible, except through a one-way trust relationship. This forest, for all practical purposes, should be considered to be disconnected and secure.

You have some choices to make in designing a namespace for this forest. On one hand, you could go ahead and use the same namespace for your root-level internal domain as you use for the external namespace that you are using as an external namespace. This would allow you to create a nice organized forest structure in which all Active Directory resources are easy to locate. At the same time, though, you would run into the same issues with trying to keep track of the difference between traffic that's intended for your Web site and traffic that's destined for your internal network. It can be done, but it can get confusing.

I personally recommend using a name for your primary forest that reflects your external namespace but doesn't completely mimic it. For example, my external namespace is brienposey.com; so, for an internal namespace, I could use brienposeyinternal.com or brienposey2.com. This would provide my internal network with nice organization while eliminating all confusion.

One common argument against using this technique is that it doesn't leave room for growth. For example, what if you wanted to someday add a mail server to the domain. You would want that mail server to reflect your external namespace so that it could send and receive e-mail with the outside world.

Believe it or not, this isn't as big of a problem as you might think. As I mentioned before, my private network has two primary domains: test.com and production.com. I have an Exchange Server set up in production.com.

The way it works is that inbound messages follow my external namespace to my Web host. My Web host has an Exchange Server that receives all of my inbound mail. I then use a program called MailEssentials from GFI to have my Exchange Server download all of my inbound mail directly from my ISP's server. The software mimics each mail client, downloads messages separately for each user, and places mail into the appropriate mailboxes on the local server. The users receive the messages as though they were sent directly to my Exchange Server.

The other half of the puzzle was to configure Outlook and Exchange to reflect my external namespace instead of my internal namespace for outbound mail. This makes it possible for people to reply to messages that I have sent. My point, though, is that you don't have to be limited just because your internal and external namespaces are different.

Editor's Picks