Web Publishing


Web publishing rules allow you to take advantage of the Web Proxy service's ability to look at application-layer information in HTTP requests to make decisions on how to handle packets. At the beginning of this chapter, we discussed many features provided by Web publishing rules that aren't available with server publishing rules. Web publishing rules are the preferred method of publishing HTTP and FTP content on the internal network because they provide a higher level of security.

Several things need to be configured before you create a Web publishing rule. These include:

  • The Incoming Web Requests listener

  • Destination sets

  • Public DNS entries

  • Private DNS entries

Incoming Web Request Listeners

You must configure an Incoming Web Requests listener before a Web publishing rule can work. While you can create a Web publishing rule without configuring an Incoming Web Requests listener, the rule won't accept requests. You can configure listeners separately, or you can apply the same configuration to all listeners.

Each Incoming Web Request listener listens on a specific IP address on the external interface of the ISA server. By default, there are no incoming Web Requests listeners. As you learned earlier in the chapter, you have the choice to configure all IP addresses on the external interface of the ISA server to use the same settings, or you can configure listeners separately.

There are some situations where you must configure listeners separately:

  • Only one certificate can be bound to a particular listener. If you need to support multiple certificates, you will need to create multiple listeners.

  • If you want to support different authentication methods for different publishing rules, you will need to create separate listeners.

  • If you want to use server publishing rules to publish some Web sites, and Web publishing rules to publish other Web sites, you'll need to create separate listeners

Keep in mind that when you create Web publishing rules, you are not asked what listener you want the rule to use. The listener used by a particular Web publishing rule is determined by the FQDN used in the destination set. When a user types in the URL to access a published Web site, the FQDN in the request resolves to the IP address of a specific Incoming Web Requests listener. The listener accepts the request, and then the Web Proxy service checks for rules containing a destination set entry matching the request.

The second most common reason why Web publishing rules will not work is that the Incoming Web Requests listener(s) have not been configured properly.

Destination Sets

The most common reason for Web publishing rule failure is that the destination set used in the Web publishing rule is configured incorrectly. The Web publishing rule uses the entries in the destination set and compares them against the URL in the incoming request. The Web Proxy service passes the URL information for the incoming request to the Web publishing rules, and if one of the rules uses a destination set containing matches for the incoming request, the Web publishing rule is activated.

Destination sets for Web publishing rules need to contain the FQDN (and perhaps that path) that the users on the external network use to access your published Web site. For example, if the user types in http://www.mywebsite.com to access your publishing server, then the destination set must contain an entry for www.mywebsite.com.

It's very common for ISA Server administrators to include the private name of the publishing server in the destination set. For example, suppose the external user needs to type in http://www.mywebsite.com to access the external IP address on the ISA server you're using for the Incoming Web Requests listener. The name of the server on the internal network is web1.internal.net. The ISA Server administrator enters web1.internal.net into the destination set and uses the destination set in the Web publishing rule. When the incoming request for www.mywebsite.com comes into the Incoming Web Requests listener, the Web Proxy service won't find a match because the destination set used doesn't contain www.mywebsite.com; it contains web1.internal.net.

You need to create destination sets before you create Web publishing rules. You'll find when you go through the Web Publishing Wizard that you are not allowed to create a destination set "on the fly." This would be a fine addition to the next version of ISA Server, and we hope to see this change.

Remember that a destination set can contain multiple entries. For example, suppose you run a Web server on the internal network and it houses multiple Web sites. All the sites listen on the same socket (IP address and port number). You configure the Web server to route the requests to the appropriate site using host headers. You can put all the sites in the same destination set and create a single Web publishing rule that forwards requests to all these sites to the same IP address and port number. Just configure the Web publishing rule to send the original host header, and the same header contained in the original request (the one sent by the user) will be sent to the publishing server on the internal network. The publishing server then forwards the request to the appropriate Web site based on host header information.

Public DNS Entries

External network users must use FQDNs to access your published Web sites. Destination sets used by the Web publishing rules have FQDNs and sometimes path statements in them. External users won't be able to access your site if your servers aren't registered in the public DNS.

You might be thinking, "I'll just put IP addresses in my destination set; then I won't have to worry about entries in the public DNS." While you can put IP addresses in the destination set and avoid placing entries in the public DNS, we highly advise against doing so. You lose a great deal of security when you publish using IP addresses, because many Internet worms take advantage of this configuration.

For example, if you published by IP address, your servers would not have been protected against the Code Red Worm and many of its variants. Those of us who use only FQDNs in our destination sets never had to worry about Code Red because ISA Server protected us via Web publishing rules and FQDNs in the destination sets.

Note

Always use FQDNs in your destination sets. Microsoft designed Web publishing rules with the idea that you would use FQDNs in your destination sets. They do not recommend, and do not support, using IP addresses in the destination sets used in Web publishing rules. In addition to the security issues with IP addresses in destination sets, there is a problem with mixing FQDNs and IP addresses in the same destination set. You can avoid this problem by never using IP addresses in your destination sets. You can use a dynamic DNS service such as www.tzo.com if you have a dynamic IP address assigned to your external interface.

The public DNS server can be on your internal network, on your DMZ segment, or be hosted by your ISP or other third parties. It doesn't matter where the DNS records are located; it just matters that they are available to external network users. Make sure there is a DNS Host (A) record allowing external network users to resolve the name of each server you publish with Web publishing rules, and that the DNS Host (A) entry matches the name included in the destination set used by the Web publishing rule.

Private DNS Entries

Internal network users often need to access the same servers that external network users access. While external network users need to access your sites via ISA Server and Web publishing rules, the internal network users should never "loop back" through the external interface of the ISA server.

