Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM by Michael Howard, Marc Levy, Richard Waymire

From the Publisher

Today, businesses use networks consisting of intranets, Internet sites, and extranets, all of which extend the network, requiring increased system security. In addition, confidential information may be stored on mobile computing devices, which are subject to theft and loss.

Windows 2000 provides end-to-end security that lets organizations integrate systems both inside and outside the corporate network boundaries, while providing complete access control and data protection. Security features include advanced techniques for identifying who is accessing the system, including the use of digital "keys" to access selected data, and a single ID that permits users to access not only their own computer, but also other shared resources (such as printers or files) on the corporate network, the Internet, or even a business partner's network

Product Details

• Table of Contents
• Read an Excerpt

Table of Contents

Read an Excerpt

Chapter 5 Internet Information Services Security Overview

Because IIS is a Windows 2000 system service and relies heavily on the security functionality in Windows 2000, it's assumed in this chapter that you have read Chapter 3, "Windows 2000 Security Overview," or have a good working knowledge of Windows 2000 security.

We'll cover the following topics in this chapter:

• Internet authentication

• Web authentication protocol details

• Anonymous access

• Basic authentication

• Digest authentication

• Integrated Windows authentication and the Negotiate protocol

• X.509 client certificate authentication

• Configuring SSL/TLS

• IIS authorization-the marriage of Windows 2000 security and the Web

• IIS process identities

