Planning to Deploy in a Demilitarized Zone (DMZ)

Many organizations require both an internal network for corporate assets and a physical or logical subnet that exposes resources or services to a larger, external network, such as the Internet. For security, computers and resources in the external-facing perimeter network or demilitarized zone (DMZ) have limited access to the computers in the internal network. Because communication between the computers in the DMZ and the corporate network is restricted and protected through the use of a firewall, there are specific constraints on configuring authentication and authorization services.

This section describes how to deploy Verify Privilege Server Suite components in specific DMZ scenarios.

Identifying the Computers to Protect

The computers that are most vulnerable to attack are computers that provide services such as e-mail, host external-facing web applications, and manage network routing through Domain Name Servers (DNS). Computers that provide these services are typically isolated from the internal network on their own subnet and allowed to communicate with the internal network through specifically designated channels. This configuration allows computers in the DMZ to provide services to both the internal and external network, but controls the traffic allowed to be routed between the computers in the DMZ and the internal network clients.

Creating a Forest and Trusts for a DMZ

It is recommended that you create a separate Active Directory forest for the computers to be placed in the network segment you are going to use as the demilitarized zone. You should then establish a one-way outgoing trust from the internal forest to the DMZ forest.

Defining a one-way trust allows existing internal forest users to access resources in the DMZ without separate credentials or being prompted for authentication. The one-way trust also prevents any accounts defined in the DMZ forest from having access to the internal network. Accounts defined in the DMZ forest can only access computers inside the DMZ domain. If a privileged account in the DMZ forest is compromised, that compromise is limited to the scope of the DMZ forest.

For Verify Privilege Server Suite, the one-way trust enables you to:

  • Use the internal forest for authentication and authorization services for user accounts.
  • Define computer accounts in the DMZ domain without permission to read data from the trusted domain of the internal forest.

In most cases, you should not use an existing Active Directory domain when deploying Verify Privilege Server Suite Agents in a DMZ. Using an existing domain requires opening additional ports through the internal firewall to allow computers to connect directly to the domain controllers in the internal forest. Allowing computers in the DMZ to connect directly to the internal forest implicitly grants access to resources behind the internal firewall.

Defining Zones for Computers in the DMZ

You should create one or more zones in the DMZ forest and specify those DMZ zones when computers join the DMZ domain. You should also create and manage UNIX group profiles in the DMZ domain. However, you should define user accounts and UNIX profiles for in the internal forest and not the DMZ forest. Defining user accounts in the internal forest ensures that users can use a single password to authenticate across all network resources, including those in the DMZ.

The following figure provides an overview of the basic architecture for deploying Verify Privilege Server Suite Agents when you have computers in a DMZ.

DMZ architecture

To enable authentication for resources in the DMZ, users must have:

  • A valid Active Directory user principal.
  • A complete UNIX profile in one or more zones in the DMZ.
  • A UNIX Login, listed, or custom role assignment that allows access computers in the DMZ.

Creating a Firewall and Securing the Network

You should establish firewall rules that allow communication from the DMZ domain controllers to the internal domain controllers. Other computers in the DMZ, for example, the UNIX servers you want to isolate from the internal network, should have limited access to the corporate network. The most common exception is to allow communication from the corporate network to the DMZ network using port 22.

The client and server port requirements to enable communication through the firewall depend on the Windows operating system you have installed on the domain controllers and the functional level of the forest. For information about the specific ports to open and the services that use the ports, see Microsoft Active Directory documentation, such as How to configure a firewall for domains and trusts.

In addition to configuring a firewall that minimizes exposure to the corporate network, you should remove insecure network protocols, if possible, or replacing insecure authentication programs, such as POP3 and FTP, with Kerberos-enabled programs. These security steps reduce the potential for password exposure and the risk of an account in the corporate domain being compromised.

How to Join a Domain with a Read-Only Domain Controller (RODC)