Web Proxy clients allow the Web Proxy service to resolve names for them. If you configure the ISA server to use a DNS server that resolves the FQDN of the server to the external interface of the ISA server, the client ends up looping back through the external interface. You can get around this problem by configuring the ISA server to use a DNS server on the internal network. This internal network DNS server contains the private IP addresses of the servers you're publishing instead of the public IP addresses.

For example, if you're publishing a server that external network users access via the URL http://www.mystuff.com, you want the DNS server that the ISA server uses to resolve www.mystuff.com to the internal IP address of the server on the internal network. This means that you need to create two DNS zones for the same domain name: one zone used by external network users, and a second zone for internal network users. The zone used by internal network users allows internal network clients to access the server through its internal network address.

This works great for SecureNAT and Firewall clients; SecureNAT clients directly connect to the server on the internal network, and the Firewall clients see the destination IP address as being on the LAT and send the request directly to the Web server on the internal network. Web Proxy clients don't use the LAT. You have to use other methods to prevent the Web Proxy clients from looping back through the ISA server to access internal network resources.

Note

The Local Domain Table (LDT) is used to control how clients resolve names contained in the table. Firewall and Web Proxy clients typically allow the ISA server to resolve names on their behalf. The client resolves the name instead of the ISA server if the resource is located on the domain in the LDT. It's important that you configure all internal network clients with the address of an internal network DNS server that can resolve addresses of internal network servers.

One thing you need to do is configure the LDT. The LDT can be used by Web Proxy clients to allow them to resolve names locally instead of allowing the ISA server to resolve the name. Local name resolution only takes place for those servers or domains contained in the LDT. The ability to allow Web Proxy clients to resolve names locally isn't as important as the ability to configure the Web Proxy client to use direct access for domains on the LDT. Figure 27.44 shows how you configure Web Proxy clients to use direct access to access resources located in domains in the LDT.

click to expand
Figure 27.44: Configuring Direct Access to Internal Site for Web Proxy Clients

Direct access means that the client bypasses the Web Proxy service to access resources configured for direct access. Since the resources are on the internal network, the machine will be able to directly access these resources.

While we're on the topic of direct access, note that when you configure external domains for direct access, the Web Proxy client will try to use the Firewall client or SecureNAT client configuration to access the resource. It will not use the Web Proxy client configuration; sites configured for direct access bypass the Web Proxy service.

Terminating an SSL Connection at the ISA Server

You can publish SSL sites using Web publishing rules. The ISA server terminates the SSL connection at the Incoming Web Requests listener when you use Web publishing rules to publish SSL sites,. The ISA server impersonates the secure server on the internal network.

The first thing you need to do is get a certificate for the site when you run secure Web sites. You can obtain a Web site certificate from commercial entities such as VeriSign and Thawte, or you can use the Microsoft Certificate Server included with Windows 2000 Server and Windows Server 2003. If you want to run a public site, you should use a commercial certificate. Commercial certificates are much easier to work with on public sites because most machines already include the major commercial sites' enterprise root certificates in their Enterprise Trust List. You should use the Windows 2000 Certificate Server if the secure site is for your own users only.

The ISA server needs to be able to impersonate the Web site on the internal network. The ISA server is able to impersonate the secure site on the internal network by presenting the Web site's certificate to external network clients. In order for the ISA server to do so, you will need to install the secure site's certificate into the ISA server's certificate store. You can attach the certificate to an Incoming Web Requests listener once you install the certificate in the machine's certificate store.

Installing the Web site certificate into the ISA server's certificate store is very easy to do. However, there seems to be a lot of misunderstanding on how to bring a certificate server online and how to request and assign certificates. To help you implement a simple certificate infrastructure for your published Web sites, we'll go over how to install a stand-alone root certificate server, an enterprise root certificate server, and how to request a certificate for your Web site from each of these certificate servers. Then, we'll go over how to export the Web site's certificate and how to import the root server's certificate into the enterprise trust list of the Web clients that access your Web site.

Creating a Stand-Alone Root Certificate Server

A stand-alone root certificate server is a good choice when you need to assign certificates to machines that are not members of the internal network domain. One of the big advantages of the stand-alone root certificate server is there are a number of certificate templates available via the Web-based enrollment site that are not available when you roll out an enterprise root certificate server. Another reason to implement a stand-alone certificate server is that you don't have an Active Directory domain in place.

Perform the following steps to install the stand-alone root certificate server:

  1. Click Start, point to Settings, and click on Control Panel.

  2. In the Control Panel, open the Add/Remove Programs applet.

  3. In the Add/Remove Programs applet, click Add/Remove Windows Components in the left pane of the dialog box.

  4. In the Windows Components Wizard dialog box, put a check mark in the Certificate Services checkbox. Click Yes in the dialog box that explains that you cannot rename the computer, or join or remove it from a domain, after installing certificate services. Click Next in the Windows Components dialog box.

  5. On the Certification Authority Type page (Figure 27.45), select the Stand-alone root CA option. You do not need to select the Advanced options check box unless you want to use a custom Cryptographic Service Provider (CSP) and specific settings to be used in generating a key pair, or if you want to use an existing key pair. We will not cover those options in this exercise. Click Next.

    click to expand
    Figure 27.45: Setting the Certification Authority Type

  6. On the CA Identifying Information page (Figure 27.46), type in the information requested for each field. The only field required is the CA name. It's considered good practice to use the computer name (NetBIOS name) of the server in the CA name field. However, if you want to do certificate mappings and matching based on fields, you should enter the correct information in all fields. In our examples, we won't be doing any certificate mapping. However, keep in mind that if you want to use client certificates in SSL bridging scenarios, you will need to perform certificate mapping. After entering the information on the CA Identifying Information page, click Next.

    click to expand
    Figure 27.46: The CA Identifying Information Page

  7. On the Data Storage Location page, select the locations where you want to store the Certificate database and Certificate database log. You also have the option to store configuration information in a shared folder. In this example, we'll use the default locations. Click Next. Click OK in the dialog box warning you that the IIS services must be stopped before continuing.

  8. The Certificate Services files are installed. You might be asked for the Windows 2000 CD during the installation, so make sure you have it handy or have the installation files on a network share.

  9. Click Finish on the Completing the Windows Components Wizard page.

