Extranets: SharePoint 2010 Gateway and Firewall Products

While there is already an abundance of information available online regarding SharePoint 2010, I had not seen much related information on gateway products until this afternoon. Considering the improvements made to Web hosting in SharePoint 2010, I thought it worth taking a look at the various supported options available and determine whether there is much difference when compared to those available at the time MOSS was released back in 2007. The most notable changes since then are that TMG 2010 is effectively the replacement for ISA server 2006 (although ISA 2006 is still tested and supported in SharePoint 2010), and ForeFront UAG 2010 replaces IAG 2007.

Wikipedia defines an extranet by stating that "An extranet can be viewed as part of a company's intranet that is extended to users outside the company, usually via the Internet". In the context of SharePoint, I interpret this as the ability to securely publish SharePoint resources over the Internet in order to provide access to users outside of the company infrastructure.

There are numerous reasons that companies may wish to use a firewall or gateway product to publish SharePoint resources; in my experience this has typically been to provide secure remote access to external staff and customers including those using mobile devices. One product that I have worked with in the past to facilitate this is ISA Server. As with MOSS, Microsoft have tested ISA server with SharePoint 2010 and provide a useful comparison between this, ForeFront TMG and ForeFront UAG here. One area that caught my attention was Web hosting: in SP2010, hosting providers are supposedly "first class citizens" with the introduction of data partitioning and service subscriptions to facilitate multi-tenancy. With this in mind, it seems likely that hosted service provides will want to consider a secure method of publishing their server farm to remote users using a gateway product such as Forefront UAG 2010.

Looking at the comparison provided by Microsoft in the above document, one might wonder why businesses would bother upgrading to Forefront TMG when they are already using ISA server 2006. After all, the only additional feature advertised appears to be "DirectAccess" - and even that is only partially supported for TMG 2010.

John Wettern made some some interesting points back in 2009 that might lead us to think that perhaps TMG is a significant release, as opposed to the difference between ISA server 2004 and 2006 which (as John rightly points out) was little more than a service pack in terms of new features. Looking on the Forefront TMG Technet Blog reveals a couple of other documented benefits of TMG over ISA server 2006 - integrated anti malware protection and encrypted traffic inspection. DirectAccess is a new feature in Windows 7 and Windows Server 2008 R2 that reportedly allows access to shared resources such as folders, e-mail servers and intranets without the need for a VPN.

Although the benefits here in using TMG over ISA are not really that relevant to securing a Web hosting service (which would likely benefit from the use of a reverse proxy server deployed in an edge firewall topology), I think the new features described in the above articles would certainly be useful to companies looking to deploy a gateway product in a back to back perimeter scenario for securing internal resources against the dangers faced online and improve accessibility to internal resources through DirectAccess. Indeed, Microsoft describe TMG as "a comprehensive, secure Web gateway that helps protect employees from Web-based threats" as opposed to UAG which "delivers secure, anywhere access to messaging, collaboration, and other resources, increasing productivity while maintaining compliance with policy".

So aside from the obvious benefit of an extended support period, there appear to be few compelling reasons for MOSS Web hosting providers to move from an existing reverse proxy scenario using ISA server 2006 to TMG 2010 when it comes to upgrading to SharePoint 2010 - indeed, you would only use TMG to protect internal users from Web based threats.

Lets move on to Forefront UAG 2010 - Microsoft's flagship gateway product that extends the features offered by TMG to include dedicated interfaces for mobile devices, health based authorisation and information leakage mitigation.

Microsoft provide a useful lists of benefits UAG brings to SharePoint here. This time the feature comparison appears to offer a more compelling reason to upgrade from ISA server 2006 in order to publish SharePoint 2010 resources - lets take a look at these features in the context of a provider looking to publish an extranet in a remote access scenario.

First up - information leakage mitigation. Having been through numerous penetration tests with prospective clients recently this one certainly sparked my interest. UAG deletes all cached files, temporary files and cookies which from a security perspective offers a compelling new feature when compared to ISA and TMG. Similarly, endpoint health-based authorisation offers an interesting corporate security improvement - particularly the capability to prevent unsupported (and potentially insecure) browser versions from accessing a published SharePoint site. It seems that these new security features will allow hosting service providers to proactively protect their sites in more ways than ever before.

