SharePoint Portal Server 2003 is a powerful knowledge management and collaboration solution for organizations desiring to increase productivity, enable better communication, provide better access to information, and enhance business processes and decision-making capabilities. Because access to a SharePoint portal site is based on Web standards, many organizations will want to make the rich features of these sites available to employees, partners, and customers over the Internet. To mitigate the inherent risks of providing Internet access to portal sites, organizations need to deploy a flexible, secure, application layer aware firewall solution to protect the confidentiality, integrity, and availability of portal sites.

ISA Server 2000 with Feature Pack 1 installed is an ideal solution for providing secure Internet access to and protection of SharePoint portal sites. ISA Server 2000 firewalls can enable organizations to achieve the goal of providing the highest level of appropriate access for external users with the greatest level of security. ISA Server 2000 is powerful, flexible, and feature-rich firewall providing granular access control, stateful packet filtering (stateful filtering), application layer inspection (stateful inspection), flexible SSL support and configuration, detailed logging, and many other features that provide a high level of security and ease of use.

This document covers how using ISA Server 2000 firewalls together with SharePoint Portal Server 2003 provides the highest level of security and accessibility possible for remote access to SharePoint-based information.

Microsoft SharePoint Portal Server 2003 is a highly effective solution that enables smart organizations where internal users, customers, and partners can quickly and easily find relevant information from disparate sources, collaborate on shared projects, and communicate with each other. Much more than a comprehensive and scalable document management solution, SharePoint Portal Server 2003 makes it easy to seamlessly connect people, teams, and information with each other to support business decision making processes, information sharing, collaboration, communication, and other activities that are critical to the productivity and profitability of organizations. To provide this seamless connectivity, SharePoint Portal Server 2003 provides Web sites and pages based on Windows SharePoint Services to create portals that aggregate document management, information-sharing, and other collaboration tools and services into a single location.

SharePoint Portal Server 2003 provides a wide range of services and features that will prompt many organizations to consider extending its availability from the intranet to extranets and to the Internet. Portal sites are Web based and accessible from Internet browsers through the HTTP and HTTPS protocols (to provide confidentiality of data). Authentication to portal sites can occur through a number of different mechanisms, including Windows Integrated Authentication (WIA), Basic Authentication, Anonymous Authentication, Digest and Advanced Digest Authentication, and Certificates Authentication (SSL). Moreover, SharePoint Portal Server 2003 enables granular control over permissions governing access to content and other areas of the portal site. The security context of incoming users can be leveraged to provide tight control over content and other areas of the portal site that users are allowed to see or modify.

For large organizations wishing to allow customers access to services provided by SharePoint Portal Server 2003, they can configure Network Load Balanced front-end web servers that connect to a back-end SQL 2000 database. These servers can be clustered to provide increased fault-tolerance and availability. Organizations can purchase licenses for SharePoint Portal Server 2003 that enable an unlimited number of Internet users to gain access to the portal site.

Organizations can realize a number of significant benefits by making SharePoint portal Web sites and services available to employees, customers, and partners from the Internet.

Employees could securely access the portal site from home or on the road without the need for establishing a VPN connection. Many ISPs are blocking ports used for PPTP and L2TP/IPSec traffic on residential accounts, forcing many telecommuters and their employers to pay for a more expensive service that will allow the use of VPN ports. Furthermore, supporting a VPN infrastructure requires administrative effort and entails its own set of risks.

When a user connects to the intranet via a VPN link, the entire intranet is usually available to him for browsing and resource access. If the user’s computer is infected with a virus or a Trojan, the VPN connection represents a point of entry for malicious programs. Although it is possible in Windows 2003 to quarantine the VPN connection in order to run scripts to check for up-to-date anti-virus software and definitions on the VPN client before allowing access, VPN access remains problematic whenever computers outside the administrative control of the network administrator are allowed to become trusted internal network hosts by virtue of the VPN. Access to resources on the intranet is controlled through a single point and a limited set of protocols by connecting to the portal site through HTTP or HTTPS.