Requesting a Web Site Certificate from a Stand-Alone Root Certificate Server

The Web site can now request a certificate from the stand-alone root certificate server. The Certificate Request Wizard on the Web server won't be able to directly communicate with the certificate server, so you'll have to create a certificate request file and then use the Web-based certificate enrollment system to send your certificate request.

Perform the following steps to begin the certificate request for your Web site:

  1. Click Start and point to Programs. Point to Administrative Tools and click on Internet Services Manager.

  2. Expand your server name in the Internet Information Services dialog box. Right-click on the Web site and click the Properties command.

  3. In the Web site's Properties dialog box, click on the Directory Security tab. In the Secure communications frame, click Server Certificate.

  4. Click Next on the Welcome to the Web Server Certificate Wizard page.

  5. On the Server Certificate page, select the Create a new certificate option and click Next.

  6. On the Delayed or Immediate Request page, select the Prepare the request now, but send it later option. This might be the only option available if there are no enterprise root certificate servers in your organization. Click Next.

  7. On the Name and Security Settings page (Figure 27.47), give the certificate a friendly name. The friendly name doesn't matter in terms of the functionality of the certificate, but it does help you identify what the certificate is used for. Select a Bit length for the certificate. The more bits, the lower the performance. The required number of bits depends on the level of security you desire balanced by the required performance levels. Click Next.

    click to expand
    Figure 27.47: The Name and Security Settings Page

  8. On the Organization Information page, enter your Organization and Organizational unit information. This information is not required. Click Next.

  9. On the Your Site's Common Name page (Figure 27.48), type in the FQDN that users on the external network use to access your published Web server. This is an extremely important entry. The common name must be the same as the one you want external users to use to access the site; this is the same name you include in the destination set in the Web publishing rule you use to publish the site. Click Next.

    click to expand
    Figure 27.48: The Site's Common Name Page

  10. On the Geographical Information page, enter the State/province and City/locality information. This information isn't required, but you should enter the information just in case you want to leverage this information for certificate mapping in the future. Click Next.

  11. On the Certificate Request File Name page, note the default name and location of the certificate request file. You can use this default setting (c:\certreq.txt) in the majority of cases. Make a change if you need to, and click Next.

  12. On the Request File Summary page (Figure 27.49), review the settings and click Next.

    click to expand
    Figure 27.49: The Request File Summary Page

  13. Click Finish on the Completing the Web Server Certificate Wizard page. Click OK in the Web site Properties dialog box.

The next step is to take the contents of the certreq.txt file and paste them into the Web enrollment form provided by the stand-alone certificate server.

Perform the following steps to obtain the Web server certificate:

  1. Open the certreq.txt file you created when you ran the Web Server Certificate Wizard. Select the certificate request information that is highlighted in Figure 27.50. Right-click the highlighted area and click the copy command to copy it to the clipboard. Note that selecting the information the way we did in Figure 27.50 works with the Windows 2000/2003 Certificate Server. If you were to send information to a third-party certificate authority, you should send the entire contents of the file, including the BEGIN and END entries at the beginning and end of the certificate request.

    click to expand
    Figure 27.50: Selecting the Certificate Request Information

  2. Open Internet Explorer and type in the URL to the stand-alone certificate server Web site. The URL is http://<certservername>/certsrv. In our example, the URL is http://webserver/certsrv.

  3. On the Welcome page (Figure 27.51), select the Request a certificate option and click Next.

    click to expand
    Figure 27.51: The Certificate Server Web Site Welcome Page

  4. On the Choose Request Type page, select the Advanced Request option and click Next.

  5. On the Advanced Certificate Requests page (Figure 27.52), select the Submit a certificate request using a base64 encoded PKCS #10 file or a renewal request using a base64 encoded PKCS #7 file option. Click Next.

    click to expand
    Figure 27.52: The Advanced Certificate Requests Page

  6. On the Submit A Saved Request page (Figure 27.53), paste the certificate request information in the text box. Click Submit.

    click to expand
    Figure 27.53: The Submit A Saved Request Page

  7. Go to the stand-alone certificate server machine. Click Start and point to Programs. Point to Administrative Tools and click Certification Authority.

  8. In the Certification Authority console (Figure 27.54), expand your server name and click on the Pending Requests node. In the right pane, right-click on the submitted request, point to All Tasks, and click Issue.

    click to expand
    Figure 27.54: Issuing the Web Site Certificate

  9. Return to the Web server and open Internet Explorer. Type in the URL for your stand-alone certificate server's Web enrollment page. Click on the Check on a pending certificate option. Click Next.

  10. On the Check On A Pending Certificate Request page (Figure 27.55), select the request that appears on the page and click Next.

    click to expand
    Figure 27.55: The Check On A Pending Certificate Request Page

  11. In the Certificate Issued page (Figure 27.56), click the Download CA certificate link to download the CA certificate. Click the Download CA certification path link to download the certification path. Save each of the certificates to the desktop so that you can find them easily.

    click to expand
    Figure 27.56: Downloading and Installing the Certificate

  12. Close Internet Explorer.

