IIS Insider - December 2002

  • Article

By Brett Hill

Ports to Open When Configuring IIS Server for Use in the DMZ

Q: We are planning on using IIS servers inside a DMZ to deliver content to the internet. Can you tell us what ports we need to open on our external firewall to allow for the various kinds of authentication in IIS?

A: Authentication on IIS typically utilizes only the ports that you use to deliver the files and applications from IIS. By default, those are TCP ports 80 for HTTP and 443 in the event of an SSL connection. You can assign different port numbers, but if you didn't then those are the only ports your external firewall require, regardless of the authentication type(s) you selected within IIS (with one exception which I'll cover in a moment).

When I configure an IIS server for use in the DMZ, I start with the presumption that the only open ports necessary for access to the server are 80 and 443. This generally launches a healthy conversation on exactly what ports need to be opened to support this specific web server, applications, and networking infrastructure. IIS itself, however, requires only the ports assigned to the websites and nothing else. There are plenty of reasons why other ports may need to be open to support SMTP, DNS, Terminal Services and other commonly used capabilities of an IIS running on a Windows Server platform.

The exception I spoke of has to do with Kerberos. IIS 5 on Windows 2000 Server and IIS 6 on Windows Server 2003 are capable of using Kerberos to authenticate traffic to an IIS server. Kerberos is not suitable for internet traffic so in no event should you find yourself trying to open an external firewall for Kerberos traffic. You can find a list of ports in use on Windows 2000 at https://www.microsoft.com/resources/documentation/exchange/2000/all/reskit/en-us/resguide/appendb.mspx, and also review How to Configure a Firewall for Domains and Trusts at https://support.microsoft.com/default.aspx?scid=kb;en-us;179442&sd=tech.

More About Installing IIS in Windows XP

Q: On Windows XP Home, how do I install IIS? Where do I download IIS for Windows XP Pro?

A: This question was addressed in the December 2001 edition of IIS Insider, but since this and related questions about IIS versions are still very common, I thought it would be good to address it in a little more detail. In particular there have been a lot of questions about IIS running on Windows XP, so here's a rundown of the version of IIS and how they correlate to operating systems:

  • IIS 4 – Windows NT 4.0
  • Personal Web Server – Windows NT 4.0 Workstation
  • IIS 5 – Windows 2000 Server (all versions)
  • IIS 5 – Windows 2000 Workstation (client version with limited capability)
  • IIS 5.1 – Windows XP Professional
  • IIS 6 – Windows Server 2003 (all versions)

The following rules address the most common questions about the above list:

  1. The version of IIS designed to run on its host operating system cannot be installed on any other operating system. For example, IIS 6 cannot be installed on Windows 2000 and IIS 5 cannot be installed on Windows NT 4. This is the result of tight integration of IIS with its specific operating system;consequently it is not operating system independent.
  2. IIS 5.1 is not supported or provided on Windows XP Home Edition. IIS 5.1 cannot be downloaded, purchased separately, or ordered on a CD-ROM. IIS 5.1 is provided and supported with Windows XP Professional and you can install it from Control Panel-Add/Remove Programs/Add Remove Windows Components. IIS 5.1 is a client operating system and is for development or very small intranets. It has some built-in limitations, however, and is not designed to be used as a server.
  3. The client versions of IIS are the PWS, IIS 5.1 and IIS 5.0 on Windows 2000 Professional. These versions of IIS do not have the ability to support more than one website and are limited to 10 simultaneous connections. There are no registry modifications or updates that increase these capabilities.
  4. With the exception of IIS 4, all versions of IIS are provided on the Operating System CD. You cannot download them from the Microsoft web site. IIS 4 is provided with the Windows NT 4 Option Pack and can be found at https://www.microsoft.com/ntserver/nts/downloads/recommended/NT4OptPk/default.asp.

To Authenticate or Not When Accessing the Default Web Site

Q: After installing IIS on Windows 2000 or XP, I launch Internet Explorer and check to see if the installation completed successfully. To do this I access the Default Web Site with https://localhost and it works fine. However, if I type in https://127.0.0.1 I am prompted to authenticate. Why am I prompted for credentials in one case and not the other?

A: This behavior is expected, and has to do with Internet Explorer's server accessing management and the configuration of the Default Web Site. As described in the June 2002 edition of IIS Insider ('Localstart.asp Is "Under Construction"), the Default Web Site is configured such that the file IISSTART.ASP is invoked if there is no default.htm or default.asp. If IISStart.asp thinks that you have asked for access from a local IP address, and certainly typing https://localhost or https://127.0.0.1 would qualify, then the request is redirected to Localstart.asp as follows:

<% Response.Redirect "localstart.asp" %>

This results in IIS sending the following information to Internet Explorer.:

HTTP/1.1 302 Object moved Server: Microsoft-IIS/5.0 Date: Thu, 09 Jan 2003 23:30:03 GMT Location: localstart.asp Connection: Keep-Alive Content-Length: 135 Content-Type: text/html Set-Cookie: ASPSESSIONIDGQQGQWNC=FOFJMOPCDFNCDALAEPMEGKNF; path=/ Cache-control: private <head><title>Object moved</title></head> <body><h1>Object Moved</h1>This object may be found <a HREF="localstart.asp">here</a>.</body>

Internet Explorer then requests localstart.asp as directed. What happens next depends on how you make your request to the Default Web Site. If you use https://localhost, everything works fine presuming you are logged on as a user with permissions sufficient to access the content. If you use https://127.0.0.1, however, you will be prompted to authenticate.

This can seem confusing since the authentication methods enabled for the Default Web Site are Anonymous and Integrated Windows authentication. Since Anonymous authentication is enabled, and everyone has Read and Execute permissions by default, there should be no prompt at all! Closer inspection reveals that localstart.asp is configured differently than the rest of the Default Web Site; Anonymous authentication is disabled while Basic and Integrated Windows are enabled.

Consequently, to successfully run localstart.asp you will have to authenticate to the server as something other than the IUSR account. This occurs automatically when you use Internet Explorer, if Internet Explorer thinks you are requesting a server on your intratnet such as https://research or https://betacode. In this event, Internet Explorer will log you onto IIS using the credentials entered when you logged onto your computer. If Internet Explorer thinks you are requesting an Internet site, however, you are prompted for security reasons to enter your username and password instead of being automatically logged on. This prevents malicious web sites from harvesting authentication session network traffic with an eye to cracking passwords.

This may not seem to apply since you are using https://127.0.0.1 to access the Default Web Site, but Internet Explorer uses the following rule to determine if the site is local or non-trusted ;'if there is a dot in the URL, it is not local'. Consequently, https://localhost works without a prompt and https://127.0.0.1 results in a prompt.

You can avoid the prompt on the IP address or intranet server that have been deployed with a . in the name, by listing the servers IP address or name that contains a . in the Local Intranet section of Internet Explorer. The Local Intranet section can be found from Tools, Internet Options, Local Intranet, Sites, Advanced. Then enter https://127.0.0.1 or other relevant site URL in the box title Add this web site to the zone.'

Submit your questions to the IIS Insider. Selected questions along with the answers will be posted in a future IIS Insider column.

For a list of previous months questions and answers on IIS Insider columns, click here.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as is," without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.