Let’s begin by launching the ISA Management Console, and navigate to create a new web site publishing rule.  The New Access Rule Wizard will launch in which you will begin by specifying a name for your rule.

Select Deny as your Rule Action

Select Publish a single web site or load balancer.

Select Use SSL to connect to the published Web server or server farm.

Enter your Internal Publishing Details which should be identical to the original Exchange Publishing rule.

Click Next and then Next again skipping the Path details.

Enter the Public Name details as per your original Exchange Publishing rule.

Select the existing Exchange Web listener that you already have created for your Exchange Publishing Rule.

Select, No delegation, and client cannot authenticate directly.

Remove Authenticated Users if present and select All Users instead.

You will then receive the below warning as we have selected All Users.  Ignore this warning and click on OK to continue.

Now that the rule has been created, we need to specify the redirect page.  Right Click on the newly created rule and select properties.  Navigate to the Action tab and click on the check box beside “Redirect HTTP requests to this Web page:” and enter the full Outlook Web Access URL.

We are now complete.  You will need to ensure that the deny rule is place immediately below the original Exchange Publishing Rule as per the below screen shot.  When a user now enters the url mail.yourdomain.com it will hit the redirection rule that we have just created which will then redirect to https://mail.yourdomain.com/owa and authenticate against your original Exchange OWA rule.

In summary we have removed the all so common confusion that end users may encounter when browsing to the Outlook Web Access site.  This methodology provided above with the deny rule can also be used against any other web site publishing rule including SharePoint Sites and Terminal Server Web Access.

So let’s begin the second part of our setup!  The first item we need to address is the newly created certificate that has been applied to our site in IIS.  ISA also needs to be aware of this certificate so we need to export it from IIS and then import it to the certificate store on the ISA server.  This certificate will be required when creating the web listener in the ISA rule later below.

To export the certificate, select it in IIS and select Export under Actions.

Specify the export path and enter a password.

After exporting the certificate, copy it to your ISA server and then launch the Certificate MMC snap-in from the ISA Server.

Right click on the Personal Folder and select All Tasks /  Import.  This will invoke the Import Certificate Wizard.

Click Next.  Browse for the certificate file that we exported and copied earlier.

Click Next.  Enter the password that we supplied to the exported certificate.

Click Next and ensure that the certificate is placed in the Personal Certificate Store.

Now that we have done the pre-work for ISA, it’s time to launch the ISA Server Management Console in order to create our SharePoint Publishing Rule.

• · Right click on Firewall Policy and select New / SharePoint Site Publishing Rule
• · Specify a SharePoint publishing rule name
• · Select your Publishing Type, in my case I selected Publish a single Web site or load balancer.
• · Click on Use SSL to connect to the published Web server or server farm

Type the Internal site name: The warning here states that the site name must match the common name or subject alternative name on the certificate. This should be the World Wide Web Address.

Then click on Use a computer name or IP address to connect to the published server and enter the correct details. This could potentially be a single server  IP or the IP address of your Network Load Balanced Cluster.

Specify the Public domain name.

We will now create a New Web Listener by clicking New. This will invoke the New Web Listener Wizard

• · Provide your web listener with a friendly name. e.g SharePoint FBA
• · Select Require SSL secured connections with clients in the Client Connection Security Window

• - Specify the Web Listener Internal IP address.  If you recall from part 1, this is a domain joined ISA server sitting in the internal network in between an existing edge firewall and your SharePoint Site.

The next step requires you to select your SSL certificate. Depending on the number of certificates your ISA server is storing you will either select Single certificate (in the event you are using a SAN or wild card certificate) or assign a certificate for each IP address. In my case I am using singular certificates for my SharePoint Sites so I will assign a specific certificate against a unique IP address.

You now need to select your Authentication Settings for the web listener. We are providing Forms based Authentication for our SharePoint Sites so I will select HTML Form Authentication and then select how ISA server will validate these. I am selecting Windows (Active Directory in my instance).

• · Specify your Single Sign On Settings, Click Finish.
• · Select your Authentication Delegation. In my case I am selecting NTLM

• · Select “SharePoint AAM is already configured on the SharePoint server. We completed this step after extending our site in Part 1 of this series.

• · Select your User Sets

• · Then Click Finish to complete the Wizard.

One of the great enhancements to ISA 2006 Service Pack 1, is the ability to test your rules automatically within the ISA Management console.  This will do the hard work for you and ensure that your rule is correctly setup and that your certificates are correctly in place.  All you need to do is right click on the rule that we have just created and select properties.

Under the General tab, click on the Test Rule button.

You should get green ticks as per below.

We are done!  Our internal users can now navigate to the external published URL and get directed to ISA’s Forms Based Authentication screen as per below. After successfully authenticating with Active Directory via the ISA server the users will be automatically redirected to the SharePoint site.

Some important points to emphasise;

• Ensure your Alternate Access Mappings (AAM) are setup correctly for the correct zone.
• Ensure your certificate common name matches the fully qualified external domain name which in turn matches the AAM in SharePoint.
• Ensure that you have successfully exported the certificate from IIS Manager and Imported it to your Certificate store on the ISA Server.
• Use the Test Rule Button in ISA 2006 SP1 to test your rule, so ensure you are running the latest Service Pack for your ISA server.

___________________________________________

Articles in this series

1. Securing your SharePoint Sites with ISA 2006 using Forms Based Authentication – Part 1/2
2. Securing your SharePoint Sites with ISA 2006 using Forms Based Authentication – Part 2/2

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 3^rd 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 3^rd 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

1. Securing your SharePoint Sites with ISA 2006 using Forms Based Authentication – Part 1/2
2. Securing your SharePoint Sites with ISA 2006 using Forms Based Authentication – Part 2/2