IIS Insider - April 2006

By Ken Schaefer, Systems Engineer Consultant, Avanade

IIS Insider is a monthly column designed to answer your questions on how to troubleshoot and make the most of Microsoft Internet Information Services (IIS).

The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real companies, organizations, products, domain names, e-mail addresses, logos, persons, places, or events are intended or should be inferred.

Authentication Mechanisms

Fac1

Q. I want to secure access to my Web site by requiring my users to authenticate with their Windows credentials. I am going to disable anonymous access, but I'm unsure what other authentication options I should use. In the Authentication Methods dialog, I see Basic, Digest, Integrated Windows Authentication and .NET Passport Authentication as described here: .NET Passport Authentication in IIS 6.0. I am using IIS 6.0.

A. IIS 6.0 includes a number of authentication options as you have discovered. Some are open standards and others are proprietary Microsoft technologies. Each has different strengths, and what you select will depend very much on the nature of your environment and the types of clients that you need to support.

See full-sized image

Basic Authentication
Basic Authentication is the simplest of all the supported authentication options. It was originally defined in the HTTP v1.0 specification. You can find the current specifications in RFC2617.

Basic Authentication has the client (the Web browser) sending the user's credentials (user name and password) as Base64 encoded data, which is virtually the same as clear text (unencrypted) as Base64 encoding is not encryption. It is easy to decode using any number of widely available tools.

Because Basic Authentication is such a simple authentication mechanism and has been around for a significant amount of time, it is supported by every modern browser and is easily implementable in any non-browser client (if your Web site is being accessed by some kind of automated tool). However, because Basic Authentication itself doesn't implement anything to secure the user name and password from anyone sniffing network traffic, you will need to use some other technology to protect these.

The most common options include using SSL (Secure Sockets Layer) or a VPN (Virtual Private Network). Both of these technologies encrypt traffic in transit between their end points. Microsoft's KB Article 299875 provides step-by-step instructions on configuring SSL with IIS 6.0. You may also want to look at the Microsoft guide to Configuring SSL Host Headers.

Microsoft discusses authentication strategies in the following webcast that also provides a high-level overview of other authentication types discussed later in this column:

The Ins and Outs of Authentication in Internet Information Services

Digest Authentication
Digest Authentication is also documented in RFC2617. It has been designed to improve the security offered by the Basic Authentication system. It allows the server to specify an encryption or hashing mechanism that the client should use, as well as the option to inject random plaintext (a "nonce") into the algorithm to help prevent replay attacks.

The table below provides a useful description of how Digest Authentication is used with different versions of IIS:

• IIS4:

  • Not Available

• IIS5:

  • NT4 Domain = No Digest

  • Win2000 Domain = Basic Digest (for Domain accounts only)

• IIS6:

  • NT4 Domain = No Digest

  • Win2000 Domain (with SubAuth & LocalSystem) = Basic Digest (for Domain accounts only)

  • Win2003 Domain = Advanced Digest (for Domain accounts only)

Digest Authentication is supported in all modern browsers, and works through proxy and firewall servers. Despite being significantly more secure than Basic Authentication, Digest Authentication may be susceptible to replay attacks. Due to the randomization of the "nonce", replay attacks can only occur in a very limited timeframe. For this reason digest authentication is considered secure and quite adequate for most websites. If additional security is required, an alternate authentication mechanism can be used, or traffic can be secured via the use of SSL. It is also important to be aware of the need to store passwords using "reversible encryption" when in a Windows Server 2000 domain.

Microsoft has a webcast that can be viewed to compare IIS 5.0's original Digest Authentication with IIS 6.0's new Advanced Digest. To view this webcast, please use the following URL:

Understanding Digest and Advanced Digest Authentication in IIS 6.0

See the article entitled Configuring Subauthentication in a Windows 2000 Domain for more information as it relates to IIS 6.

Integrated Windows Authentication
Integrated Windows Authentication (IWA) encompasses two separate authentication mechanisms. The first is NTLM (also known as NT Challenge/Response in previous versions of IIS). NTLM is a proprietary Microsoft technology and has had several iterations since its original inception. NTLM v2, the most current version of NTLM, uses complex challenge/response and hashing algorithms to secure transmission of the user's credentials. This protocol should be tightly locked down to avoid any temptation from hackers to use old, known, and vulnerable protocols such as NTLM v1. For information on how to restrict your system to only NTLM v2, review the following:

How to enable NTLM v2 Authentication
����������https://support.microsoft.com/kb/239869/en-us

NTLM, despite being a proprietary protocol, is widely supported in most modern browsers, including Firefox, Internet Explorer and Opera. NTLM authentication requires that HTTP keep-alives be enabled, otherwise it will fail authentication, and as such does not work through most proxy servers (as many do not allow keep-alives.)

Kerberos authentication is an authentication technology originally developed at the Massachusetts Institute of Technology (MIT). It is a robust authentication mechanism that utilizes shared secrets to protect the user's credentials, and timestamps to prevent replay attacks. It is widely supported across Web servers as well as by most client browsers. IIS implements Kerberos authentication via a Negotiate Authorization HTTP header. The Negotiate header allows clients and servers to negotiate a commonly supported authentication mechanism.