By leveraging features of SharePoint Portal Server 2003, organizations enhance their relationships with customers and boost sales. For example, through a publicly available portal site, customers could search for product descriptions and other documents, contact sales and technical support staff, add contact information, and contribute to public discussion threads.

SharePoint Portal Server 2003 enhances relationships with business partners by making available a wide variety of tools and services that facilitate collaboration on joint projects and tasks. Because of SharePoint’s extensibility, it is possible for line-of-business applications on the partner site to communicate directly with the portal. That is, partner applications could leverage a client/server relationship with the portal site.

As an example and imagined scenario, a retail e-commerce site could send search requests for detailed product information to a Web service running on manufacturer’s portal site on behalf of a potential customer who was connected to the retail Web site. The portal site would find the information using its own client/server model (that is, sending the search requests to the back-end SQL Server), and then send the requested information back to the e-commerce site for delivery to the customer.

The extensibility of SharePoint Portal Server 2003 is partly the result of its reliance on ASP.NET and its exposure of the Object Model and the Simple Object Access Protocol (SOAP) layer. SOAP provides a means of implementing a client/server model whereby one program can communicate with another program using HTTP and XML, regardless of the operating system used by the client or server program.

SOAP allows programs to exchange structured information with each other using XML. Among the advantages of SOAP is that it allows a wide variety of programs and systems to communicate with one another, including those that use Remote Procedures Calls (RPCs). Another key advantage (and danger) of SOAP is that it uses HTTP or HTTPS as a transport to tunnel information from one program to another, thereby making it easy for this traffic to cross through firewalls, which usually leave the ports for HTTP traffic open for access to Web sites.

Security Issues for SharePoint Portal Server 2003 Web Sites

There are many benefits to making portal services available from the Internet, either as an extranet deployment or as dedicated Web site accessible to the general public. (An extranet makes available intranet resources from the Internet.) Exposure of portal services to the Internet, however, significantly increases the threat of compromise to those services. (Threat can be considered as the sum of risk of compromise and possible loss of assets through an exploitable vulnerability and the vulnerabilities themselves.) Compromise of the portal services can take three general forms:

Loss of confidentiality.
This occurs when users have access to data they are not authorized to read, either as a result of improper permissions, theft of authentication credentials, sniffing data in transit, Man-in-the Middle attack, and so on.
Loss of integrity.
This occurs when data is improperly modified or destroyed, often as a result of improper permissions on the data that allow authorized or unauthorized users too high a level of access.
Loss of availability.
This occurs when services are not available, usually as a result of a Denial of Service (DoS) attack. Denial of Service attacks can take a number of forms, such as TCP SYN, SMURF, Ping-of-Death, and Application-Directed attacks. An Application-Directed attack takes advantage of weaknesses in applications, such as IIS. A good example of such an attack is the Code Red worm.

Organizations implementing SharePoint Portal Server 2003 are likely to see it become a mission-critical application within a short period of time. Compromise of the portal server can therefore have significant consequences, such as loss of employee productivity and loss of sales.

To mitigate the threat of compromise to portal services, a layered approach to security, often referred to as defense-in-depth, should be implemented. This means security is addressed at a number of different levels, including user security training and awareness, hiring policies, organizational security policies, computer configuration, application software configuration, software patches, network design, firewall configuration, and so on.

In the case of SharePoint Portal Server 2003, administrators can take a number of measures to reduce the threat of compromise. These include:

· Implementing strong authentication methods, password policies, account lockout policies, and encryption.

· Leverage the permissions model in SharePoint Portal Server 2003 to ensure a high degree of granular control over access to content and other areas of the portal site.

· The computer hosting SharePoint Portal Server 2003 can be hardened by taking measures such as removing unnecessary services, moving the cmd.exe file from the default location, changing registry settings to harden TCP/IP, securing COM components, implementing URLScan on IIS, and implementing custom ISAPI filters.

· Firewalls can be configured to implement strict policies whereby all traffic into and out of the network is inspected and verified and allowed or disallowed based on those policies.