A New Feature of IIS 5-WebDAV  Defined in RFC 2518 (http://www.ietf.org/rfc/rfc2518.txt), Web-based Distributed Authoring and Versioning (WebDAV) is a set of extensions to the HTTP 1.1 protocol that allows users to collaboratively edit and manage documents on Web servers. IIS 5, Microsoft Internet Explorer 5, and Microsoft Office 2000 support WebDAV.

You can find more information about WebDAV at the WebDAV Resources Web site (http://www.webdav.org) and at the Microsoft Developer Network (MSDN) Web site at http://msdn.microsoft.com/standards/WebDAV.asp.

Internet Authentication

• Anonymous access

• Identified access

• Authenticated access

In the anonymous access scenario, you don't care who the user is-users have access to all the resources you want them to have access to and no more. A good example of this is simple Web presence; most Web sites use anonymous access for their home page and their marketing or sales material. For example, the vast majority of www.microsoft.com uses anonymous access, including its sales, marketing, and developer-related materials.

Identified access is for Web areas where you are providing personalized services-you are not giving users access to private data known only to the company and the user. For example, you have the option to customize the home page of The Microsoft Network, www.msn.com, so that you can see your favorite stock quotes, news sources, leisure categories, and so on. This Web information is not confidential; it is customized.

In the authenticated access scenario, you need to know who the user is and the user has to have access to data that might be private, sensitive, or personal.

Notice that as you progress from anonymous to authenticated access there's a greater need to trust the user's credentials, as shown in Figure 5-1. For anonymous access, there's far less of a need to know who the user is; in fact, some might argue that you needn't care at all. For identified access, you need to know who the user is but only to the extent needed to provide a service or personalized but public content associated with that identity. With authenticated access, access is denied if you cannot confirm the credentials of the calling user.

Figure 5-1. Valuable information requires stronger credentials.

Each of these scenarios depends on the degree to which you trust the credentials supplied by the user. Anonymous access requires no credentials, identified access uses weak credentials, and authenticated access requires strong credentials. The strength of the credentials required is related to the value or sensitivity of the data you are providing. This is not to say that sales and marketing information available to all users is not valuable, but it is not as valuable as projected sales and marketing information internal to the organization.

In the example shown in Figure 5-2, the public area of the fictitious Exploration Air Web site requires no authentication (anonymous access), and the internal part of the site requires either HTTP 1.1 Digest authentication or Integrated Windows authentication, both of which are covered later in this chapter. The directories used to serve the content should be controlled by access control lists (ACLs) according to who the users are. Notice the use of the Deny access control entry (ACE) for the anonymous user account on the internal directory in the figure. If the administrator accidentally sets anonymous access as a valid authentication scheme, the anonymous account will still be denied access to the site content because of this ACL setting.

Figure 5-2. Public data requires weak or no credentials; private or confidential data requires stronger credentials using authentication techniques.

Authentication Protocols Supported by IIS 5

Web authentication protocol details  Web authentication requires multiple interactions between the Web browser and the Web server. The general steps, as shown in Figure 5-3, are as follows:

1. The browser requests data from the server by using an HTTP GET verb.

2. If the Web server requires the client to authenticate himself, it sends an HTTP 401 error back to the browser, along with a list of the authentication schemes it supports and data, often called a challenge, with which the client can resubmit the request. The challenges are sent as one or more WWW-Authenticate headers in the server's response.

3. The browser chooses an authentication scheme it supports and reconstructs the request to include a response to the challenge. The response is data based on the user's credentials and the challenge data sent by the server. The response is sent back as part of an Authorization header. Note that Internet Explorer will always pick the first authentication scheme if given the option of choosing from multiple authentication schemes. For example, if Basic authentication is listed before Digest authentication, Internet Explorer will pick Basic.

4. The browser reissues the request including the response data.

5. The server authenticates the newly submitted data and, assuming all is well, sends the response, and the requested resource, back to the user, including an HTTP 200 status code - no error message.

Figure 5-3. Overview of Web authentication protocols data flow.

As shipped, the Web server in IIS 5 supports the following authentication .protocols:

• Anonymous access

• Basic

• Digest

• Integrated Windows

• X.509 client certificates

Each of these is explained in detail in the following sections, so let's get started with the weakest of all the authentication schemes, anonymous access.

Anonymous access  Technically, anonymous access is not an authentication scheme because the calling user is never asked to present credentials such as a password. However, Windows 2000 requires that all users authenticate themselves before they access any resource. To this end, IIS provides a default user account called IUSR_machinename as the Anonymous User account for anonymous access. All anonymous access is performed in the context of this account.

The account is defined at setup time with a very strong password-comprising uppercase and lowercase letters, numbers, and punctuation-and can be changed by the administrator later, but you are not obliged to use this and only this account for anonymous access. In fact, you can set different user accounts to be used in different parts of your Web space, such as at a Web server, virtual directory, directory, and file levels.

You can change the account in the IIS administrative tool like so:

1. Right-click the My Computer icon on your desktop.

2. Choose Manage from the context menu.

3. Expand the Services And Applications node.

4. Click Internet Information Services.

5. Right-click the Web server, virtual directory, directory, or file in question.

6. Choose Properties from the context menu.

7. Click the Directory Security tab.

8. Click Edit in the Anonymous Access And Authentication Control box.

9. Make sure Anonymous Access is checked.

10. Click Edit.

11. Enter the account name and the account password. If the password box is grayed out, you need to clear the Allow IIS To Control Password check box first.

12. Click OK three times.

You can also set the anonymous account programmatically by using Active Directory Services Interface (ADSI). Refer to Chapter 13, "Security Administration with ADSI, WMI, and COM+," for an example.

Failure to configure the account this way will compromise the security of your Web site because all anonymous access will operate in the context of the anonymous account. You have been warned!

Why change the Anonymous User account?  It's useful to change the Anonymous User account if you host multiple Web sites. You can set up one Anonymous User account per Web site and set ACLs on the resources used by that Web site. For example, say you host www.SiteA.com and www.SiteB.com. You could then set the account for www.SiteA.com to be AnonA and the account for www.SiteB.com to be AnonB. The scenario would look like that in Figure 5-4.

Figure 5-4. Using different Anonymous User accounts for different Web sites.  Privileges required when using the Anonymous User account  There has been much confusion about the Anonymous User account and anonymous access in IIS relating to which privileges are required for the account. The question is, "Does the Anonymous User account need network logon or interactive logon privileges?"

The answer is, it depends!

If you have the Allow IIS To Control Password option checked in the Anonymous User Account dialog box, the account must have the Access This Computer From The Network privilege; otherwise, the Log On Locally privilege is required. IIS will log the account on using different techniques, depending on the Allow IIS To Control Password setting, which is our next topic.

The Allow IIS To Control Password setting   If the Allow IIS To Control Password setting is checked, IIS calls a subauthenticator to validate the password. Subauthenticators are implemented as dynamic-link libraries (DLLs). A subauthentication DLL allows the authentication information stored in the Windows 2000 user account database (the Security Accounts Manager [SAM] or the Directory) to be augmented with other account validation capabilities.

For example, a server might supply a subauthentication DLL that validates a user's password via a different algorithm or specifies special workstation restrictions. All of this can be accomplished using subauthentication DLLs without sacrificing the use of the Windows 2000 user account database and its administration tools.

IIS 5 supplies a subauthentication DLL called IISSUBA.DLL to verify that the password is correct and then informs Windows 2000 that the password is valid so that the user can log on. Note that this functionality is available in Internet Information Server 4 also.

Accounts authenticated using a subauthentication DLL are always network logons and thus must have the Access This Computer From The Network privilege.

For more information about subauthentication DLLs, refer to the MSDN CDs or to http://msdn.microsoft.com.

If Allow IIS To Control Password is not checked, IIS will log the account on using the Windows API LogonUser and pass in the name of the Anonymous User account as well as the password, both of which are stored in the IIS configuration store, the metabase. Hence, if the control password setting is not set, the anonymous account must have the Log On Locally privilege.

Basic authentication  Basic authentication is a simple authentication protocol defined as part of the HTTP 1.0 protocol defined in RFC 2617 (available at http://www.ietf.org/rfc/rfc2617.txt). Although virtually all Web servers and Web browsers support this protocol, it is extremely insecure because the password is in cleartext (also called plaintext), meaning it's passed over the network "in the clear." (Actually, it's not in the clear; it's base64-encoded, which is so trivial to decode that it might as well be cleartext!). Basic authentication works well through proxy servers and firewalls.

Basic authentication, as implemented in IIS 5, requires Windows 2000 accounts, either in the SAM or in Active Directory. This allows the Web site to use ACLs to determine access to resources. When a user connects to a Web site using Basic authentication, IIS gets the username and password from the HTTP Authorization header, calls the LogonUser API, and then impersonates the user.

By default, users accessing your Basic authentication Web server need the right to log on locally, although this can be changed in the IIS metabase by using ADSI. Refer to Chapter 13 for this method.

So, why change the logon type? The LogonUser API allows you to determine how the account is logged on. For example, the account can be logged on using log on locally, network, or batch privileges. Interactive logon is the default because it's the most flexible setting for most environments; it's not necessarily the most secure. Giving users this privilege allows them to log on to the Web server if they have physical access to the server.

The flexibility of a local logon is a legacy of Windows NT 4 and IIS 4. If an account is authenticated using NTLM or is logged on with network privileges, the account cannot access secured resources on another remote computer. While the issue of client delegation is resolved in Windows 2000 by using Kerberos, the only way to work around this in Windows NT with IIS 4 and Windows 2000 with IIS 5 in a non-Active Directory environment is to log the account on using log on locally privileges.

With log on locally privileges, information about the client, such as group membership and privileges, is stored so that the account can perform an offline logon if the server performing the logon cannot access a domain controller. The downside to storing this information is its effect on speed-it takes a certain amount of time to load and store the data.

Nevertheless, you can get the best of both worlds-speed and the ability to "hop" onto a remote server securely-by using the batch logon privilege. However, few user accounts have this privilege, so you must grant the privilege to the users in question.

The Network Logon With Cleartext password setting  Just to make things a little more interesting, there's another option! Once you give a user the network privilege-again, the Access This Computer From The Network privilege-you can allow the user to hop off the IIS server and onto a remote server by using a flag in the call to LogonUser that is new to Windows 2000: the Network Logon With Cleartext password setting. This is a new implementation in Windows 2000 of the network logon, a way of using the network privilege when calling LogonUser. This capability can be set only by using ADSI, as we'll describe in Chapter 13...