Microsoft's inclusion of "Granular access policies" as an exclusive UAG feature in the comparison threw me slightly - having used ISA server 2006 extensively as an edge firewall I didn't see this is a new feature given that the ISA policy manager is extensive. I dug a little further on technet and can conclude that this feature mainly refers to the ability to target policies at specific platforms - such as Windows, Macintosh or Linux. I think that Microsoft's consideration for platforms other than Windows here demonstrates their change in approach toward competitors - a welcome change for customers that is consistent with the cross-browser support for SharePoint 2010.

In conclusion, customers planning to move to SharePoint 2010 that are looking to implement a gateway product to securely publish their server farm have more choice than ever before. While there are few obvious reasons to move from an existing ISA server 2006 based topology to TMG 2010, the extended features offered by UAG 2010 are a definite improvement and will allow providers to offer a very secure, policy based SharePoint installation to customers. Customers wishing to upgrade should note that UAG 2010 requires Windows Server 2008 R2 64-bit.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

ISA Server: Publishing MOSS with ISA Server 2006 SP1: Lessons Learnt

Note: a version of this article updated for SharePoint 2010 is available on my new blog site here.

1. Introduction

Hi! This is officially my first blog post, not only in this particular blog but ever. I would provide an introduction, but I am almost certain that most of you are only looking at this as a result of a Google search for "publishing MOSS using ISA server 2006" (or something along those lines). Guilty? I thought so.

As such, I will skip the intro and get down to business. Following are some notes that I made whilst attempting to (and eventually successfully) configuring ISA Server 2006 to publish a series of MOSS portals. Although I could go into detail on how I carried out each step, I have decided to give an overview to begin with and respond to any requests the general public may have ("Could you show me how to get SSL bridging to work?" etc).

2. Acknowledgements

To start with, I must give due credit to those articles which helped me most whilst setting up ISA Server 2006 to publish a secure MOSS environment. Obviously you can find these for yourself using a search engine, but I thought it useful to show a concise list of those I found most informative:

• Technet: Remote Management Concepts in ISA Server 2006 (Microsoft discuss best practises and precautions to take whilst remotely managing ISA server - read this one before installing if possible).
  