Firewall Protection for SharePoint Portal Server 2003

The choice and configuration of a firewall to protect a SharePoint server is a critical element in any total security solution. At the most basic level all firewalls, perform simple packet filtering at the network layer. The IP packet header contains information on the source and destination IP address and the source and destination TCP and UDP ports for the transport layer. When a packet filtering firewall receives traffic destined for a particular host, it compares the characteristics of the IP header with rules that are configured on it to determine whether to allow or deny access.

For example, if the firewall receives traffic destined for TCP port 80 (the port used for HTTP requests) at a particular IP address, it will evaluate the source and destination IP address and ports. If the request matches allow rules on the firewall, it will allow the packet to be forwarded to the host. However, simple packet filtering firewalls may at the same time deny access to other traffic, such as traffic destined for TCP port 135 (because they unaware of how to secure the RPC end-point mapper) or TCP port 139 (NetBIOS).

Packet filtering can be found implemented in a wide variety of devices, such as traditional packet filtering firewalls and consumer-oriented gateways for DSL connections. Consequently, packet filtering is widely implemented to prevent unwanted access to internal computers. However, this level of protection is not adequate to protect services running on internal computers from external attacks. Hackers know how to exploit the limitations of packet filtering firewalls and the characteristics of legitimate traffic that is often allowed through them.

Application Layer Stateful Inspection

For example, hackers can insert malicious code into traffic destined for port 53 (DNS) or port 80 (HTTP). Often, these attacks exploit vulnerabilities to buffer overflow attacks on unpatched servers by sending long strings of garbage data within the application layer. The result is usually a denial of service or worse—for example, the unauthorized elevation of permissions on the affected servers.

In general, it is a good security principle not to trust any incoming data crossing the firewall. Data needs to be checked and verified before it is allowed into a DMZ or the intranet. Because it is possible for any port to host any service and because it is possible to “wrap” or “tunnel” protocols in other protocols in other protocols for transport (eg. RPC over HTTP for Exchange 2003 RPC messages or the tunneling of IRC messages in HTTP), it is necessary to check and verify application layer content. Examples of protocols operating at layer 7 include HTTP, DNS, SMTP, Telnet, and POP3.

In situations where Web services are implemented, it becomes even more important to check and verify the payload inside the HTTP header. For example, when a Web service is implemented and SOAP is used to provide structured exchange of information between hosts over HTTP, a malicious hacker could potentially insert code into the XML data that generates a long string of garbage data, consuming resources on the computer hosting the Web service.

It is possible to write an Internet Services Application Programming Interface (ISAPI) filter to evaluate and authenticate data at the Web Method level. (Authentication at the Web service level takes place through IIS authentication methods.) This approach entails administrative overhead in a distributed environment because the ISAPI filter would have to be implemented on all Web servers hosting the Web service.

Furthermore, a number of different filters might be required depending on the Web services that are implemented. A better approach would be to implement a custom filter on a firewall, such as ISA Server 2000, that could inspect and verify the XML data stream and block or allow the traffic on characteristics of the data tunneled over HTTP.

Only application layer firewalls like ISA Server 2000, which can examine the content contained in the application level protocol and enable application proxying of complex protocols requiring use of secondary ports, such as H.323 and FTP can provide adequate security for modern networks. Many application-layer firewalls can drop or accept traffic based on whether the application layer header conforms to expected data, for example, by rejecting HTTP traffic that contains non-ASCII data in header. But, the same firewalls may lack the ability to look deeper into the payload to reject or allow traffic based on content. For example, to reject SMTP traffic because of the presence of offensive words in the message.

Microsoft’s ISA Server 2000 sets the bar for application-layer firewalls. Because of its powerful application-layer filtering capabilities and the relative ease for ISVs to create additional application-layer filters to extend those capabilities, an ISA Server 2000 firewall is the firewall choice for securing remote access to SharePoint Portal Server 2003. Furthermore, in addition to its ability to block or allow traffic based on layer 3 and sophisticated application layer filtering, its ability to log detailed information regarding inbound and outbound access combined with its advanced intrusion detection capabilities make it an ideal choice for protecting any network.