The final step is to install the Web server certificate:

  1. Open the Internet Information Services console, right-click the Web site, and click Properties.

  2. In the Web site's Properties dialog box, click on the Directory Security tab. In the Secure Communications frame, click Server Certificate.

  3. On the Welcome to the Web Server Certificate Wizard page, read the Status of your Web Server information. You'll see that you have a pending request. Click Next.

  4. On the Pending Certificate Request page (Figure 27.57), select the Process the request and install the certificate option. Click Next.

    click to expand
    Figure 27.57: Processing the Pending Request

  5. On the Process a Pending Request page, click Browse and locate the certificate you saved to your desktop. You should see the certnew.cer certificate. Select that one and click Open. Click Next.

  6. On the Certificate Summary page (Figure 27.58), review the settings and click Next.

    click to expand
    Figure 27.58: Reviewing the Settings

  7. Click Finish on the Completing the Web Server Certificate Wizard page.

The Web server certificate is now installed on the Web server. Later we'll see how to export the Web site's certificate and import the certificate into the ISA server's machine store.

Creating an Enterprise Root Certificate Server

You can create an enterprise root certificate server if you have an Active Directory domain. The advantage of using an enterprise root certificate server is that when your Web server belongs to the same domain as the certificate server, it can send the certificate request directly to the certificate server. You don't have to save the certificate request to a text file and submit it via the Web interface.

Installing the enterprise root certificate server works just about the same as installing the stand-alone certificate server. Perform the following steps to install an enterprise root certificate server:

  1. Open the Control Panel and double-click on the Add/Remove Programs applet.

  2. Click Add/Remove Windows Components on the left side of the Add/Remove Programs window.

  3. Select the Certificate Service check box in the Windows Components window. Click Yes in the dialog box warning you that you can't rename the server or leave/join a domain. Click Next.

  4. Select the Enterprise root CA option and click Next.

  5. Fill in the fields in the CA Identifying Information page. Although the only required field is the CA name, you should fill in each text box. Click Next.

  6. On the Data Storage Location page, choose where you want to store the Certificate database and Certificate database log. In this example, we'll select the default locations and click Next. Click OK in the dialog box warning you that the IIS services must be stopped.

  7. Click Finish on the last page of the wizard.

Requesting a Web Site Certificate from a Enterprise Root Certificate Server

Requesting a certificate from an enterprise root CA is much easier than from a stand-alone CA. If the Web server belongs to the same domain as the enterprise root CA, information about the CA is stored in the Active Directory, and the Web server will be able to find the CA and request the certificate directly from the enterprise root CA.

Perform the following steps to have the Web site request a certificate from the enterprise root CA:

  1. Open the Internet Information Services console and expand your server name. Right-click on your Web site and click the Properties command.

  2. In the Web site Properties dialog box, click on the Directory Security tab. Click Server Certificate in the Secure communications frame.

  3. Click Next in the Welcome to the Web Server Certificate Wizard page.

  4. Select the Create a new certificate on the Server Certificate page.

  5. Select the Send the request immediately to an online certification authority on the Delayed or Immediate Request page (Figure 27.59). Click Next.

    click to expand
    Figure 27.59: Sending the Certificate Request Directly to the Certificate Server

  6. On the Name and Security Settings page, type a friendly name for the certificate in the Name text box. Select a bit length appropriate for the level of security required for your site. Click Next.

  7. On the Organization Information page, type in the name of your organization and organizational unit in the Organization and Organizational unit text boxes. Click Next.

  8. On the Your Site's Common Name page, type in the FQDN external users use to access the site. This is the name you will use in the destination set in the Web publishing rule you'll use to publish the site. Click Next.

  9. On the Geographical Information page, type in the State/province and City/locality. Click Next.

  10. On the Choose a Certification Authority page (Figure 27.60), click the Down arrow in the Certification authorities drop-down list box and select the enterprise CA from which you want to obtain the certificate. If you have a single enterprise CA, that name will appear automatically. Click Next.

    click to expand
    Figure 27.60: Choosing a Certification Authority

  11. Review the information on the Certificate Request Submission page and click Next.

  12. Click Finish on the Completing the Web Server Certificate Wizard page, and click Finish.

The certificate is now installed on the Web server.

Exporting the Web Site Certificate and Importing the Certificate into the ISA Server Certificate Store

You need to install the Web site certificate on the ISA server so that the ISA server can impersonate the secure Web site. The Web site's certificate is installed into the ISA server's machine certificate store. You can attach the certificate to an Incoming Web Requests listener once the certificate is in the ISA server's machine store.

Getting the certificate into the ISA server's machine store is a two-step process: first, export the Web site certificate from the Web server, and then import the exported certificate into the ISA server's machine certificate store. Perform the following steps to export the Web site's certificate:

  1. Open the Internet Services Manager from the Administrative Tools menu.

  2. In the Internet Information Services console, right-click on the Web site that contains the certificate you want to export, and then click Properties.

  3. In the Web site's Properties dialog box, click on the Directory Security tab.

  4. On the Directory Security tab, click View Certificate. Click on the Details tab. Click Copy to File. This opens the Certificate Export Wizard.

  5. On the Welcome to the Certificate Export Wizard page, read the description of the wizard and what it does, and then click Next.

  6. On the Export Private Key page, select the Yes, export the private key option, and click Next.

  7. On the Export File Format page, remove the check mark from the Enable strong protection option. If you leave this option checked, you will have to enter information to confirm the certificate usage. Since the Web Proxy service needs to use the certificate in the background, you need to remove the strong protection option. Click Next.

  8. On the Password page, type in a password to secure the certificate, and then confirm the password. Don't forget the password! You'll be asked for it when you import the certificate into the ISA server's certificate store. Click Next.

  9. On the File to Export page, type in a name for the certificate, such as c:\webservercert in the File name text box. The wizard automatically adds the correct file extension (.pfx). Click Next.

  10. On the Completing the Certificate Export Wizard page, confirm that the information is correct and then click Finish. If there are no problems, you'll see a dialog box informing you that the certificate export was successful. Click OK to dispatch the dialog box.

  11. Close the Certificate dialog box and click Cancel in the Web server Properties dialog box.

