Protect SharePoint with ISA Server 2006

Microsoft ISA Server 2006 sports a host of new and improved features that extend its capabilities as a front end for SharePoint and make it easier to administer in that role. These features provide enhanced load balancing, easier server publishing, better detection for redundancy, and other improvements. In this article, we look at three SharePoint-related topics for ISA Server 2006: load balancing, using wildcard certificates for authenticating multiple sites, and using forms-based authentication.

Load Balancing Web Front-End Servers
Load balancing enables a group of servers in a web farm to service requests for the same content so that the workload is distributed evenly across the servers in the farm. Regardless of whether you use a hardware or software solution, load balancing is essential to your web farm topology in two primary ways. First, it distributes the load across the servers in the farm, improving overall performance and providing redundancy. Second, load balancing enables the farm to be more easily scaled as load on the farm increases. In the case of a SharePoint farm, you simply add another web front-end server to the farm, then add it to the server group in ISA Server, which begins distributing a share of the load to the new server.

Balancing traffic between web servers is just one requirement, however. To handle load balancing gracefully, the solution also needs to provide detection of failed or offline servers so that consistent and predictable failover can occur. If the Web service hangs on a given server, for example, the load-balancing solution needs to detect that failure and exclude the affected server from the group, transferring the load to the remaining servers in the farm. This detection isn’t a simple matter of a heartbeat or ping between the load balancer and the individual farm servers because the web service could be hung and unresponsive but the server itself still responding to pings.

In addition, when web front-end servers are brought online, those servers need to be added to the balanced farm without affecting current client connections. So, whether a failed server is brought back online or another server implemented to replace it, the load-balancing solution needs to integrate the server into the farm’s overall workload seamlessly and transparently.

ISA Server treats the web front-end servers in a SharePoint web farm as a single entity. When you set up a web farm in ISA Server, you specify either the IP addresses or host names of the servers in the farm. If you specify host names, ISA Server needs to be able to resolve those names to the IP addresses of the target servers. In addition, you specify the method you want ISA Server to use to monitor server connectivity within the farm. As Figure 1 shows, you can use an HTTP/HTTPS GET request, send a Ping request, or establish a TCP connection to each server; the method you choose applies to all servers in the farm. ISA Server performs a verification check every 30 seconds for each server in the farm, with a default response timeout of 5,000 milliseconds.

Probably the best option for server-health detection for a SharePoint farm is the HTTP/HTTPS GET method because it accommodates situations where the web service has failed on a target server but the server is still responding to pings or is able to create a TCP connection. If the server responds to GET requests, it’s a good bet that the server is available and the web service is running.

To use the GET method, you specify a URL that ISA Server will check and prefix the URL with an asterisk (*) to represent the server host name. For example, assume that your farm includes web front-end servers named MOSSWFE01 and MOSSWFE02, and you want to test at the site top level. You specify a URL of http://*/default.aspx for connectivity testing when you set up the farm in ISA Server. When performing the connectivity check for the servers, ISA Server replaces the asterisk with the host names and derives the URLs http://mosswfe01/default.aspx and http://mosswfe02/default.aspx for testing. If your SharePoint configuration requires it, you can specify a custom host header in the URL.

Publishing a SharePoint farm is fairly straightforward thanks to the SharePoint Site Publishing Rule Wizard. Before you run the wizard, however, there are a couple of additional steps to take:

• Determine the communication method between ISA Server and the farm. You can use either HTTP or HTTPS, as applicable to your situation and infrastructure.
• Determine the server farm members and optionally create the server farm object. The members are the servers that are running the Web Server role in the SharePoint farm. You can create the server farm object prior to running the wizard or you can create it within the wizard.
• Determine the web listener settings. The web listener specifies the ISA Server networks and IP addresses on those networks that will listen for external connection requests, the authentication method and forms to be used, the number of allowed connections, what certificates are used, single sign-on settings, and a handful of other related settings.
• Determine the authentication mechanism that ISA Server uses to authenticate to the web servers. If you’re authenticating all your users against Active Directory (AD), NTLM suffices in most situations. However, you can also choose to negotiate Kerberos or NTLM, constrain authentication to Kerberos only, use Basic authentication, or use no delegation. Each method has situations where it’s the best choice, so do your planning ahead of time to determine which method fits your farm’s requirements.
• Specify alternate access settings. Although you don’t need to specify these settings in SharePoint before running the wizard, you’ll have to do it at some point before deploying the farm. You configure alternate access mapping in SharePoint Central Administration.