Publishing Multiple Web Roots with a Path Statement, Part 2

Publishing Multiple Web Roots with a Path Statement, Part 2

By Thomas W Shinder M.D.

In the first part of this two part article, I introduced the topic of publishing multiple Web sites using a single IP address and single domain name, but a different path statement in the URL. If you missed the first part or need a refresher, head on over to http://www.isaserver.org/tutorials/multiwebpubpart1.html and first part 1. In this second and final part of the two part article I’ll go over how to create and configure the Web sites on Internet Information Server 5.0 (IIS 5.0) and DNS issues you need to address so that external network clients can access your sites.

There’s a good chance that someone else has probably already created the Web sites for you. If you have to play both Web server and firewall administrator, then you might have to create the Web sites yourself. Creating new Web sites is very easy if you use Internet Information Server 5.0 (IIS 5.0). The only requirement from the firewall point of view is that each site have a different IP address (at least in the scenario that we’re discussing today, you could use different port numbers).

It’s very important to remember that the ISA Server isn’t going to protect you from everything that comes from the Internet into your Web server. While the ISA Server can perform content inspection and protect against many different types of exploits, the ISA Server does not replace host based security. You need to harden the Web server based on the Web server’s role. Fortunately, you can secure your Web server to a fairly high level even if you’re not a Web site security specialist. The IISLockdown tool and URLScan can do the heavy lifting for you. Check out these tools at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=DDE9EFC0-BB30-47EB-9A61-FD755D23CDEC

You must bind all the IP addresses you need to the Web server computer before you being assigning these addresses to the Web sites. Remember that the Default Web Site and the Administration Web Site also need an IP address; they can share the same IP address but you do not want them to share an address with any of your other sites. While you have the option to create all your Web sites to listen on “all addresses” before assigning them to a specific IP address, I highly recommend that you bind the IP addresses to the network interface before you create the sites. By adding the IP address first, you’ll be much less likely to forget something important.

Perform the following steps to create a new Web site after you’ve bound the IP addresses to the Web server’s interface:

1. Open the Internet Information Services console from the Administrative Tools menu.
   
2. Expand your server name. Right click on the Default Web Site and click Properties.
   
3. Click on the Web Site tab in the Default Web Site Properties dialog box. Notice that the IP Address setting is set to [All Unassigned] by default. Click the down arrow and select an IP address for the Default Web Site to use. Select the address then click Apply and then click OK.
   
4. Repeat this procedure at the Administration Web Site.
   
5. Right click on the Default Web Site, point to New and click on Site.
   
6. Click Next on the Welcome to the Web Site Creation Wizard page.
   
7. On the Web Site Description page, type in a name for the site. This is the name that will appear in the left pane of the console. Click Next.

8. On the IP Address and Port Settings page, select the IP address you want to use for the site in the Enter the IP address to use for the Web site drop down list box. Leave the TCP port this web site should use at 80. You’re not doing any port redirection, so you don’t want to use an alternate port number. Click Next to continue.

9. On the Web Site Home Directory page, type in the path to the folder where you want the Web site to live on the hard disk. The wizard will not create the folder for you, so if you forgot to create the folder, you can leave the dialog box as it is and open the Windows Explorer to create the new folder After creating the folder, return to the dialog box and type in the path. Click Next.

10. On the Web Site Access Permissions dialog box, leave the default settings or change them depending on your requirements. Your requirements are determined by the goals and functions of your site. Click Next to continue.
    
11. Click Finish on the You have successfully completed the Web Site Creation Wizard page.

In this scenario, we need to create three sites, called Web10, Web11 and Web12. The figure below shows what the console looks like after creating the three sites.

Now that you have the Web sites, you can create the subfolders used for the path-based redirection. For example, for Web10, we need to create a subdirectory in the root folder for Web10 named web10. After you create the subfolder in the physical directory, you can return to the Internet Information Services console and configure the redirection on that folder to the Web root.

1. Open the Windows Explorer and create the subdirectory for the redirect. In our example, we want users to be able to type www.internal.net/web10 to receive the redirect to the root of the Web10 site. You can see the subdirectories used for the redirection in the figure below.

2. Return to the Internet Information Services console. Click the Refresh button in the console’s button bar. You should now see the directory you just created in the right pane of the console. Right click on that directory and click Properties.
   