Now we're ready to import the certificate into the ISA server's machine store:

  1. Copy the exported certificate to the ISA server.

  2. Click Start and then click the Run command. Type mmc in the Open text box and click OK.

  3. Click the Console menu and then click the Add/Remove Snap-in command.

  4. On the Stand-alone tab, click Add in the Add/Remove Snap-in dialog box.

  5. In the Add Stand-alone Snap-in dialog box, select the Certificates entry and then click Add.

  6. On the Certificates snap-in dialog box, select the Computer account option. It's important that you select the Computer account option because you want the certificate in the machine's certificate store. The most common error ISA Server administrators make is to select the wrong option and import the certificate into the user account's certificate store. Select the Computer account option and click Next.

  7. On the Select Computer page, select the Local computer: (the computer this console is running on) option and click Finish.

  8. Click Close in the Add Stand-alone Snap-in dialog box, and then click OK in the Add/Remove Snap-in dialog box.

  9. Expand the Certificates (Local Computers) node and then right-click on the Personal node. Point to All Tasks and then click on the Import command.

  10. On the Welcome to the Certificate Import Wizard, read the description of what the wizard does, and click Next.

  11. On the File to Import page, click Browse to find the Web server certificate that you copied to the ISA server. Click Next after selecting the certificate.

  12. On the Password page, type in the Password you assigned to the certificate. Put a check mark in the Mark the private key as exportable check box. This will make your life a bit easier if you need to export the key and use it on another machine. Click Next.

  13. On the Certificate Store page (Figure 27.61), select the Place all the certificates in the following store option. The Certificate store should read as Personal. Click Next.

    click to expand
    Figure 27.61: The Certificate Store Page

  14. Read the settings on the Completing the Certificate Import Wizard page and then click Finish. If all goes well, you'll see a dialog box confirming that the import was successful. Click OK to dispatch the dialog box.

  15. Refresh the display. You should now see the certificate in the list of certificates in the machine's certificate store (Figure 27.62).

    click to expand
    Figure 27.62: Certificates Contained in the ISA Server's Machine Store

  16. Minimize the Certificates console and open the ISA Management console. Right-click on your server name and click Properties.

  17. On the server's Properties dialog box, click on the Incoming Web Requests tab. On the Incoming Web Requests tab, select the Configure listeners individually per IP address option, and then click Add.

  18. On the Add/Edit Listeners dialog box (Figure 27.63), select your server name in the Server drop-down list box. Select an IP address on the external interface of the ISA server in the IP Address drop-down list box. Type in a short name for the listener in the Display Name text box. Put a check mark in the Use a server certificate to authenticate to web clients check box.

    click to expand
    Figure 27.63: Selecting the Web Site Server Certificate

  19. On the Add/Edit Listeners dialog box, click Select. In the Select Certificate dialog box (Figure 27.64), select the Web server certificate and click OK. The certificate will show up in the Add/Edit Listeners dialog box. Click OK in the Add/Edit Listeners dialog box.

    click to expand
    Figure 27.64: Selecting the Web Site Server Certificate

  20. Click Apply in the server Properties dialog box. A warning dialog box appears and informs you that the Web Proxy service will need to be restarted. Select the option that works best for you, and click OK.

Now with the certificate attached to the Incoming Web Request listener, you are in the position to securely publish the Web site. You can publish the Web site so that the SSL connection terminates at the ISA server's external interface, or you can protect the information using SSL from the client to the internal Web server by forcing an SSL connection between the ISA server and the internal Web site. This is called SSL bridging, which we discuss in the next section.

Bridging SSL Connections

ISA Server supports SSL bridging, and can bridge incoming SSL requests in two ways:

  • The incoming SSL request can be bridged as an HTTP request.

  • The incoming SSL request can be bridged as an SSL request.

When ISA Server bridges an SSL request as an HTTP request, the SSL connection is terminated at the Incoming Web Requests listener. The ISA server receives SSL packets, decrypts the packets, and forwards them to the Web server on the internal network as HTTP. SSL protects data between the client and the external interface of the ISA server; the data is sent "in the clear" between the internal interface of the ISA server and the Web server on the internal network.

You might think its safe to send the data between the internal interface of the ISA server and the internal network Web server unencrypted if you trust the internal network,. However, if you don't completely trust the transit network between the ISA server and the Web server, you should protect that data as well.

You can protect data moving between the ISA server and the publishing Web server by bridging SSL requests as SSL requests. In this scenario, the Internet client establishes an SSL link with the ISA server's Incoming Web Requests listener. The data is decrypted by the ISA server after it is received by the listener. Then, the ISA server creates a second SSL connection between the internal interface of the ISA server and the publishing Web server. The data is re-encrypted and sent to the Web server over the secure SSL link.

In the following sections, we look at how to bridge the SSL connection as HTTP, and then how to bridge the connection as SSL.

Bridging SSL Connections as HTTP