Securing SharePoint Portal 2003 Web Sites with ISA Server 2000

ISA Server 2000 provides powerful application filtering capabilities right out of the box. ISA Server 2000 ships with SMTP, POP3, and DNS protocol-scanning application filters that examine application layer data to prevent buffer overrun attacks and add greater protection by delving deeper into the application layer content. The SMTP application filter can, for example, be configured to reject certain SMTP commands, such as “vrfy”, which is used by spammers to verify the existence and validity of an email address, and to reject messages that contain certain keywords often associated with spam.

In addition to protocol-scanning application filters, ISA Server also ships with a number of protocol-enabling application filters. These include the H.323 and FTP application filters. Both the H.323 and the FTP protocols require the opening of secondary ports after the initial connection is established between the two communicating hosts. These protocol-enabling filters enables applications behind the firewall can use these protocols without additional configuration, such as installing the ISA Server 2000 Firewall client. Another important protocol-enabling filter is the RPC filter for Exchange servers. This filter makes it possible for external Outlook clients to connect securely to an internal Exchange server using RPC without requiring the use of a VPN.

ISA Server 2000 also ships with an HTTP redirection application filter. This purpose of a redirection filter is to redirect traffic to a particular service. In this case, the HTTP redirector is used to redirect all HTTP traffic through the HTTP proxy service, regardless of whether the HTTP client is configured as a Web Proxy client.

Organizations requiring additional application filters, such as a filter that can check and verify the XML data in SOAP messages, can create them using the ISA Server 2000 SDK and other tools, such as Visual Studio. Microsoft provides a number a number of sample filters in the ISA Server 2000 SDK and on its Web site. Developers who know how to create ISAPI filters for IIS can leverage those skills to develop filters for ISA Server 2000. Since many developers already possess this skill, organizations can keep the costs of development down.

Additionally, a number of Microsoft partners have developed filters extending the already powerful application filtering functionality of ISA Server 2000, and provide even greater protection. For example, by scanning for viruses in SMTP and HTTP traffic as it crosses the ISA Server 2000 firewall. In the case of remote users connecting to a SharePoint site, checking for viruses in HTTP traffic at the firewall is an extremely useful feature, since it provides another layer of protection as part of a defense-in-depth strategy.

In addition to providing sophisticated application layer filtering, ISA Server 2000 with Feature Pack 1 (available as free download from Microsoft) provides a number of features that further enhance security for remote access to SharePoint Portal 2003 Web sites. These features include the following:

· Web Publishing

· Server Publishing

· SSL Bridging

· URLScan

· Link Translation

· Delegation of Basic Authentication Credentials

Web Publishing

Web Publishing is the primary and preferred way to make internal Web sites available on the Internet through ISA Server 2000 firewalls. Web publishing makes it possible to publish multiple web sites using a single external IP address, even though the internal web servers consume a number of different IP addresses. When external users connect to the published web, ISA Server 2000 redirects the HTTP request to the internal Web site. Pages on published web sites can be delivered from the Web proxy cache on the ISA server, rather than the Web server itself. Delivering content from the Web Proxy cache reduces load on the internal Web server and increases the apparent speed of the Web site from the point of view of the user. (ISA Server 2000 is also a very fast Web proxy server.)

An important feature of Web publishing is that it supports Web-based authentication methods that are also used on IIS Web servers. These methods include Windows Integrated Authentication (WIA), Basic Authentication, Anonymous Authentication, Digest, and Certificate Authentication (SSL). With Feature Pack 1 installed, ISA Server 2000 supports delegation for basic authentication and RSA SecureID. This provides greater security and eliminates multiple login prompts when users connect to internal Web sites that also require authentication.