3. Click on the Directory tab. Click on the A redirection to a URL option. Type in the URL that you want to use for the redirect in the Redirect to text box. Note that the FQDN has to be exactly the same as the one you used into the Destination Set for the Redirect Web Publishing Rule you created for the site. In this example, when users connect to the web10 subdirectory on this web site, they will be sent a redirect that tells them to request the default document at http://www10.internal.net. Do not select The exact URL entered above option unless you want to limit users to the default document at the redirected site. For example, if a user typed http://www.internal.net/web10/stuff.txt in the browser, the redirect would be to http://www10.internal.net if you select the exact URL option. However, if you do not select that option (which I recommend), when a user tries to access http://www.internal.net/web10/stuff.txt, they will be redirected to http://www10.internal.net/stuff.txt. You can select the A permanent redirection for this resource to improve performance on busy sites. Click Apply and then OK after making the changes.

4. After making the changes you’ll see the subdirectory used for the redirect in the right pane of the console and it shows that requests to that directory are redirected to the URL of your choice. This is the key setting that allows you to redirect to the root of the site. This redirect works together with the Web Publishing Rule you created earlier.

5. Stop and start the Web site using the stop and start buttons in the button bar in the console.
   
6. Repeat this procedure with your other Web sites. In this example, we’re publishing three different sites, so we need to create the redirects for the subfolders in Sites Web11 and Web12.

You’re almost done. You’ve configured the Incoming Web Requests listener, the Destination Sets, the Web Publishing Rules and the Web sites. There’s only one thing left for you to do: create the DNS records the external users need to access your primary and redirect sites.

Let’s take another look at our scenario diagram:

The external network clients need to be able to resolve the names:

The first entry is required for the primary connections (www.internal.net/web10, etc). The three Web Publishing Rules we created for the primary connections can use the first DNS entry, since the primary connections are always to www.internal.net. However, we need three different DNS entries for the redirects, because the redirects are to three different host names (within the same domain as the primary connection, in this example).

All of the Host (A) entries map to the same IP address, which is the single IP address bound to the external interface of the ISA Server; this address is used by the Incoming Web Requests listener. You don’t have to do it this way, but there’s no reason not to. This method allows you to preserve you public IP addresses for Server Publishing Rules, in the event that you might need to use them in the future. The great thing about Web Publishing Rules is that you can publish 5000 Web sites using a single IP address on the external interface of the ISA Server!

Keep in mind that the Host (A) entries have to be created on a public DNS server. It won’t do you any good at all to put these entries on your private network’s DNS server. The records must be accessible to external network clients. The public DNS server can be hosted by your ISP, by your friend’s DNS server, or you can publish your own DNS server. What’s important is that external network clients are able to access the DNS server authoritative for the domains you’ve included in the Destination Sets.

The ISA Server is configured, the Web sites are set up, and the DNS host records are in place. Let’s look at the details of what happens when the external clients make the request.

1. The external client makes a request for http://www.internal.net/web10 using Internet Explorer.
   
2. The request is intercepted by the Incoming Web Requests listener at IP address 1.1.1.1. The Incoming Web Requests listener passes the request to the Web Proxy service. The Web Proxy service looks at the HTTP header and finds the request is for www.internal.net/web10. The Web Proxy service compares this request string with the entries in the Destination Sets contained in all the Web Publishing Rules. Web Publishing Rules are arranged in hierarchical order, so the one on top is evaluated first. The first rule that contains a Destination Set with an entry www.internal.net/web10 is a match. The matched Web Publishing rule tells the Web Proxy service to forward the request to the http://10.0.0.10/web10
   
3. The Web site at 10.0.0.10, which is Web10, detects the incoming request to its /web10 directory.
   
4. The internal Web server sends back to the requesting client a redirect, telling the Web client to go to www.10.internal.net.
   
5. The external client sends a request for www10.internal.net
   
6. The Incoming Web Requests listener intercepts the request for www10.internal.net and forwards it to the Web Proxy service. The Web Proxy service compares the string www.internal.net in the request with the entries in the Destination Sets used by the Web Publishing Rules. The highest ranked Web Publishing Rule that contains www.interal.net in its Destination Set is triggered and is configured to redirect the request to http://10.0.0.10

In this two part article we went over the procedures required to publish multiple Web sites using the same FQDN, but different paths within that domain. The procedure is fairly straightforward, with the key element being the differentiation of the primary and redirect connections. You first create Destination Sets for the primary and redirect connections, then you create Web Publishing Rules based on those Destination Sets. The Web sites are configured so that when a user connects to a specific folder on the Web site, the user receives a redirect to the root of the same site, but via an alternate FQDN. While we used the same Web site for the redirect in this example, there is nothing preventing you from redirecting to an entirely different site.

I hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything I discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=5;t=001383 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom