Hosting AD RMS Servers with Domain Controllers in a Perimeter Network

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2

You may not want significant communication between internal domain controllers (DCs) and the Active Directory Rights Management Services (AD RMS) server and database servers in the perimeter network that are required to support licensing. The compromise of a server in the perimeter network can potentially lead to the compromise of more critical, internally located servers, such as domain controllers. Therefore, significant care must be taken to secure and protect the servers in the perimeter network.

This need can be reduced by placing a domain controller (in particular, a read-only domain controller) in the perimeter network that has the AD RMS servers. While it is ordinarily not a best practice to put domain controllers in the perimeter network because of their sensitive nature, the risks imposed by doing it are not significantly greater than the risk of opening all of the ports that are used by Active Directory between the perimeter network and the internal DCs.

The following diagram shows a single AD RMS cluster in a perimeter network, with a domain controller for the internal domain.

This solution can also be applied for the case where a licensing-only cluster is located in the perimeter network, as shown in the following diagram:

You must consider that in order to keep the DCs in the perimeter network up to date, replication must be enabled between these DCs and internal DCs. While the number of ports and protocols needed for replication are fewer than those needed for full client–to–domain controller connectivity, and these ports are needed only between the DC located in the perimeter network (which is not intended to receive incoming communication from the Internet) and the internal DCs (instead of an architecture where the AD RMS servers, which do receive traffic from the Internet and are therefore more exposed to attack, must communicate with the internal network), there is always some risk. This risk can come from software vulnerabilities, management errors, and so on.

In order to reduce these risks, Windows Server 2008 enables you to use a read-only domain controller (RODC). An RODC is a domain controller whose database is read-only, that cannot perform directory write operations and that cannot perform outgoing replication. In the case of compromise or damage to an RODC, the changes are not propagated to other domain controllers, significantly reducing the risk of placing a DC in the perimeter network. Additionally, a reduced set of credentials (those of users explicitly enabled to authenticate through the RODC) can be replicated to the DC, and those that are so configured are replicated only when they are authenticated through the RODC. This reduces the security and management impact in cases of compromise.

An additional advantage of an RODC is that, because directory-services replication with a read-only domain controller is unidirectional, the firewall ports that are used for directory replication need only be opened from the internal network to the perimeter network, and not from the perimeter network to the internal network.

The RODC can also be configured as a read-only DNS (RODNS) server, with similar characteristics, reducing the need for DNS traffic sent from the AD RMS servers in the perimeter network to the internal network.

This solution presents some advantages. Among them are the following:

  • The internal firewall can be configured to allow for only communication through port 80/443 to the AD RMS servers and to enable directory replication traffic (between the DC in the perimeter network and the internal DCs). In addition, no ports must be opened between the AD RMS servers or the database servers and the internal DCs.

  • No significant load is imposed on the internal firewall, and AD RMS imposes no load on the internal domain controllers.

  • No server that can be accessed from the Internet has access to the internal network, presenting an additional layer of defense against external attacks.

When you use an RODC in the perimeter network, you can obtain additional advantages:

  • Active Directory replication ports have to be opened at the internal firewall only from the domain controllers in the internal network to the RODC in the perimeter network.

  • Only regularly used credentials from a set of allowed credentials are replicated to the RODC, reducing the impact in case of server compromise. You can configure your environment so credentials for service or administrative accounts are never accessed through the RODC.

  • Any change maliciously performed on the RODC, offline or online, will not propagate to the internal DCs. If propagation were tried, it would not be accepted by the internal DCs because it would be coming from an RODC. An RODC cannot be “upgraded” to a full DC.

On the other hand, this configuration has some disadvantages that make it unacceptable in specific scenarios:

  • The full AD RMS certification and licensing servers are still potentially exposed on port 80/tcp and 443/tcp (depending on which server roles are deployed in the perimeter network) because some firewalls do not perform application-layer inspection.

  • The connection to the intranet requires a significant number of open ports between the DC or RODC in the perimeter network and internal DCs (though this can be reduced to a single port through registry configurations in the DCs).

  • Placing a DC in the perimeter network might not be acceptable under the security policies of your organization, although using an RODC can reduce some of these concerns.

This architecture offers a good balance between flexibility and security, especially when you use a read-only DC, but installing a DC in the perimeter network requires special considerations that make it difficult to adopt in some environments.