SolutionBase: Deploying domain controllers in a DMZ

In an ideal world, you'd have all of your servers safely off the Internet. However, Internet applications nowadays sometimes demand access to your network. You can help increase security by putting domain controllers in a DMZ. Here's how.

As applications continue to improve and add more functionality that requires Internet connectivity, and as the business user's need continues to grow for on-demand enterprise anytime and anywhere, security concerns also grow and dominate corporate concerns. This concern can clearly be seen by the many new certifications that companies like Microsoft are introducing to promote security and security awareness. Everything today is about security, and companies are not touching software before examining the ins and outs of how it will be deployed and how it can be secured.

This security frenzy was prompted by the many viruses that have surfaced and have compromised corporate data and information. It is also prompted by 14-year-old hackers from their garage attacking corporations and gaining access to sensitive data.

One of the immediate measures that companies take in order to improve security is to create a DMZ or "demilitarized zone." A DMZ is a perimeter network that isolates the internal network and controls what kind of traffic, if any, is allowed to pass on to the internal network. By creating a DMZ, you limit the amount of damage an intruder can do to just the DMZ. Servers that typically go into the DMZ are servers that need to be exposed to the Internet, such as Web servers and e-mail servers.

The problem

Suppose you have created a DMZ and populated it with servers that are exposed to the Internet, and you have limited access from the DMZ to the internal network to very specific and very closely monitored ports. One of the immediate problems you are faced with is how to authenticate users to these servers. Even better, how do you log in to these servers yourself? Sure, you can log in locally, but most of the applications you have deployed require some kind of directory for authentication purposes.

An example would be a project that your developers and a consulting company are working on; these developers need user accounts in order to log in to your system. Do you create local accounts for everyone? That would be an administrative nightmare and a security concern.

The solution

Different scenarios exist for how to remedy the problem of offering directory authentication for servers and users in the DMZ. For the purposes of this article, we will be discussing Active Directory.

