Do you want to provide your information workers access to your SharePoint Site whilst out of the office easily from any internet connection without compromising security? Do you want to accomplish this without complicated client-site VPN setups. In this 2 part series I will be providing you with step by step instructions explaining how you can leverage Microsoft’s Internet Security and Acceleration Server (ISA) 2006 and the out of the box SharePoint publishing rule to provide secure access for your corporate users using SSL. YES! That’s right! Whether you like it or not, Microsoft ISA is a great reverse web proxy application firewall in which HTTP/HTTPS traffic from the internet is inspected first before it is forwarded onto the destination server, in our case our SharePoint web servers. Microsoft ISA is also more than capable in providing you with a secure edge firewall as well.
Providing reverse web proxy is something that most major firewall vendors cannot accomplish out of the box including some of the big players like Checkpoint and Cisco. ISA is an ideal choice of reverse proxy to place in between your existing edge firewall and your SharePoint server due to the application layer inspection filtering that is also provided. Our ISA 2006 server should be domain joined in this instance as it will be acting as a dedicated reverse proxy and there are a lot of articles at isaserver.org supporting my case.
The below diagram is an example of how ISA can be strategically placed within your network. In our example, all servers are running Windows Server 2008, SharePoint 2007 and ISA 2006 with the latest Service Packs applied at the time of this writing.
Our goal at the end of this 2 part series is to setup Forms-Based Authentication (FBA) (screen capture below) where users are forced to authenticate successfully with Active Directory first before being passed on to the SharePoint Server.
So let’s begin. This post is assuming that you already have your current SharePoint Site setup correctly in IIS and Central Administration assigned to the Default Zone with Windows being our assigned Membership Provider. Our goal is to now be able to access the same SharePoint site outside of the corporate LAN via the World Wide Web using the same authentication method, i.e. via <DOMAIN>\<Password> . In order to do so, we need to extend the current site, ensure that the Alternate Access Mapping (AAM) is setup correctly and secure the extended site using SSL via a 3rd party root certificate.
Extend your existing SharePoint Site
Browse to Central Administration / Application Management and under SharePoint Web Application Management, select
- · Create or extend Web application
· Click on Extend an existing Web application
· Select an existing Web application to Extend
· Create a new IIS web site and type in your description
· Port should be set to 443 (SSL)
· Specify a Host Header : yousite.externalfullyqualifieddomain.com
· Select Yes Use Secure Sockets Layer (SSL)
· Select Internet for your Zone as requests are coming from world wide web
· Click OK
Alternate Access Mappings (AAM)
The Alternate access mappings for the zone should have been created for you and you can confirm this via Central Administration / Operations / Global Configuration / Alternate access mappings.
More detailed information on Alternate Access Mappings (which I highly recommend) can be found at this TechNet Article http://technet.microsoft.com/en-us/library/cc288609.aspx (Plan alternate access mappings)
By default your Alternate access mappings for all 5 zones (Default, Intranet, Internet, Custom, Extranet) are set to use Windows as your Membership Provider Name which is what is required in this example. Recall that we want our users to authenticate using their Active Directory credentials. You can confirm the Membership provider for your zones via Central Administration / Application Management / Authentication Providers. Ensure the correct Web Application in question is selected first.
Please also note that the extended Website will have been automatically created and listed in IIS Manager (Windows 2008)
SSL and Certificate Creation
We now need to create a certificate request that we will pass on to our preferred Certificate Authority (CA). Please note that it is best practice to use an external CA to avoid SSL warnings and errors for your users when browsing to the site. My preference is Godaddy.com who provide decently priced certificates, and no I am not a Godaddy reseller 
In IIS 7 Windows 2008 this is done via Server Certificates located under the properties page of the IIS Server.
- · Click on Server Certificates, under the IIS heading
· Under Actions, Click on Create Certificate Request
· Fill in the details; please note the Common name is important and should be the fully qualified domain name that is being accessed from the World Wide Web.
- · Select your Cryptographic Service Provider Properties.
· Specify the filename and location to output the certificate request (The contents of this file (MODIFIED EXAMPLE BELOW) is important as it will be required by your Certificate Authority. In my case I am using a 3rd Party Certificate Authority that will issue the certificate.
- · Once you have been issued with your certificate file from your Certificate Authority, go back into IIS Manager and re-launch Server Certificates and this time under Actions select Complete Certificate Request
· Browse for the File Name and specify a Friendly name
Upon completion of the wizard your certificate will appear beside the already self signed machine certificate in IIS7.
You will now need to apply the new certificate against the recently extended website.
- · Click on the Site you wish to apply the certificate and then click on SSL Settings.
- · Select Require SSL and Require 128-bit SSL for your SSL settings and click on Apply
We now need to apply our newly imported certificate to the extended site by clicking again on the extended site, and under Actions select Bindings and then click on Edit.
Select the newly added SSL certificate from the drop down and ensure the port and IP address settings are correct.
Our site is now secure and ready to be accessed via the World Wide Web, well almost! Stay tuned for next week for part 2 of this article, in which we will be focusing on the configuration of ISA 2006 and how we can leverage the inbuilt SharePoint Publishing Wizard to allow external access to our SharePoint site via SSL and Windows Forms Based Authentication.
___________________________________________
Articles in this series