When external users request access to a Web site, the ISA Server can pre-authenticate users and pass credentials using basic authentication. RSA SecureID provides stronger two-factor authentication. Two-factor authentication can also be configured for external users by requiring them to authenticate to the ISA Server 2000 firewall using a digital certificate in addition to using basic authentication. Because sessions between the external client and the ISA Server 2000 firewall can be encrypted using SSL, security issues related to the use of basic authentication (passing username and password in clear text) are eliminated.

Although ISA Server 2000 firewalls support pass-through authentication to internal Web servers, there are a number of advantages to requiring users to authenticate to the ISA Server 2000 firewall before they are allowed access to internal Web servers.

Note:
Pass-through authentication is used when an internal Web server requests authentication from anonymous requests forwarded to it by the ISA Server. The ISA Server will pass authentication messages for NTLM and other authentication methods between the client and the server.

An obvious advantage is users must be authenticated before requests are forwarded to the Web site. Another important, but perhaps less obvious, advantage is that username information is stored in the ISA Server 2000 firewall’s log files. This enables the firewall to obtain more detail for analysis of those files.

Finally, because ISA Server 2000 firewalls use destination sets in Web Publishing rules, Web publishing allows for a great deal of flexibility. For example, path statements can be used to map web requests to specific folders or to redirect requests to folders on other web servers. Correct configured path statements in Web publishing rules improve security by eliminating vulnerabilities to directory traversal attacks, whereby hackers are able break out of the web root directory and navigate the file system by sending malformed or Unicode path statements in the HTTP header.

Server Publishing

Server publishing is used whenever it is necessary to make other services other than Web and FTP sites available through the ISA Server 2000 firewall. For example, if external clients required access to an SMTP or SQL Server on the internal network, the ISA Server 2000 firewall could publish TCP ports 25 and 1433, respectively, for those clients. Access to the published service could be controlled by means of packet filter rules that are configured to allow access only to a limited set of IP addresses, in addition to the security configured on the published service itself.

Although an effective method for providing access to internal services, server publishing has a number of limitations. One major issue is that if multiple instances of the same service need to be published, a unique IP address for each instance of the published service has to be bound to the external interface of the ISA Server.

Server publishing does not work for all protocols, in particular those that require the opening of secondary ports after the initial connection has been established.

Note:
Protocols that require secondary connections are also referred to as complex protocols.

To publish these services, it may be necessary to install the ISA Server Firewall Client application on the published server and configure a wspcfg.ini file to bind ports to the external interface of the ISA Server 2000 firewall (this is not a recommended configuration) or to use a protocol-enabling application filter (this is the recommended method).

For example, it is not possible to use server publishing alone to allow external NetMeeting users to establish an audio or video sessions with internal NetMeeting users. Audio and video communication using NetMeeting requires the use of the complex H.323 protocol. Enabling H.323 communication across the firewall is best accomplished with the use of a protocol-enabling application filter specifically designed for that purpose.

Web sites can be published using Server Publishing rules instead of Web Publishing rules. There are a number of disadvantages to using server publishing for web sites and is not a recommend configuration for making internal Web sites available. For example, this configuration allows external HTTP requests to bypass the Web proxy service. Also, server publishing for web servers does not make use of destination sets, resulting in a loss of flexibility for the configuration of access to internal web servers.

In spite of some limitations of inherent in Server Publishing rules, it can provide a powerful method to secure services in a properly designed ISA Server 2000 firewall environment. For example, in a back-to-back ISA Server 2000 firewall configuration, a Web server requiring access to a back-end SQL server is placed in the perimeter network (DMZ) created in the private network between the two ISA Server 2000 firewalls. A Web publishing rule is then configured on Internet-facing ISA Server 2000 firewall to provide access to the Web site; a server publishing rule on the internal ISA Server 2000 firewall to publish an internal SQL Server on the intranet to the Web server in the perimeter network. Access to the SQL server from the perimeter network is strictly limited by packet filter rules to the single, private and non-routable IP address of the Web server.

SSL Bridging