• Technet: Publishing SharePoint 2007 using ISA Server 2006 (Microsoft's own article on publishing MOSS using ISA server - very useful to get started).
• Technet: Plan alternate access mappings (From the Microsoft SharePoint team blog- includes information on configuring AAM using ISA server. Invaluable if you are looking at the AAM screen in SharePoint central admin and wondering why MOSS isn't working as you might expect).
• Technet: Authentication in ISA Server 2006 (useful for understand how different authentication mechanisms operate in ISA server 2006).
  
• MSFirewall.org.uk: Customising ISA Server 2006 HTML forms (I haven't actually used this one myself as it was only recently published but based on the fact that I have successfully configured custom login form branding myself I would say this article looks exceptionally useful).

3. Lessons Learnt

Most of us have heard the saying Keep It Simple Stupid (KISS). In configuring ISA Server, and particularly whilst attempting to configure SSL termination (so as to forward HTTP requests to the published MOSS Server), I realised KISS is probably the most concise way of summarising the lessons I learnt:

3.1 Proceed with care when installing ISA server remotely *Important!*

In case you didn't know, ISA Server is designed to function as an industry grade firewall. This means that unless you have configured it correctly, it will try its hardest to stop anything and everything from accessing it and the published servers it is protecting. This means you are locked out if the server is not configured to allow remote administration. I learnt this the hard way and had to drive to our MOSS farm to manually correct the issue - make sure you don't make the same mistake.

The key to preventing yourself from being locked out is to:

• Before installation: add exceptions for RDP and file / printer sharing in the Windows Firewall prior to installation.
• After installation: define "Remote Management Computer Sets". This means adding your IP address to the list of trusted remote management addresses. More detail on this can be found in the Technet article listed in the "acknowledgements" section of this post.
  

3.2 Install ISA Server 2006 SP1 from the beginning

I know - this sounds like an obvious one. But if you are as keen to get ISA server up and running as soon as possible you may be tempted to skip the updates. Don't do it. ISA Server 2006 SP1 includes a host of new features, but the most useful one has to be the ability to test a new publishing rule (you will see what I mean if you haven't yet installed SP1 and are having difficulty troubleshooting a given publishing rule).

3.3 Ensure AAM is configured correctly

This is, from what I have gathered the number one mistake made when troubleshooting ISA / MOSS publishing scenarios, particularly when using SSL termination (see the lesson below). Ensure you read and follow the Microsoft article on planning AAM in the "acknowledgements" section above. From my experience, I can say with great certainty that most issues you will encounter (particularly with regard to SharePoint document library functionality) will be related to an incorrect AAM configuration.

3.4 Use SSL bridging where possible

I spent a significant amount of time and effort attempting to get SSL termination (or off-box termination as it is commonly known) working due to my belief that SSL bridging would result in significant processing overhead. Before you make the same mistake, try SSL bridging for yourself in your own environment. In most cases, you will find the overhead is negligible and it could potentially save you a lot of wasted hours / hassle for the following two reasons:

• SSL termination means the forwarded URL will contain HTTP rather than HTTPS. You will find that in most cases (assuming AAM is configured correctly), SharePoint will work just fine in this configuration. However, in my case I kept finding small niggling issues that required a fix (note that this is particularly the case if you use custom web parts that may store URLs in a database). An example of a problem with standard MOSS functionality was trying to export to a spreadsheet from a SharePoint list (if you think you have got SSL termination working correctly, try this for yourself to make sure).
  
• SSL termination means that the channel from your ISA box to your MOSS farm is not secure. There are mixed opinions on whether this is a real security issue, but suffice to say I prefer to be able to (honestly) tell clients that "128 bit encryption is used end-end over a secure SSL channel". Sure, you may pass penetration testing and clients may not ever find out if you are using SSL termination, but there is always "what if".
  

3.5 Authenticate at the ISA server

Again, this sounds obvious. ISA server provides a perimeter defence mechanism and one of its main benefits is the capability to prevent unauthorised traffic from ever reaching your web servers. To be more specific, do not select "All Users" from within the users tab of any given publishing rule unless you really want anonymous users to access your MOSS site. OK - IIS will still prompt for authentication, but if you want to save bandwidth and CPU cycles, ensure "All authenticated users" is selected.

If, like me you have an environment where you want some areas of your MOSS site to be accessible anonymously (i.e. no authentication), I recommend you create a separate "Public" publishing rule. Ensure you define only those paths (in the "Paths" tab of the ISA Server publishing rule) you wish to be accessible by Joe Public.

By specifying that only "Authenticated users" can access your MOSS servers, you are effectively telling ISA server to communicate to your authentication provider (in my case AD) directly. Valid credentials are then forwarded (delegated) to your published web server.

3.6 Use ISA server monitoring functionality

This one has been almost essential for me. ISA Server 2006 SP1 includes numerous monitoring features, but by far the most useful for me was the "Logging" tab. This tab shows all requests passing in and out of the ISA server and is invaluable when troubleshooting a connectivity issue. Having problems updating Windows? In all likelihood ISA server is blocking HTTP access to the outside world. Not able to ping the ISA server even from within your farm? It's likely you haven't added those servers to the "Remote Management" computer set. Whatever the problem, it is likely that ISA Server's real-time logging capability will assist you.

3.7 Utilise the Windows "hosts" file

As I'm sure many server administrators will know, the hosts file is a valuable tool for forcing a computer to ignore DNS for a particular hostname and use a manually configured IP address. It can be handy to test the ISA server is forwarding requests to your published MOSS server correctly without having to modify the public A-record right away. The file itself is located in C:\Windows\System32\drivers\etc - I normally modify it using notepad.

4. Conclusion

In this post we took a look at some of the lessons I personally learnt whilst publishing MOSS using ISA server 2006 in a real world environment. Depending on whether I receive any comments I will most likely publish future blog posts. If you found the post useful, have a question or have a constructive criticism please let me know! I will in the future be posting about all things MOSS related (not just ISA server) so please subscribe if you are interested.

Cheers, Benjamin Athawes

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook

Add this blog to your Technorati Favourites