email article printer friendly more resources

Placing an Active Directory in the DMZ
Be careful when creating outward-facing Active Directories.
by Danielle Ruest and Nelson Ruest

Posted April 19, 2004

For This Solution: Windows Server 2003, Active Directory Application Mode, Internet Information Services 6.0, Systems Management Server 2003

Q:
I plan to have a single multidomain forest topology setup using Windows 2003. I set up Active Directory (AD) with an integrated DNS as a root domain (test.local) along with one child domain controller (child1.test.com) in my internal network. I would like to set up one more child domain (child2.test.local) in the perimeter network (our demilitarized zone). I was going to refer to the same internal DNS for my setup, but after reading your article on integrating DNS with AD, I figured out that I should have my own. Can you tell me the steps I should follow (apart from what you said in your article) that are specific to my scenario? I was unsuccessful in setting up one more domain in the external network, and I would appreciate any help on resolving this issue.

— Senthil, South San Francisco

A:
Danielle: Our January 2004 column focused on how to ensure your DNS application partitions would be positioned in the proper domain when staging a multidomain AD forest. Your situation is a bit different.

You need to position the DNS data in the right location, but even before that you should address the issue of creating a child domain in the demilitarized zone (DMZ), especially one that is linked to the internal forest. Be leery of connecting your external AD to the internal one through the use of a child domain because you will have to do a lot of replication through your firewall. This means you must open special ports in your firewall to support AD replication. At the very least, this means opening port 389 for the Lightweight Directory Access Protocol (LDAP) and port 445 for the Remote Procedure Call (RPC) to support AD replication. Even though you can reassign the RPC port, this could lead to a security risk because it creates a direct, trusted connection between the external and internal zones. If someone compromises your external AD, he or she might have access to your internal AD through the parent/child link between your domains.

We recommend you create a separate forest in the external zone that isn't linked in any way to your internal forest. This might be what you wanted to avoid, however. Many organizations want to create a child domain in the DMZ because they want to share accounts between the internal and the external directories or want to replicate data between each directory. You can still do this with separate forests. But first you should consider why you want the external AD. If it isn't for authentication and only for profile generation and management, you might consider using Active Directory Application Mode (ADAM) instead of AD. Windows Server 2003 users can get this lightweight directory tool at no cost (see Resources).

Nelson: ADAM isn't your only solution, though it is a great one. You can still create a separate AD in your external forest and synchronize data or accounts from the external to the internal directory with less risk than with a parent/child domain relationship. This is done through the Microsoft Identity Integration Feature Pack (IIFP), formerly part of the Microsoft Metadirectory Service and now a subset of the Microsoft Identity Integration Server 2003 (see Figure 1). The IIFP is specifically designed to integrate identity data between several ADs or between AD and ADAM. It will support the synchronization of user accounts between forests by taking accounts in one and changing them to contacts in the other; it will synchronize groups between forests; it will synchronize Exchange global address lists between forests; it will synchronize identity information between AD and ADAM; or it will provision users across forests. It's quite a useful tool, and best of all it's free.

Though the IIFP creates a link between the two directories through port number 389 (the LDAP port), it still creates a more secure infrastructure for several reasons. First, it isn't a direct link between your forests (such as a forest trust would create, for example). Second, it is a deferred link because it exchanges information on a given schedule. Third, because users in one forest are only contacts in the other, they aren't security principals. This provides further protection for your internal forest. Note IIFP's two limitations. First, it needs either SQL Server 2000 Standard or Enterprise Edition to store information. Second, it runs on the Enterprise Edition of Windows Server 2003 only.

To set up your external AD, I recommend you take a look at the Microsoft Systems Architecture (MSA) for the Internet Data Center (see Resources). This architecture is based on Windows 2000, but it is specifically designed for secure Internet-facing infrastructures. There is also MSA 2.0, which might be of more use because it is focused on Windows Server 2003 (see Resources).