You're ready to create a Web publishing rule that bridges an SSL connection as HTTP when the Web server's certificate is bound to the incoming Web Requests listener. Now all that's left to do is create the Web publishing rule:

  1. Open the ISA Management console, expand your server name, and then expand the Policy Elements node. Right-click on Destination Sets, point to New, and click Set.

  2. Type a name for the set in the Name text box. Type a description for it in the Description text box. Click Add.

  3. In the Add/Edit Destination text box, select the Destination option and type in the FQDN for the Web site in the text box. Remember that this is the FQDN the external network users use to access your site. This FQDN must also match the name on the Web site certificate you bound to the Incoming Web Requests listener. Click OK. You'll see the completed destination set information in Figure 27.65. Click OK to complete the set.

    click to expand
    Figure 27.65: A Completed Destination Set

Now that the destination set is completed, you're ready to create the Web publishing rule. To do so, perform the following steps:

  1. Expand the Publishing node and right-click on the Web Publishing Rule node. Point to New and point to Rule.

  2. On the Welcome to the New Web Publishing Rule Wizard page, type in a name for the publishing rule in the Web publishing rule name text box. Click Next.

  3. On the Destination Sets page, select the Specified destination set option in the Apply this rule to drop-down list box. Select the name of your destination set in the Name drop-down list box. Click Next.

  4. On the Client Type page, select the Any request option. Click Next.

  5. On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address) option. Enter either the IP address or the name of the server on the internal network. We recommend that you create a split DNS infrastructure, or put a HOSTS file entry for the FQDN used in the destination set. Enter that FQDN in the redirect. Using the FQDN in the redirect will make your log files cleaner and prevent the dreaded 14120 error from littering your application log in the Event Viewer. You can choose to send the original host header if you like; it won't matter if you're using the same name in the redirect as that contained in the original host header. Click Next.

    click to expand
    Figure 27.66: The Rule Action Page

  6. Review the settings on the Completing the New Web Publishing Rule Wizard page, and then click Finish.

  7. In the right pane of the console, right-click on the Web publishing rule you just created and click Properties. Click on the Bridging tab. In the Redirect HTTP requests as frame, make sure the HTTP requests option is selected. Of course, this selection won't matter, because we're going to force SSL connections in this rule. In the Redirect SSL requests as frame, select the HTTP requests (terminate the secure channel at the proxy) option. This allows you to bridge incoming SSL requests as HTTP requests. Put a check mark in the Require secure channel (SSL) for published site check box. This check box forces users to use SSL to connect to the Web site. You can select the Require 128-bit encryption option if your clients support it. Click Apply and then click OK.

Go to an external network client and make the connection. If the external network client has a certificate from your CA, and the CA that issued the Web site certificate is in your enterprise trust list, you won't see anything unusual, and you'll make the connection with the ISA server without incident. You won't see any warning dialog boxes regarding the nature of the certificate.

You'll see what appears in Figure 27.67 if the client doesn't have the CA that issued the Web server's certificate in its enterprise trust list, . The error indicates that you don't trust the CA that issued the Web site's certificate. This is most commonly seen when you "roll your own" certificate server solution. You can avoid this by assigning user or machine certificates. In the process of obtaining the certificate from the certificate server, the CA you receive the certificate from will be placed in the Trusted Root Certificate Authorities list. If you don't want to assign certificates to the users or machines, you can copy the certificate server's certificate into your clients' Trusted Root Authorities list manually.

click to expand
Figure 27.67: Security Alert Dialog Box Warning of an Untrusted Root Authority

Another problem you might have is with the name of the certificate. In Figure 27.68, note that everything is okay except that The name on the security certificate does not match the name of the site. This is probably one of the most common errors we encounter when troubleshooting SSL Web publishing rules. You'll see this if the name on the certificate is not the same as the FQDN used by users to access the Web site. The only fix for this problem is to obtain a new certificate that has a name that matches the FQDN used to access the site. This is why it's so important that you make the proper entry for the "common name" of the Web site when you make the Web site's certificate requests.

click to expand
Figure 27.68: Security Alert Dialog Box Warning of a Certificate Mismatch

Bridging SSL Connections as SSL

What if you need to protect the data end to end? You might not trust your internal network, so you need to protect the data on the Internet and you need to protect it from the internal interface of the ISA server to the Web site on the internal network. This might be the case when the internal network is actually a private address DMZ segment. In this scenario, the Web publishing rule is configured in very much the same way, except for the choice in the SSL bridging frame.

You also have to be mindful of how the Web site is configured, because if it is configured incorrectly, the ISA server will not be able to bridge the request. To successfully bridge SSL connections as SSL connections, you need to do the following:

  • Prepare the Web site for SSL

  • Configure the Web publishing rule

Let's first look at how to prepare the Web site. If you're already expert at configuring SSL Web sites, you can skip to the section on how to configure the Web publishing rule. In this example, we'll assume that you've already bound a certificate to the Web site and exported that certificate and bound it to the external interface of the ISA server.

  1. From the Administrative Tools menu, click on the Internet Services Manager link.

  2. In the Internet Information Services console, right-click on the Web site you're publishing and click the Properties command.

  3. In the Web site's Properties dialog box, click on the Directory Security tab.

  4. On the Directory Security tab, click Edit. This brings up the Secure Communications dialog box (Figure 27.69). Put a check mark in the Require secure channel (SSL) check box. This requires the ISA server to establish an SSL connection with the Web site. Put a check mark in the Require 128-bit encryption check box if you want to force strong encryption (the ISA server will support it). You can also force the ISA server to use a client certificate to authenticate with the Web site, although this is not required. If you want to force the use of a client certificate, select the Require client certificates option. If you want the option to use a certificate, but allow non-client certificate connections too, select the Accept client certificates option. This option allows you to use other means of authentication (other than client certificates). We won't cover client certificate mapping for Web sites in this chapter, but check www.isaserver.org/shinder for an article on how to do this. For the greatest flexibility, select the Accept client certificates option. Click OK.

    click to expand
    Figure 27.69: Forcing a Secure Channel to the Web Site

  5. Click Apply and then click OK in the Web site Properties dialog box. Click Stop in the MMC button bar, and then click Start in the button bar.