Kerberos (unlike NTLM or Digest) can be delegated, meaning that the user's credentials can flow through to remote services (such as SQL Server). This happens because IIS, upon request for authentication, calls LogonUser API"and if the response is "yes" then IIS obtains the token and moves on. This should be considered very much accurate and delegatable assuming the correct rights are in place. Information on configuring delegation can be found in the following TechNet article: Troubleshooting Kerberos Delegation.

Microsoft addresses the complexities that are introduced by Integrated Authentication in the following webcasts:

'Using Integrated Authentication in IIS

Getting Delegation to Work with IIS & ASP.NET:
����������Ins and Outs of Protocol Transition (Part 1 of 2)
����������Ins and Outs of Protocol Transition (Part 2 of 2)

Microsoft has also produced a tool (AuthDiag) aimed at solving many of the authentication and authorization failures that web administrators struggle with on a daily basis. This tool offers configuration checks for your particular authentication types as well as real-time monitoring analysis to locate and identify failures. AuthDiag can be downloaded individually or as part of the IIS Diagnostics Toolkit at the following location: https://www.iisdiagnostics.com.

In summary, it might be confusing to some which authentication to select, thus, the following table summarizes the major pros and cons for each authentication mechanism:

Web Site Accessibility Behind NAT Routers

Fac2

Q. I have two Web sites behind my NAT router. They are, however, running on different internal Web servers. Is there any way, in IIS, that I can make both of these accessible to people outside my network?

A. In November's IIS Insider article: https://www.microsoft.com/technet/community/columns/insider/iisi1105.mspx, we looked at exposing an internal Web server through the use of port forwarding.

This technique works when there is only a single server on that port behind the NAT device. This is because NAT routers typically only operate at layer 4 in the OSI model. For any given TCP port (say, port 80), they can only forward traffic to a single internal IP address. So incoming traffic on port 80 could be directed to one internal Web server or another, but not divided between them.

So, one solution to the problem presents itself immediately: run each Web server on a different port.

Typically, however, we would wish to run our Web sites on port 80, and since we only have a single public IP address (assigned to the NAT device), we would use HTTP host headers to distinguish between our Web sites. Since HTTP host headers are contained in a higher level of the OSI model than our NAT device is aware of, we need some other device (or software) that is aware of HTTP host headers, which can be configured to direct requests to the appropriate internal Web server.

A type of software that can perform this function is a "reverse proxy." The reverse proxy software can examine the incoming request, including any HTTP host header, and forward the request onto the appropriate internal Web server. It also receives the response from the internal Web server and sends it back to the original client.

See full-sized image

Microsoft's ISA Server 2004 can perform this proxying functionality, as well as a number of 3rd party products.

So, in looking at the diagram and accompanying explanation, you should have a good sense of what it takes to make both of these Web servers accessible to people outside your network. In summary, the steps that need to be taken to get this scenario working are:

1. Deploy and configure a reverse proxy server, so that it is aware of the two separate Web servers

2. Configure your NAT Router to forward all Web related traffic to the proxy server (as detailed in November's IIS Insider article: https://www.microsoft.com/technet/community/columns/insider/iisi1105.mspx)

3. Configure your DNS settings so that the DNS names for your Web sites points to the public IP address assigned to your NAT Router

When Web Applications Break IIS

Fac3

Q. In attempting to solve a permissions problem with one of our Web applications we've managed to break IIS. The IIS services no longer start. Is there anything we can do short of reinstalling the OS? We are using IIS 6.0.

A. There are two steps you can attempt to take here prior to reinstalling your system. First consult the following KB article that outlines permissions required by IIS 6.0: https://support.microsoft.com/?kbid=812614. This article is helpful because it explains what the default permissions for a brand-new installation are set to. When resetting your permissions, you should give serious consideration to ensuring that any custom user accounts you may be using are returned to the defaults, unless you have a good reason not to. Accounts here include Web Application Pool process identities as well as anonymous user accounts. These settings can be configured via the IIS Manager MMC located in the Administrative Tools program folder.

For further information, see Microsoft KB article 313222.

When you modify settings such as permissions, user rights, or system policies you should always take into account the possibility of locking your system down "too tight." Microsoft has attempted to assist in this problem with the IIS Diagnostics tool called Authentication & Access Control Diagnostics 1.0 (AuthDiag). You can download this tool from the following URL to assist in troubleshooting authentication and authorization (i.e. permission and\or user right problems) at https://www.iisdiagnostics.com.

Before you venture into modifying system permissions, you might review David Wang's (a Software Developer & Test Engineer at Microsoft) useful steps that allow you to determine the underlying cause of your Web application's problem before taking drastic steps such as re-installing IIS that might prevent IIS from working as expected. David's blog can be located here: https://blogs.msdn.com/david.wang/archive/2005/12/31/HOWTO_Basics_of_IIS6_Troubleshooting.aspx.

For More Information

Submit your questions to IIS Insider. A response is not guaranteed; however, selected questions along with the answers will be posted in a future IIS Insider column.

Visit IIS Insider column archives for a list of previous months' questions and answers.

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.

Related Links

IIS Developer Support Voice Column

IIS Webcasts

IIS Diagnostic Tools