Category: Web Application Proxy

Summary

There are many ways of allowing access to SharePoint from the internet. It is typically accomplished by setting up a WAP (Web Application Proxy) server in a DMZ and then publishing the SharePoint URL to provide the external access. This technique is easy and great if you want to allow external access to all sites for a specific SharePoint web application. But what if you need to prevent external access to one or more sites? You could create a new SharePoint web application, or host named site collection, that isn’t externally accessible and move those sensitive sites to that web application, but adding additional web applications can put extra load on your farm and can result in many broken links. Also, having to move sites around your farm to prevent access isn’t exactly a flexible solution. Another option would be to design a custom ADFS claim rule along with some javascript to protect the sites, but that seems like a lot of effort and there are plenty of ways to get around javascript.

The problem is related to how a WAP server published web application is typically configured for a host URL, without a path. This means that all sites and sub-sites starting with the host URL will be exposed through the reverse proxy. It is possible to include a path in a published web application, but this approach can result in many publishing points for a single SharePoint web application and can result in proxy URL conflicts. So how do we allow external access to SharePoint and also provide the ability to “block” access to certain sites? The answer is surprisingly easy. We add another proxy server, in this case an ARR (Application Request Routing) server. This architecture works because an ARR server not only acts as a pass-through reverse proxy, but it can also block requests or redirect requests based on IIS Rewrite rules.

Scenario

To explain how the ARR server can be used to prevent access, I’ll walk you through a simple scenario. In this scenario, we have many web sites in our SharePoint web application “https://intranet.meadware.com”. We want to allow access to all of the web sites, except for the accounting site and the engineering site. We configure the ARR server to at as a reverse proxy for https://intranet.meadware.com traffic and we create IIS Rewrite rules to block any requests for /sites/accounting and /sites/engineering. We then publish the https://intranet.meadware.com web application on our WAP server and direct all traffic for that published web application to the ARR server. The ARR server will check every requests and block all requests to the sensitive sites. All other requests will be forwarded to the SharePoint servers. The following diagram shows our solution topology.

The ARR server is now setup to act as a reverse proxy for external traffic. We still have to setup the WAP server to direct traffic to the ARR server, but before we do that lets make sure that our sensitive sites are blocked.

Add blocking rules:

From IIS, open the URL Rewrite administration screen, click on [Add Rule(s)…]

Under Inbound rules, click on [Request blocking].

Note: Instead of a Request blocking rule, you could setup a redirect rule, which would redirect the user to a friendly page that could explain that the content they are trying to access from an external location isn’t allowed. The page could offer additional information and instructions.

Block access based on: URL Path

Block request that: Matches the Pattern

Pattern (URL Path): /sites/accounting*

Using: Wildcards

How to block: Send an HTTP 403 (Forbidden) Response

Click [Ok]

ARR Server Farm Blocking Rule

Once all the blocking rules have been added, we are now set to configure the WAP server to direct traffic to the ARR server.

Publish Web Application on WAP Server

Before we publish the web application, we need to configure the environment to direct traffic to the ARR server for our host URL. There will be three DNS records for this one host URL. The first DNS record is added to a public DNS server. It will direct all internet traffic to our WAP server. The second DNS record will be on our internal DNS server and will direct all traffic for our host URL to the SharePoint server. The third record has to direct traffic from our WAP server to the ARR server. This can be done a couple of ways. The preferred choice would be to setup a DNS record, but this is only possible if a DNS server exists in your DMZ. The second choice, and often the only choice, is to use the hosts file. For our scenario, we will be using a hosts file.

Add IP to Hosts:

Open the Hosts file on your WAP server in Notepad.

Note: Notepad typically has to be running with administer privileges in order to edit the hosts file.

Add a entry in the hosts file that includes the IP address of the ARR server and the host name.

On the Relying Party page, select your SharePoint relying party and click [Next].

On the Publishing Settings page, enter a name for your SharePoint web application. Enter the URL address for your site and select a valid SSL certificate. Click [Next].

WAP Publishing Settings

On the Confirmation page, click [Publish].

On the Results page, click [Close].

Sensitive sites are now be protected. It will be easy to block or allow access to selected sites just by changing the URL Rewrite rules on the ARR server. You could even use these rules to block a specific document library, folder of even a single document. Although, that last one seems a bit far fetch.

Anybody that now attempts to access a secure site from outside your network will get a message like this.

403 Error

Users connect to your network from inside the firewall will still be able to reach the content. The sensitive data cannot leave your network. At least not through the front door.