If you want to use client certificates to authenticate against the Web server, you'll need to assign a certificate to the Web Proxy service. The Web Proxy service will act as the client of the internal network Web server. The funny thing about assigning a certificate to the Web Proxy service is that the service can't directly request a client certificate. What you can do is use the machine certificate by copying it to the Web Proxy service's machine store.

Perform the following steps to assign the machine's certificate to the Web Proxy service:

  1. Click Start and then click Run. In the Run dialog box, type mmc and click OK.

  2. In the console window, click the Console menu and click the Add/Remove Snap-in command. In the Add/Remove Snap-in dialog box, click Add.

  3. In the Add Stand-alone Snap-in dialog box, select the Certificates entry and click Add. In the Certificates snap-in dialog box, click the Service account option and click Next.

  4. On the Select Computer page, select the Local computer option and click Next.

  5. On the Select a service account to manage on the local computer page, select the Microsoft Web Proxy entry and click Finish.

  6. We need to add a second instance of the Certificates snap-in. Select the Certificates entry and click Add. On the Certificates snap-in page, select the Computer account option and click Next.

  7. On the Select Computer page, select the Local Computer option and click Finish.

  8. Click Close in the Add Stand-alone Snap-in dialog box. Click OK in the Add/Remove Snap-in dialog box.

  9. Expand both of the Certificates nodes in the left pane of the console. Expand the Personal node for both the Local Computer and the W3Proxy services (Figure 27.70).

    click to expand
    Figure 27.70: The Web Proxy Service Certificate List

  10. Click on the Local Computer\Personal\Certificates node. In the right pane of the console, you'll see the computer certificate. Right-click on your computer certificate and click the Copy command.

  11. Click on the Microsoft Web Proxy Service\W3Proxy\Personal\Certificates node. Click in the right pane of the console. Next, right-click on the right pane of the console and click the Paste command. This pastes the computer certificate into the Web Proxy service's personal store.

The Web Proxy service now has a certificate it can present to the internal Web server in the event that you configure the Web server on the internal network to require client certificate authentication.

The last step is to configure the Web publishing rule to support SSL-to-SSL bridging:

  1. In the ISA Management console, expand your server name and then expand the Publishing node. Right-click on the Web Publishing Rules node, point to New, and click New.

  2. Type in a name for the rule on the Welcome to the New Web Publishing Rule Wizard page and click Next.

  3. On the Destination Sets page, select the Specified destination set option and then select the destination set for your site. Click Next.

  4. On the Client Type page, select Any request and click Next.

  5. On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address) option. Type in the name of the site, which is the same name on the site certificate and the same name used in the destination set (Figure 27.71).

    click to expand
    Figure 27.71: Configuring the Rule Action

  6. Click Finish on the last page of the wizard.

  7. In the right pane of the ISA Management console, double-click on the new rule. Click on the Bridging tab.

  8. In the Redirect SSL requests as frame, select the SSL requests (establish a new secure channel to this site) option. Select the Require secure channel (SSL) for published site check box. If you want the ISA server to use a client certificate to authenticate with the Web server, select the Use a certificate to authentication to the SSL Web Server check box. Click Select. You'll be presented with the Select Certificate dialog box (Figure 27.72). The certificates you see listed in this dialog box are those included in the Web Proxy service's personal certificate store. Select the certificate and click OK.

    click to expand
    Figure 27.72: Assigning a Client Certificate for the SSL Bridge

  9. The name of the client certificate will appear in the rule's Properties dialog box. Click Apply and then click OK. Note that you do not need to perform certificate mapping for this to work. You do not need to create a one-to-one or many-to-one certificate mapping; the Web Proxy service will be able present the ISA server's machine certificate in order to authenticate to the Web site automatically.

Go to an external network client and connect to the published Web site. You'll be able to connect just as you did when you create the SSL-to-HTTP bridging. If everything is configured correctly, you won't see any warning dialog boxes and you'll have direct access to the site.

Just for fun, you might want to confirm that the ISA server is indeed sending a client certificate to authenticate with the Web site. If so, do the following:

  1. Configure the Web site to require certificate authentication. Next, go to a client on the internal network that doesn't have a user certificate installed. What we want to determine is whether the Web site will accept requests from browsers without a certificate.

  2. Type http://IPADDRESS of the Web site that requires certificate authentication. The Security Warning dialog box should appear, telling you that the name on the certificate doesn't match the request (see Figure 27.73). This is expected, since the Web site's certificate has the FQDN of the site, not its IP address. Click Yes to get past that dialog box.

    click to expand
    Figure 27.73: Security Alert Dialog Box Warning of a Name Mismatch

  3. Internet Explorer pops up a Client Authentication dialog box because the Web site is configured to require client certificates for authentication (Figure 27.74),. If your browser had a certificate configured on it, you would see the name of the certificate in this dialog box. Click OK to close the Client Authentication dialog box.

    click to expand
    Figure 27.74: The Client Authentication Dialog Box

  4. After closing the authentication dialog box, you'll see the The page requires a client certificate Web page (Figure 27.75). HTTP error 403.7 indicates that you need a client certificate to access the site and that you did not present a certificate and therefore are denied access.

    click to expand
    Figure 27.75: Error Page Indicating that a Client Certificate Is Required