One scenario calls for placing a domain controller in the DMZ to service the servers and users in the perimeter network. This is a viable solution, and can be secured to some extent by denying any direct communication with it from the Internet and by allowing it to communicate only with specific domain controllers in the secured network using IPSec. This, however, still poses a security risk because this domain controller has to be a Global Catalog Server. This means the server must contain every single object in Active Directory and, if the DMZ is compromised, an attacker can then compromise this server and gain access to Active Directory. (This is assuming that you're adding a domain controller in the same forest as your secured network.)

So how do you take a more secure approach to this? Since in Active Directory the forest is now the security boundary, the only way to have a fully secure implementation is to create a separate forest for the DMZ and then create a trust between the internal network forest and the DMZ forest. This trust would allow specific domain controllers in the secured network to communicate with only specific domain controllers in the DMZ. You would use IPSec to encrypt and secure the communication between the domain controllers, or you could set firewall rules for that as well.

Using this method you can allow your internal users to access resources in the DMZ, and you can create user accounts for consultants or administrators that can only use resources in the DMZ. This would negate the need to replicate your company's Active Directory to a domain controller in the DMZ and, if the DMZ is compromised, you're at risk only with the DMZ Forest.

Let's do it!

Before we start, let's outline the steps that need to be completed before we can successfully implement this exercise. There are five steps that need to be completed:

  1. Open certain ports on the firewall.
  2. Create the filter list.
  3. Create the filter action.
  4. Create the IPSec policy.
  5. Assign and activate the policy.

The first step is to open some ports on the firewall to allow for the proper communication and also to allow IPSec to properly function. Depending on your environment and what you are securing, you may need to open application-specific ports or ports that are specific to your architecture. At a minimum, the following ports should be open:

  • Kerberos—TCP 88, UDP 88
  • DNS—TCP 53, UDP 53
  • LDAP—TCP 389, UDP 389
  • LDAP over SSL—TCP 636
  • SMB over IP—TCP 445, UDP 445

For the purposes of this exercise, we'll be using the following machine names and IP addresses:

  • DC-internal—
  • DC-external—

These steps should be completed on both domain controllers. We will display the steps that need to be configured on the domain controller that is in the internal network. You would have to reverse some settings when configuring the domain controller that is in the DMZ.

The filter list

Before you can create an IPSec policy, you'll have to create a filter list and a filter action. A filter list regulates and defines the security between the participating servers. It is responsible for identifying the source computer, the destination computer, and the type of IP traffic that should be encrypted and secured. To create a filter list:

1. Click Start | Programs | Administrative Tools | Domain Controller Security Policy.

2. In the left control pane expand Windows Settings, select Security Settings, and click IP Security Policies (see Figure A).

Figure A

3. On the Action menu, choose Manage IP Filter Lists And Filter Actions.

4. Click Add and type a name for the filter list. For the purposes of this exercise, we'll select DMZ and click Add again, which will launch the IP Filter Wizard.

5. Click Next to bypass the welcome screen.

6. Under Source address, select A Specific IP Address from the drop-down menu. Type the source IP address—in our case it is—and click Next (see Figure B).

Figure B

7. Now, under Destination address, select A Specific IP Address from the drop-down menu. Type the destination IP address of and click Next.

8. Select Any under Select A Protocol Type. Click Next, click Finish, and then click Close.

When creating the IPSec policy on the DMZ domain controller, the source address here becomes the DMZ domain controller's IP address and the destination IP address becomes the internal network domain controller's IP address.

The filter action

A filter action regulates and defines the security requirements of how information is treated from different sources. A filter action can permit, block, or negotiate security.

Permit means that TCP/IP traffic is passed on without interference and is usually used with computers that are not IPSec capable. Block means that IPSec will block any communication with computers that were not explicitly defined in the filter list. The Negotiate Security setting allows you to customize what IPSec will do in different circumstances—for example, when communication is attempted from a non-IPSec-capable computer.

To set up a filter action:

1. From the Action menu choose Manage IP Filter Lists And Filter Actions, and then click the Manage Filter Actions tab.

2. Click Add, and then click Next.

3. On the Filter Action Name page type a name for the filter action—in our case it will be DMZ. Click Next.

4. When the Filter Action General Options window comes up, select Negotiate Security and click Next (see Figure C).

Figure C

5. In the next window, select Do Not Communicate With Computers That Do Not Support IPSec and click Next.

6. On the IP Traffic Security page, select High and click Next (see Figure D).

Figure D

7. Ensure the Edit Properties checkbox is selected and click Finish.

8. On the New Filter Action Properties windows, deselect Accept Unsecured Communication, But Always Respond Using IPSec, and click OK.

9. Click Close.

Create the IPSec policy

Now that we have fulfilled all the requirements, we are ready to create the IPSec policy as follows:

1. From the Action menu choose Create IP Security Policy.

2. Click Next to bypass the welcome screen.

3. In the IP Security Policy Name window, type DMZ. Click Next to continue.

4. Uncheck Activate The Default Response Rule and click Next.

5. Make sure the checkbox for Edit Properties is selected, then click Finish.

6. Click Add, and then click Next.

7. On the Tunnel Endpoint window, select This Rule Does Not Specify A Tunnel and click Next.

8. Under Select The Network Type, choose Local Area Network (LAN) and click Next.

9. In the Set The Initial Authentication Method For This Security Rule window, select Windows 2000 Default (Kerberos V5 Protocol) and click Next (see Figure E).

Figure E

10. Select the filter list created earlier, in our case DMZ, and click Next.

11. Select the filter action created earlier, in our case DMZ, and click Next.

12. Uncheck Edit Properties, and click Finish.

13. Click OK, and then click Close.

Activating the policy

The final step is to assign your IPSec policy and to activate it so that it can start encrypting and securing communications between the designated computers. To assign and activate it:

1. In the right control pane, right-click the IP Security Policy you have created (in our case, DMZ) and then select Assign.

2. Right-click IP Security Policies in the left control pane, and select Refresh.

Safe and secure

By implementing this exercise and by creating a totally separate forest for your DMZ network, you can rest assured that, in the unlikely situation that your network should be hacked, you have sufficient layers of security to shield your internal network where your most valuable information resides. This also makes it very time-consuming for a hacker to sit there and keep pounding at your network in order to crack it. Remember that they are on the clock, too, and the longer it takes them to get in, the more likely they are to be caught.

In my opinion, aside from shutting down your servers, it is extremely hard to stop a seasoned and gifted hacker from getting access to your network, but you can make their attempted hack as difficult and as complicated as possible—to the point where it becomes not worth it for them anymore. Finally, by making it more complex and harder to get in, you separate the seasoned hackers from the wanna-be hackers, which also lowers your chances of getting hacked.