Blocking SharePoint Sites from External Access

Facebooktwittergoogle_pluslinkedin

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.IIS WAP ARR Diagram

Setup the ARR Server

The details for installing Application Request Routing can be found at http://www.iis.net/downloads/microsoft/application-request-routing.

Once ARR has been installed, it is time to setup the ARR Server Farm.

  • From IIS, right click on Server Farms and click on “Create Server Farm…

    Create ARR Server Farm
    Create ARR Server Farm
  • Give the Server farm a name and click [Next].

    ARR Create Server Farm Step 1
    ARR Create Server Farm Step 1
  • Enter the Server address, click [Add] and then click [Finish].

    ARR Create Server Farm Step 2
    ARR Create Server Farm Step 2
  • When prompted to create the URL rewrite rule to route all incoming requests, click [Yes]. This will create a very generic rule, which we will adjust next.
URL Rewrite Warning
URL Rewrite Warning
Adjust the routing rule:
  • From IIS, click on your newly created ARR Server Farm. You should see the following.

    ARR Server Farm
    ARR Server Farm
  • Open “Routing Rules” and then click on the “URL Rewrite” link.
  • You should see your newly created Inbound URL Rewrite rule. Usually titled “ARR_<server farm>_loadbanace”. Select the rule and click on “Edit…“.

    ARR Server Farm URL Rewrite Rule
    ARR Server Farm URL Rewrite Rule
  • We want to add a condition so that only inbound traffic for our web application is pass-through.  Click the [Add] button in the “Conditions” section.
    • Note: Details on using IIS URL Rewrite conditions can be found at http://www.iis.net/downloads/microsoft/url-rewrite.
    • Condition input: {HTTP_HOST}
    • Check if input string: Matches the Pattern
    • Pattern: intranet.meadware.com
    • Ignore case: checked
    • Click [OK]

      ARR Server Farm Routing Rule Condition
      ARR Server Farm Routing Rule Condition
  • Click [Apply]

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
      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.
    • Typically something like 192.168.1.99 intranet.meadware.com
  • Save the hosts file
Publish the Web Application:
  • Open the Remote Access Management Console on the WAP server
  • Click on “Publish” link
  • Click [Next] on the Welcome screen
  • On the Preauthentication page, select “Active Directory Federation Services (AD FS)” and click [Next]
  • 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
    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
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.

 

Facebooktwittergoogle_pluslinkedin

Leave a Reply

Your email address will not be published. Required fields are marked *