IIS 101: The Basics of IIS Authentication

Side Bars
 • Authenticating with Certificates
 • Authentication, Permissions, and Rights

IIS 101

Imagine having to type in a username and password at every Web site you visited. In addition, you would have to create a unique username and password for each site, then have the difficult task of remembering them. Such a requirement is counterintuitive to the very nature of the "open-access" Web.

However, put yourself in Microsoft’s shoes. Microsoft had gone to great pains to design Windows NT so that no one could gain access to the OS without providing a secure username and password. Now, the Web comes along and everyone wants to be able to log on to a Web server without authentication. In addition, you must provide the same secure logon capabilities to those who require them.

To solve this dilemma, Microsoft implemented three authentication levels in IIS 4.0—Anonymous, Basic, and NT Challenge/Response. This month, I review these three authentication methods, and I show you a few key differences between IIS 4.0 and IIS 5.0 authentication methods. You can read about an additional method in the sidebar "Authenticating with Certificates."

Anonymous Authentication
The most common form of authentication in IIS is Anonymous authentication. Under this method, although a user can access a Web site without providing a username and password, that user is still logged on to the server. This authentication method works through use of the Anonymous account. Users who request a page from a Web site that permits Anonymous access log on to the NT server as the IUSR_servername user. IIS enables this capability by default.

The IIS installation process creates the IUSR account. The account has the following characteristics:

• It is a member of the Guests group. Don’t confuse this Guests group with the Guest account. By default, the Guest account is and should remain disabled. Nevertheless, a user account can programmatically log on as a member of the Guests group. For example, IIS logs on an Anonymous user under the Guest logon even if the Guest account is disabled.
• It has the Log on locally right. (For an explanation of the differences between rights and authentication, see the sidebar "Authentication, Permissions, and Rights.") You can find rights in User Manager under Rights. The Log on locally right is a required attribute, and the account won’t work correctly if you don’t assign it.
• The IUSR account is part of the Everyone group, and Everyone Full Control is the default permission on NT, so set your NTFS permissions accordingly. For basic information about NTFS, see the Microsoft articles "NTFS Security, Part 1: Implementing NTFS Standard Permissions on Your Web Site" and "NTFS Security, Part 2: Implementing NTFS Special Permissions on Your Web site". For more specifics about NTFS permissions, you can find the white paper "Windows NT Security Guidelines" at http://www.trustedsystems.com/downloads.htm.

Basic and NT Challenge/Response Authentication
When you want to require users to provide a username and password, IIS 4.0 uses either Basic or NT Challenge/Response authentication to prompt users for that information. A user must then provide credentials that match an account in User Manager. The user account can be on a domain controller (DC) either if IIS is running on a DC (which Microsoft doesn’t recommend) or if you set up IIS to authenticate to a DC instead of its local user database. The user’s account must have NTFS permissions for the requested resource, or the OS will deny access.

Basic authentication is part of the HTTP 1.0 standard and is in widespread use. This method works with both Netscape and Microsoft browsers, but it isn’t secure. The username and password are sent over the network in Base64, which for all practical purposes is clear text.

For that reason, Microsoft developed an alternative to Basic authentication called NT Challenge/Response. With NT Challenge/Response, the browser encrypts the password into a one-way hash, then compares that hash with the same calculation on the server. If calculated hashes are the same, the browser assumes that the password is the same. In this way, the password is never sent over the network.

NT Challenge/Response authentication is considerably more secure than Basic authentication, but tools exist to crack the hash if it’s captured. Furthermore, NT Challenge/Response doesn’t work with Netscape. The lack of solid encryption and the incompatibility with Netscape make NT Challenge/Response a poor choice for Internet Web servers.

The best option is to use Basic authentication over a Secure Sockets Layer (SSL) connection. SSL is the same protocol used to encrypt most e-commerce Web sites and is a secure and widely supported standard. With this configuration, the industry-standard SSL protocol encrypts your logon session. When the system has authenticated a user, you can drop the SSL session and return to an unencrypted connection. Because of the significant CPU and bandwidth overhead of creating, maintaining, and processing SSL traffic, I recommend that you not conduct all your Web server sessions over SSL. If you have significant SSL-processing requirements, consider a hardware-based SSL enhancer such as the Compaq AXL200 Accelerator PCI Card.

Authentication in IIS 5.0
IIS 5.0 offers a couple of new authentication methods in addition to those in IIS 4.0—Integrated Windows authentication and Digest authentication. Integrated Windows authentication is the same as NT Challenge/Response except that if you’re using Microsoft Internet Explorer (IE) 5.0 on a Windows 2000 system and the IIS 5.0 machine is a member of a domain and has access to a DC, then the system automatically uses Kerberos instead of NT Challenge/Response. In any other circumstance, Integrated Windows authentication behaves the same as NT Challenge/Response. Kerberos is significantly more secure than NT Challenge/Response and is the key component to authentication in Win2K networks. However, the conditions that must be met for this feature to be implemented don’t make it a consideration for Web servers that are available on the Internet.

The same is true for the second IIS 5.0-only method, Digest authentication. Microsoft designed Digest authentication to overcome the security risks of Basic authentication. This method provides a means for the client to authenticate securely to the Web server without the password going over the network. The client verifies the password when that client performs a calculation (i.e., hash) on the password and sends that calculation to the server. The server then performs the same calculation, and the system compares the two values. If the calculations are the same, the system presumes that the passwords are the same.

Although Digest authentication is a feature of IIS 5.0 and holds promise, not all browsers support it, so it’s not in widespread use. Furthermore, you must appropriately configure your IIS 5.0 server and network. For more information about Digest authentication in IIS 5.0, see the Microsoft article "Setting Up Digest Authentication for Use with Internet Information Services 5.0".

Choosing an Authentication Method
You can select multiple forms of authentication for IIS. When you make such a selection, IIS and the browser negotiate what kind of authentication they will use. If a Microsoft browser encounters an IIS server on which you’ve enabled NT Challenge/Response or Windows Integrated authentication, the browser will use that method in preference to Basic authentication. Netscape browsers always use Basic authentication if the server requires something other than Anonymous access.

So, how do you decide what forms of authentication to use? Your specific circumstances determine this choice. Many Web sites have no authentication at all and allow only Anonymous access. Other sites are just the opposite. Some Web servers must provide logon capability to all kinds of browsers and, therefore, must use Basic authentication or a custom authentication process. Still other servers are Microsoft-only intranets in which the users all use IE on Win2K systems, so Windows Integrated authentication is a good choice.

One more item of interest: Microsoft requires that you purchase a Client Access License ( to enable a client to log on to a Microsoft server. Microsoft waives this requirement for Anonymous access to IIS servers, but if you authenticate a user against an account in User Manager, you need a CAL. If you plan to have many users authenticate to an IIS server, you can end up making a significant investment in CALs. If you use a non-Microsoft means of authentication, either custom or third party, you bypass this requirement but at the expense of not integrating with NTFS permissions.

Next Month
This month, you’ve learned the basics of authentication. If you would like to learn more, the best resource on this topic is Leonid Braginski and Matthew Powell, Running Microsoft Internet Information Server (Microsoft Press, 1998). Also, don’t underestimate the value of the Microsoft TechNet Web site dedicated to IIS. Next month, I’ll give you a primer on performance.