Hosting the AD RMS Servers in an Internal Network and Publishing Them to the Internet through a Reverse Proxy with an Application Layer Firewall

  • Article

Applies To: Windows Server 2008, Windows Server 2008 R2

You can place all of the Active Directory Rights Management Services (AD RMS) servers in the internal network and make them accessible from the Internet through a firewall. Typical firewall filtering is normally not acceptable for this type of scenario. This is because HTTP traffic that is passed from outside the network (potentially by malicious users) directly into the internal network can lead to a security incident, even if that traffic is encrypted. Some firewall solutions, however, offer advanced content inspection and service-publishing capabilities that can significantly reduce the risk of providing access to internal servers from the Internet. Microsoft Forefront Threat Management Gateway (TMG) Server is one such product. TMG offers sophisticated application-layer inspection capabilities for HTTP traffic when publishing internal HTTP-based services (commonly referred to as a reverse proxy) to the Internet.

An architecture design in which TMG is used to publish the licensing services of an internal AD RMS cluster is illustrated in the following diagram:

As the diagram shows, in this case no perimeter network is necessary and a single application layer firewall is providing access to the AD RMS servers from the Internet. The AD RMS servers are the same ones being used from the internal network (though potentially with a different URL) and only internal database servers and domain controllers are used.

While allowing access to the internal servers from the Internet can be seen as a risk at first glance, TMG offers capabilities that significantly limit these risks, such as:

  • The ability to restrict access to specific AD RMS server URLs—Different URLs in the web server hosting the AD RMS services (commonly called pipelines) are used for different services, such as licensing or certification, and the application-level firewall can be configured to forward requests only to specific paths on the AD RMS servers, preventing access from the Internet to those services that are meant only for internal access

  • The ability to implement strong authentication for Internet access to specific pipelines—While IIS can be configured to require strong authentication directly, doing so can be undesirable for users in the internal network

  • The capability to perform pre-authentication that enables the firewall to pass requests only from authenticated users and to drop any other packets

  • The ability to terminate a Secure Sockets Layer (SSL) connection for content inspection and filtering

Such an architecture presents some important advantages, such as:

  • It provides strong protection of the AD RMS servers from external, malicious users (as well as from internal users, if a reverse proxy is used for access from the internal network) by allowing access to the AD RMS servers only to authenticated users and through specific ports.

  • It requires a single AD RMS infrastructure with no special need for licensing-only servers.

  • It keeps firewall filtering rules simple. Complex filtering rules can increase the chance that a configuration error can result and lead to network compromise.

  • All AD RMS services can be published selectively to the Internet by controlling which pipelines are allowed, providing fine-grained control of the functionality that is exposed externally.

  • No internal firewall is necessary. Nevertheless, the configuration is compatible with further network segmentation and filtering.

  • No management or filtering of complex protocols, for authentication or replication, is necessary at the firewalls.

  • You can use it to implement strong authentication to some or all of the AD RMS pipelines (via a smart card or other two-factor authentication mechanism).

This solution has a few negative aspects that include the following:

  • Some organizations have policies that restrict the publishing (reverse proxy) of internal servers to the Internet, which exclude this option from consideration.

  • Because there is only one certification and licensing cluster that is required to be implemented, any type of security issue that affects the cluster affects both internal and external access. One example of this type of security issue is a denial of service attack (though these attacks can typically be blocked at the publishing ISA server before the internal servers are compromised).

In order to selectively enable or disable access to AD RMS functionality from the client, the AD RMS pipeline URLs must be published individually by the ISA server (as opposed to publishing the parent path shared by all AD RMS pipeline URLs). Available pipelines that are typically published externally include the following:

Certification pipeline

  • Published through the path /_wmcs/Certification/Certification.asmx

  • Called when a user needs to request or renew a rights account certificate (RAC)

  • Default permissions should be kept, which causes users to be prompted for domain credentials when they access the service externally. Default permissions also provide temporary RACs to users on computers not managed by the organization’s IT department.

Licensing pipeline

  • Published through the path /_wmcs/Licensing/License.asmx

  • Called when a user requests an end-user license (UL/EUL).

  • Anonymous access can be safely granted on this pipeline, if necessary, to issue licenses to external users.

It is important to highlight that, for all the solutions presented to provide external access to AD RMS, service discovery (the process through which clients discover the AD RMS server URLs, which by default is automatically done through Active Directory) must be performed either from the intranet or through a registry override. This is necessary only for certification and for initial content publishing because acquiring use licenses is always done through the URL specified in each protected document.

Activation This registry key defines the URL of the user activation service:

  • Key: HKLM\Software\Microsoft\MSDRM\ServiceLocation\Activation

  • REG_SZ: default

  • Value: <http(or https)://RMS_Cluster_Name/_wmcs/Certification>

EnterprisePublishing This registry key defines the URL of an RMS installation that you want this client to use for license requests:

  • Key: HKLM\Software\Microsoft\MSDRM\ServiceLocation\EnterprisePublishing

  • REG_SZ: default

  • Value: < http(or https)://RMS_Cluster_Name /_wmcs/Licensing>

Also, content publishing licenses should include both the intranet and extranet URLs, so that both should be configured before protecting content (by default, only the intranet URL is configured during installation of the AD RMS servers), as in the following example:

<DISTRIBUTIONPOINT>
<OBJECT type="License-Acquisition-URL">
<ID type="MS-GUID">{0F45FD50-383B-43EE-90A4-ED013CD0CFE5}</ID>
<NAME>DRM Server Cluster</NAME>
<ADDRESS type="URL">https://RMS_Cluster_Name/_wmcs/licensing</ADDRESS>
</OBJECT>
</DISTRIBUTIONPOINT>
<DISTRIBUTIONPOINT>
<OBJECT type="Extranet-License-Acquisition-URL">
<ID type="MS-GUID">{94BF969A-CA04-44d6-AA96-51071281FEF2}</ID>
<NAME>DRM Server Cluster</NAME>
<ADDRESS type="URL">https://rms-external-url.com/_wmcs/Licensing</ADDRESS>
</OBJECT>
</DISTRIBUTIONPOINT>