Secure FTP Connections Using SSL

Secure publishing of FTP requires you use Web publishing rules. You can only use the basic authentication protocol when you publish an FTP site using a server publishing rule. In addition, you can't protect the data using the FTP protocol.

The solution is to publish the FTP site using a Web publishing rule. You can configure the Web publishing rule to require an SSL connection and then redirect the SSL link as an FTP request. The FTP server on the internal network receives the request from the ISA server and returns the FTP data to the internal interface of the ISA server. The ISA server encrypts the data and returns it to the client. Note that the client must use a Web browser and the HTTPS protocol to access the secure FTP site via the Incoming Web Requests listener.

We have already reviewed most of the procedures required to make secure FTP server publishing work:

  • Bind a certificate to the Incoming Web Requests listener that matches the name users use to access the site.

  • Configure the Web publishing rule to redirect SSL requests as FTP requests.

  • Train the users to use HTTPS to access the site, or create a Web page that redirects FTP downloads to HTTPS requests.

You saw how to bind the certificate to the external interface earlier in this chapter. For more information on how to bind certificates to the Incoming Web Requests listener, review the section on SSL bridging.

Creating a Web publishing rule to forward SSL requests as FTP requests is very similar to the rules you created in the SSL bridging scenarios covered earlier. The only difference is the setting on the Bridging tab of the rule (Figure 27.76). You need to enable the Require secure channel (SSL) for published site check box, and you can choose the Require 128-bit encryption check box if your clients support this option. Note that the client certificate check box is disabled and the Select button is grayed out. The reason for this is that you can't use certificates to authenticate with an FTP site.

click to expand
Figure 27.76: Redirecting SSL Requests as FTP Requests

The browser will show a list of files on the FTP site when you connect to the site (Figure 27.77). Notice that you have to use HTTPS in the URL; when the connection is established, a "lock" icon appears in the status bar of the browser.

click to expand
Figure 27.77: Connecting to the FTP Site

Publishing a Certificate Server

You might want to publish your certificate server. This is a good idea for two reasons:

  • External network clients can access the certificate server's Web enrollment site from the Internet.

  • The certificate revocation list (CRL) is available to Web clients.

You might want to publish the certificate server if you want users to access the Web enrollment site to obtain a client certificate from the certificate server. The user must be a member of the domain to request a user certificate from an enterprise certificate server. If the request is made to a stand-alone root certificate server, the user will have to wait for you to approve the certificate request (this is the default setting).

Another reason why you might want to publish the certificate server is to make the CRL available to external network users. One reason for poor SSL performance is that the client can't access the CRL. You can fix this problem by publishing the CRL.

Perform the following steps to make the CRL available to external network clients:

  1. Open the Internet Services Manager from the Administrative Tools menu.

  2. In the Internet Information Services console, expand the Default Web site node and right-click on the CertEnroll virtual directory. Click Properties.

  3. Click on the Virtual Directory tab and put a check mark in the Directory browsing check box. Click Apply and then click OK.

  4. Now let's check what the default URL is for the CRL. On the certificate server, click Start and then click Run. Type mmc in the Open text box and click OK. In the console, click on the Console menu and click the Add/Remove Snap-in command.

  5. In the Add/Remove Snap-in dialog box, click Add. In the Add Stand-alone Snap-in dialog box, click the Certificates entry and click Add. On the Certificates snap-in page, select the Computer account option and click Next.

  6. On the Select Computer page, select the Local computer option and click Finish. Click Close in the Add Stand-alone Snap-in dialog box. Click OK in the Add/Remove Snap-in dialog box.

  7. In the left pane of the console, expand the Certificates node and then expand the Personal node (Figure 27.78). Click on the Certificates node. In the right pane of the console, double-click on the certificate that lists <All> for Intended Purposes.

    click to expand
    Figure 27.78: The Certificates List

  8. In the Certificate dialog box, click on the Details tab. Scroll through the list of fields and find the CRL Distribution Points entry (Figure 27.79). This is the URL you need to make available to external network users. In this example, the URL is http://clientdc.internal.net/CertEnroll/enterprisecert.crl. The FQDN in this URL must be accessible to external network clients; therefore, you need to enter this information into the public DNS. Close the Certificate dialog box.

    click to expand
    Figure 27.79: CRL Distribution Point Information

  9. Go to the ISA Server machine. Create a destination set for the FQDN listed in the CRL. You also must create an entry in the public DNS that resolves the FQDN listed in the CRL to the external IP address of the ISA server used by the Incoming Web Requests listener. If you want to further limit access, you can enter the path /CertEnroll to the destination set.

  10. Create a Web publishing rule to publish the CRL using the destination set you created in step 9.

  11. You also need to make the certificate chain information available to the external network clients. The certificate chain is contained in the same folder as the CRL, so you shouldn't have to create a separate Web publishing rule to support this.

Your biggest challenge in publishing the CRL and the certificate chain information (contained in the root certificate) is to match the URL information in the certificate to that which is accessible to external network clients. You will need to create a split DNS infrastructure if the certificate server is an enterprise root or enterprise subordinate server. If the certificate server is a stand-alone root, you will have problems if only the NetBIOS name is contained in the URL.

You can add CRL Distribution Point and Authority Information Access (used to confirm the certificate chain) URLs in the Certificate Authority console.




The Best Damn Firewall Book Period
The Best Damn Firewall Book Period
ISBN: 1931836906
EAN: 2147483647
Year: 2003
Pages: 240

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net