An advantage of using Web publishing is the ability to use SSL bridging to control the behavior of SSL connections between Web sites and clients. Using SSL bridging on a Web publishing rule, a number of configurations are possible. For example, it is possible to terminate an SSL session at the ISA Server 2000 firewall and forward non-SSL HTTP traffic to the internal Web server. An advantage of this configuration is that it offloads processing required to encrypt the session from the Web server to the ISA Server 2000 firewall. This is a useful configuration where there is no requirement for end-to-end encryption between the client and Web server, but there is a requirement to encrypt traffic over the Internet.

Where end-to-end encryption is required, it is possible to configure SSL bridging to terminate the SSL session between ISA Server and the external client and then establish a new SSL session between ISA Server and the internal Web server. As an alternative to establishing a new SSL session between the ISA Server and the Web server, IPSec policies can be implemented to provide the encryption between the two hosts.

Note:
SSL to SSL bridging is the preferred SSL bridging model. The remote client assumes a link that is secured from end to end.

One of the most important advantages of the SSL bridging feature is that it allows the ISA Server 2000 firewall to inspect and verify content of traffic between client and Web server. Because the SSL session is terminated at the external interface of the ISA Server 2000 firewall, the firewall can read payload HTTP payload content and allow or disallow the traffic based on rules it enforces through Web application filters. It is not possible for ISA Server 2000 firewalls to provide this level of protection when server publishing rules are used to make internal SSL-enabled web server available on the Internet.

URLScan

URLScan for IIS has been available separately and as part of the IIS Lockdown tool for some time. The most recent version is URLScan 2.5, which will work with IIS 6.0. With the advent of Feature Pack 1 for ISA Server 2000, it is possible to implement URLScan on ISA Server 2000 either singly on the ISA Server 2000 firewall alone or as part of a defense-in-depth strategy where it is installed on Web servers as well as the ISA Server.

URLScan is a powerful tool for protecting Web servers by examining HTTP requests sent to the Web server in order to allow or deny them according to rules an administrator configures in the URLScan.ini file. Many Web server exploits attempt to compromise the system by sending URLs containing overly long strings, Unicode characters, unexpected or unusual patterns of characters, inappropriate HTTP verbs, and so on. By filtering for allowable length, patterns, characters, and commands in URLs, administrators can block unusual requests that may have been sent to the Web server with a malicious intent.

Implementing URLScan on ISA Server 2000 provides an added degree of flexibility and customization for secure access to publicly available SharePoint servers. SharePoint Portal Server uses the WebDav protocol to allow users to upload, download, delete, navigate, and manipulate files using HTTP. WebDav is actually an extension of the HTTP 1.1 standard, and its functionality is the result of addition of HTTP verbs enabling users to invoke a wide range of commands.

Furthermore, because SharePoint Portal Server 2003 uses the ASP.NET framework, URLScan can be customized to allow or disallow filename extensions used by ASP.NET applications. In fact, it is important to be aware of ASP.NET filename extensions in order to properly configure URLScan to work with IIS 6.0.

Link Translation

Link translation allows ISA Server 2000 firewalls to substitute character strings in URLs returned from a published Web server before forwarding those URLs to the external client. Link translation is useful in a number of situations, and solves a number of problems in Web publishing scenarios.

It is a common practice among web developers to build web pages containing absolute references to internal computer names. This results in broken links if sent to the external client. For example, a Web page containing a link pointing to a GIF file on another internal Web server using a format like http://ServerB/gifs/logo.gif. If this Web page is returned to an external client, the GIF will appear as a broken link, since the client has no way to resolve the server name in the link to an external address accessible via the ISA Server 2000 firewall. With link translation enabled, administrators can configure a mapping allowing the internal server name to be substituted with an external name that is resolvable by the client.

Another common situation where Link translation is useful occurs when external clients must use HTTPS (SSL) to connect to a published Web site, but the internal Web site contains absolute URLs following a format like http://servername/.. In other cases, these links are not hard coded on Web pages. Instead of being “hard coded”, these links are dynamically generated by ASP code that uses the connection type (HTTP or HTTPS) to determine the URL to send to the client.

