Executive Summary: |
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.
With these decisions behind you and your web servers up and running, you’re ready to publish your farm. To launch the wizard, open the ISA Server Management console, right-click the Firewall Policy node, and choose New, SharePoint Site Publishing Rule. After you specify a name for the rule and click Next, the wizard gives you three options, as Figure 2 shows:
- Publish a single Web site or load balancer—Use this option to publish a single web server or publish a load-balanced farm that sits behind another load balancer.
- Publish a server farm of load balanced Web servers—Use this option to load balance the farm using ISA Server.
- Publish multiple Web sites—Use this option to publish multiple websites. The wizard creates a rule for each site.
The second option is the one to use when ISA Server is load-balancing the web front-end servers for your SharePoint farm. As you move through the wizard, you’ll be prompted for the following information:
- Internal Publishing Details—Specify the internal site name for the web farm, which is typically the name that users use when accessing the farm internally.
- Specify Server Farm—You can choose an existing farm object or create a new one. If you’re creating a new farm, specify the farm object name, the name or IP address of each server in the farm, and the monitoring method that ISA Server will use to monitor individual server availability within the farm.
- Public Name Details—Specify whether ISA Server accepts requests for all domains or only for a specific domain. If you’re specifying a single domain, you enter the Fully Qualified Domain Name (FQDN) for the farm, such as www.contoso.com.
- Select Web Listener—Select an existing web listener or create a new one on the fly. Regardless of which option you choose, you can edit the listener properties within the wizard or afterward.
- Authentication Delegation—Choose the authentication method that ISA Server will use to authenticate to the web farm.
- Alternate Access Mapping Configuration—Specify whether alternate access mappings are already configured on the SharePoint farm.
- User Sets—Specify how the publishing rule is applied. By default, it’s applied to all authenticated users, but you can add, edit, and remove user sets as needed.
To view the rule settings after you create them, open the Firewall Policy node and double-click the rule. You can review and edit settings as needed and also modify the default settings for rules that aren’t set through the wizard, such as schedule and link translation.
The properties for the rule also specify how the rule handles client affinity, ensuring that the same web front-end server handles all requests for a particular client. The Web Farm tab lets you choose between cookie-based (session affinity) and source IP–based (IP address affinity). Session affinity provides more reliable client affinity and is recommended for SharePoint farms.
Using Wildcard Certificates
If your SharePoint farm hosts multiple websites, such as www.constoso.com, support.contoso.com, and partners.contoso.com, and you need to secure those sites with SSL, you need to decide whether to use individual SSL certificates or use a single wildcard certificate.
An SSL certificate includes a common name as one of its properties. The common name must match the host header being submitted by the client’s browser or a certificate error occurs. For example, the common name on a certificate for the site www.contoso.com should be www.contoso.com. If you map support.contoso.com to the same site and users browses to that URL, they’ll see a certificate error because the host header, support.contoso.com, doesn’t match the common name in the certificate. Depending on how the client browser is configured, users might not be able to browse to the site.
A wildcard certificate lets you use a single certificate for multiple sites in a domain. Instead of a common name that matches the site name, the wildcard certificate uses an asterisk in the common name in place of the host name. So, in this example, the common name of the certificate would be *.contoso.com. Any site in the contoso.com domain can then be served by this single certificate.
Both types of certificate have their advantages. If you’re hosting a relatively small number of sites, individual certificates are probably less expensive than a wildcard certificate. As the number of sites increases, you see a tradeoff between ease of administration and cost: It’s easier to manage a single certificate and you can deploy as many sites as you need without adding other certificates, but you pay more for that convenience and flexibility.
To determine whether a wildcard certificate is the right solution for you, look at the number of sites you’ll be hosting and the cost differential between that number of individual certificates and a single wildcard certificate. For example, if individual, one-year certificates are $995 and a wildcard certificate is $15,995, then your break-even point is essentially at 16 sites; with any more than 16 sites, you’ll pay less if you purchase a wildcard certificate. But you should also factor in any projected growth in your number of sites and how much it’s worth to you to not have to manage multiple certificates, and you’ll have an answer to the question of which option is best for your environment.
Note that you aren’t limited to using a certificate only on ISA Server. If you want to secure traffic between ISA Server and your web front-end servers for your SharePoint farm, you can also install certificates on the front-end servers. As Figure 3 shows, when you run the wizard to create the publishing rule, you specify that ISA Server will use SSL to connect to the servers in the published web farm.
To use a wildcard certificate to publish multiple websites with a single web listener, first obtain the wildcard certificate and install it in the machine store on each ISA server in the array. After you install the certificate, create the new web listener that you’ll use to publish the sites. In the New Web Listener Definition Wizard, when prompted to select the certificates for the web listener, choose the option Use a single certificate for this Web Listener, then choose the wildcard certificate.
Forms-Based Authentication
Forms-based authentication uses HTML forms to authenticate users, and ISA Server 2006 supports forms-based authentication to published SharePoint servers. ISA Server 2006 provides three sets of forms: HTML for standard browsers, and Compact HTML (cHTML) and Extensible HTML (XHTML) for mobile browsers. ISA Server serves up the appropriate form based on the User-Agent header sent by the client. In addition, ISA Server 2006 supports three types of forms-based authentication:
- Password—The user enters the username and password. This type supports AD, LDAP, and Remote Authentication Dial-In User Service (RADIUS) authentication.
- Passcode—The user enters a username and passcode (i.e., a single-use password such as those generated by security token devices). This authentication type supports SecurID and RADIUS one-time password authentication.
- Passcode/Password—The user enters a username with passcode and a username with password. The username/passcode combination is used to authenticate to ISA Server using SecurID or RADIUS, and the username/password combination is used for delegation.
The forms used for SharePoint are stored in the \CookieAuthTemplates\ISA folder. This folder contains three subfolders, one each for HTML, cHTML, and XHTML forms. You can customize these forms to brand them or add functionality. For example, you might add disclaimers or notifications to the logon form.
The forms contain input tags, form tags, and placeholders, and you must leave these elements intact for the forms to work. However, you can modify the logon_style.css file to change page and form background color, font style and color, and other visual characteristics of the form. You can also modify the strings.txt file to change the text that ISA Server displays in the forms, as well as to add new text to the file. To add new text, you must add a new, unique placeholder in the form’s .htm file, then add a corresponding entry in the strings.txt file with the same placeholder. ISA Server replaces the placeholder with the text when it displays the form.
You can also change or add graphics for the forms. For example, you might want to include your company logo on the logon form or even use a graphic as the background for the form. The graphics that ISA Server uses by default are stored in the same folder as the .htm files. Changing the graphics is as simple as replacing those graphics files with your own files. You can add additional graphics by modifying the .htm files.
In addition to modifying the existing form sets, you can create a custom form set, enabling you to use the standard set for some web listeners and a custom set for other web listeners. To create a custom set, first create a new folder in the CookieAuthTemplates folder to contain the custom form set. Copy all of the files from the appropriate default form folder (such as HTML) to the new folder. Then modify the forms in the new folder to create your custom set.
To use the new form set, create a web listener, then open the property sheet for the web listener and click the Forms tab. Select the option to use customized HTML forms, and specify your custom form set directory. If you’re using an ISA Server array, the custom set’s folder must exist on all servers in the array.
While you’re visiting the Forms tab of the web listener’s property sheet, note that you have a couple of other options you can set for forms-based authentication. If you enable the option to let users change their passwords, ISA Server offers that option when users log on. In addition, you can also have ISA Server notify the user when their password is scheduled to expire within a time period that you specify. After you’ve modified the forms files as needed, restart the Firewall service for the changes to take effect.
Note that ISA Server forms-based authentication as described here is different from forms-based authentication provided as an optional authentication provider for SharePoint. The latter provides a mechanism to store user credentials in a SQL Server database instead of AD, and present a form requesting those credentials from the user during logon to SharePoint.
Performance, Reliability, and User Happiness
Understanding how ISA Server can function as a front end for SharePoint helps you provide a stable, robust load-balancing solution for SharePoint, which ultimately makes it easier to add and remove servers from a farm when necessary. For example, choosing the right monitoring option helps ensure that ISA Server can recognize failures when they occur and adjust to them accordingly. While the capability to customize ISA Server’s authentication forms might not have an impact on performance or reliability, it can improve branding and user experience. After all, like it or not, it’s all about keeping your users happy.