With Windows Server 2008, you have the option of installing read-only domain controllers (RODC). Read-only domain controllers enable you to deploy a domain controller that hosts read-only partitions of the Active Directory database. Deploying a read-only domain controller enables you to make Active Directory data and reliable authentication services available in locations that cannot ensure physical security required for a writable domain controller.

You can also deploy read-only domain controllers to handle special administrative or application management requirements. For example, you may have line-of-business applications that are required to run on a domain controller, or application owners who must have access to the domain controller to configure and manage operations but not allowed to modify Active Directory objects as they could with a writable domain controller. You can grant a non-administrative domain user the right to log on to the read-only domain controller while minimizing the security risk to the Active Directory forest.

For more information about read-only domain controllers, see the Read-Only Domain Controller (RODC) Planning and Deployment Guide.

To join a domain that has a read-only domain controller:

  1. Create a computer account for the computer in the DMZ that will connect to the readonly domain controller using a writable domain controller as described in Creating computer objects for the target set of computers.

    You can create the computer account using the Access Manager console, an adedit script, or using the adjoin command with the --precreate command line option. However, be sure to create the computer account in a DMZ zone.

  2. Use Active Directory Sites and Services or the repadmin program to replicate the computer account in the read-only domain controller. For example,

    • In the console tree, expand Sites, and then expand the site of the domain controller that you want to receive configuration updates.
    • Expand the Servers container to display the list of servers that are currently configured for that site.
    • Double-click the server object that requires the configuration updates that you want to replicate.
    • Right-click NTDS Settings below the server object, and then click Replicate configuration to the selected DC.
    • In the Replicate Now message box, click OK.

  3. (Optional) Open a Command Prompt and use the repadmin /showrepl command to verify successful replication on the read-only domain controller.

  4. Block the route from the UNIX computer to the writable domain controller, if necessary.

  5. Run the adjoin command with the self-service option. For example:

    adjoin mydomain.local --password c%ntrify --name quad90 --selfserve

    Because you have already created the computer account in Active Directory, you don’t need to specify the zone to join the domain.

Enabling NTLM Authentication through a Firewall

Having a domain controller in the perimeter forest trust the internal domain requires you to open up ports through the firewall. The specific port requirements depend on the Windows operating system version and functional level of the forest. As an alternative, you can use NT LAN Manager (NTLM) authentication to allow Active Directory users in the internal forest to log on to computers in the perimeter forest.

Using NT LAN Manager (NTLM) authentication enables you to have a more restrictive firewall with a one-way forest trust between the perimeter forest and the internal forest. For example, if the firewall prevents you from using the ports required for Kerberos authentication or if you have limited communications between the forests to a specific port, you can use NTLM authentication to pass authentication requests from the domain controllers in the perimeter domain to the internal domain controllers through the transitive trust chain.

This configuration still requires a one-way trust relationship between the internal forest and domain controllers outside of the firewall.

Configuring the Domain Controllers that Allow NTLM Authentication

You can use the pam.ntlm.auth.domains configuration parameter to specify the domain controllers in the DMZ forest that should use NTLM authentication. This parameter requires that you specify the domain controllers using their Active Directory domain names. In addition to setting this parameter, you must be able to map NTLM domain names to their corresponding Active Directory domain names to support looking up user and group information in the cache.

Configuring a Map that Converts NTLM Domains to Active Directory

For Verify Privilege Server Suite to automatically construct this map, it must be a able to send LDAP search requests to the domain controllers in the corporate forest. If the firewall restrictions will block these search requests, you must manually define a topology map that converts NTLM domain names into Active Directory domain names. To manually configure how Active Directory domain names map to NTLM domain names, define entries in the /etc/centrifydc/domains.conf file using the following format:

ActiveDirectory_Domain_Name: NTLM_Domain_Name

For example:

arcade.com: ARCADE
ajax.org: AJAX

You can refresh the list of domain controllers in DMZ forest at any time by modifying the configuration parameters, then running the adreload command.