In situations where SSL bridging is configured to terminate the HTTPS connection at the ISA Server 2000 firewall and then forward the request to the Web server as an HTTP request, ASP code on the Web server detects a standard HTTP connection and dynamically generates URLs it sends back to the client for an HTTP (not HTTPS) response. The client will not be able to establish a connection to these URLs because it is required to use HTTPS. ISA Server 2000 Link translation solves this problem because it can be used to replace the HTTP string with an HTTPS string before forwarding it to the client, allowing the client to make the return connections normally.

Delegation of Basic Authentication Credentials

Implemented as part of Feature Pack 1 for ISA Server, delegation of basic authentication credentials makes it possible for users to be authenticated at the ISA Server 2000 firewall for access to the published Web server. Those credentials are then forwarded to the Web server for subsequent authentication and authorization. So, even though there may be multiple requests and responses for authentication credentials occurring when users are connecting to web pages on the published Web server, they are prompted only once for a set of authentication credentials. Delegation of basic authentication credentials can provide a high level of security in that it requires users to be authenticated with the ISA Server 2000 firewall before access is granted to the Web site.

The problem arises because authentication credentials are not subsequently forwarded from the ISA Server 2000 firewall to the Web server after the client has authenticated with the firewall. The process of authenticating with a particular service and then having that service impersonate the user to authenticate with other services is known as delegation. Delegation is an extremely useful and powerful authentication feature in multi-tiered environments, and one of the reasons that Kerberos v5 is preferred as an authentication mechanism over NTLM is its support for delegation. When Kerberos is used as method to authenticate users with front-end applications, these applications can communicate with back-end applications, such as SQL Server, in the security context of the user account, not in the security context of the application, which may have elevated permissions to the back-end service relative to the user account.

The lack of support for delegation in ISA Server 2000 (without Feature Pack 1 installed) is partly by design. In the case of NTLM authentication using Challenge Handshake Authentication Protocol (CHAP), computers participating in the authentication dialog must have a copy of the hashed password (the master key) available to them. For security reasons, this master key is never sent across the wire. Because the ISA Server does not have a copy of the user’s master key, it can not impersonate the user for the purpose of authenticating the user at the Web site. Hence, delegation is not possible using NTLM authentication. (Note that delegation is different from pass-through authentication whereby the ISA Server enables the authentication dialog to occur directly between the peer Web server and client.)

The authentication mechanism for basic authentication is significantly different from NTLM. When basic authentication is used, both the username and the password cross the wire in Base64 encoded clear text. While this authentication mechanism is inherently insecure if additional measures are not taken to encrypt the authentication dialog between peers, it does have an advantage over NTLM in that it can be leveraged to support delegation since all the information needed to impersonate a user to the Web server is known to the ISA Server 2000 firewall.

When used in combination with SSL to encrypt sessions between the client and the ISA Server 2000 firewall and the ISA Server 2000 firewall and Web server, delegation of basic authentication credentials can provide a high degree of security. Users authenticate with the ISA Server 2000 firewall before they are granted access to the published Web server. The ISA Server 2000 firewall subsequently authenticates with the Web server in the context of the user account so that the user can perform his or her tasks appropriately.

From the user’s perspective, basic delegation of authentication has the advantage of simplicity and convenience. The user is prompted only once to authenticate and be authorized to gain access to the Web site. Administratively, delegation of basic authentication credentials is much easier to implement than a combination of client digital certificate authentication at the ISA Server 2000 firewall and IIS authentication mechanisms at the Web site.

Summary

In particular, ISA Server 2000 firewalls provide sophisticated and easily extensible application layer filtering that can mitigate vulnerabilities that are the result of the exploitation of weaknesses in legitimate protocol traffic for illegitimate ends. Features such as URLScan form a first-line of defense to ensure inappropriate HTTP traffic is dropped before it reaches Web servers that have also been hardened against this inappropriate traffic. Furthermore, features such as SSL bridging, link translation and delegation of basic credentials ensure that the experience of connecting to portal sites over the Internet is both transparent and highly secure.