Training
Certifications
Books
Special Offers
Community




 
Designing Secure Web-Based Applications for Microsoft® Windows® 2000
Author Michael Howard
Pages 528
Disk 1 Companion CD(s)
Level Intermediate
Published 07/26/2000
ISBN 9780735609952
ISBN-10 0-7356-0995-0
Price(USD) $49.99
To see this book's discounted price, select a reseller below.
 

More Information

About the Book
Table of Contents
Sample Chapter
Index
Related Series
Related Books
About the Author

Support: Book & CD

Rate this book
Barnes Noble Amazon Quantum Books

 


Chapter 5: Internet Information Services Security Overview



Chapter 5 Internet Information Services Security Overview

Internet Information Services (IIS) 5 is a mature, high-performance Microsoft Windows 2000–based Web server, which builds on the success of IIS 4, the most popular Web server for Microsoft Windows NT 4. In this chapter, we’ll examine some of the security features of IIS 5 as well as some of the server’s new functionality.

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.inc), 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

There are three types of Web access in a Web application, be it on the World Wide Web or on an intranet:

  • 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

Before we look in depth at the authentication protocols supported by IIS 5, an overview of how Web authentication works is in order.

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.


IMPORTANT:
When the server sends an HTTP 401 error to the client, it sends a list of supported authentication protocols. Therefore, if your Web server supports authentication protocols A and B, you must be willing to accept credentials from the weakest protocol because the browser might understand (or choose) only the weaker protocol. If you’re not willing to accept weak credentials, you should not select that protocol for your Web site.

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.


IMPORTANT:
It is imperative that the Anonymous User account be an account with few privileges, minimal group membership, and minimal access to resources.

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.


IMPORTANT:
Only administrators can add subauthenticators to the operating system.

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.inc). 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.

Table 5-1 outlines the advantages and drawbacks of each logon privilege when applied to Basic authentication.

Table 5-1. Basic authentication and the effects of different priviledges.

PrivilegeProsCons
LocalUser can perform a hop to a remote, secured server running Windows NT or Windows 2000.Insecure—giving users this privilege allows them to log on to the Web server if they have physical access to it.
NetworkSecure—the user cannot log on to the server even with physical access to the server. Fast because no client data is cachedSlower than other logon types because client information is cached. User is unable to make a hop to a remote server.
BatchUser can make a hop to a remote server.log on to the server even with physical access to the server.Fast because no client data is cached. (Note: future versions of Windows might support caching client data for batch logon.)Very few accounts have this privilege by default.
Network with cleartext logonSecure—the user cannot log on to the server even with physical access to the server. Fast because no client data is cached.User can make a hop to a remote server. 

Using Basic authentication with Active Directory  Basic authentication, when used on a system with Active Directory, offers two other features:

  • The ability to delegate identity
  • The use of user principal names (UPNs)

Let’s look at both in turn.

By default, the account logging on to the Web server using Basic authentication must have the Log On Locally privilege, by which IIS can make requests for secured resources on a remote computer on behalf of the user. In other words, if Cheryl attempts to use a resource on a remote computer, the remote computer will see that Cheryl is performing the task. However, if the remote computer attempts to access a resource on another computer, the next computer won’t see that Cheryl is making the request. In fact, the chances are good that the request will fail. This is the delegation problem, which Figure 5-5 shows more clearly. As you can see, there’s a limit to how many times the user’s credentials can be used to set up secure connections between computers running Windows NT or Windows 2000.

Figure 5-5. The delegation effects of different logon schemes when used with Basic authentication.

However, when Active Directory is used the delegation issue is solved because Windows 2000 uses Kerberos (which, as we know, is enabled when Active Directory is installed) to perform delegation. The net effect of this configuration is shown in Figure 5-6. In short, the delegation problem is solved when using Basic authentication and Active Directory.

Figure 5-6. The effect of using Basic authentication in an Active Directory .environment.

Another useful feature of Basic authentication when used in conjunction with accounts held in Active Directory is the ability to use UPNs—names in the form user@domain.com. The following must be true to use UPNs in conjunction with Basic authentication:

  • The server on which IIS 5 is running must have access to Active Directory.
  • The account must have a UPN. (By default, all accounts in Active Directory have a UPN.)
  • The Basic domain name must be set to "\". This is used as an indicator to IIS to use UPN naming rather than classic Windows NT DOMAIN\Account naming.

As already discussed, users must have accounts in either the SAM or Windows 2000 Active Directory to access resources on IIS 5. If the user logs on and does not enter a domain name, it’s assumed that the domain to be used for the account is the same domain in which the Web server is running. For example, if the Web server is located on a server on the Sales domain and Richard logs on using Basic authentication, he will log on with the SALES\Richard account unless he explicitly logs on with another account such as DEVELOPMENT\Richard. Setting Basic authentication to use a default domain of "\" tells IIS 5 to disregard any domain names and use a UPN instead. This is possible because a UPN has domain information built in to the name itself.

You can set the default domain to "\" by following these steps:

  1. Right-click the My Computer icon on the desktop.
  2. Choose Manage from the context menu.
  3. Open the Services And Applications node.
  4. Open the Internet Information Services node.
  5. Right-click the Web site, virtual directory, directory, or file in question, and choose Properties from the context menu.
  6. Click the Directory Security tab.
  7. Click Edit in the Anonymous Access And Authentication Control box.
  8. Enable Basic authentication.
  9. Read the warning message, and select Yes if you want to continue using Basic authentication.
  10. Click the Basic authentication Edit button.
  11. Enter "\" (without the quotes) in the Domain Name box.

  • Click OK three times.
  • Figure 5-7 shows the domain name to enter in the Basic Authentication Domain dialog box in the Internet Service Manager administration tool so that UPN naming will work.

    Figure 5-7. Setting the domain name to support Windows 2000 UPNs.

    You can achieve the same result programmatically by using ADSI and the DefaultLogonDomain property. The following Windows Script code shows how to set Basic authentication on a virtual directory named Private and configure it to use UPNs:

    ‘ Authentication protocol constants.
    AUTH_ANON = 1
    AUTH_BASIC = 2
    AUTH_WINDOWS = 4
    AUTH_DIGEST = 16

    Set oVdir = GetObject("IIS://localhost/W3SVC/1/Root/Private")

    ‘ You can use AUTH_DIGEST to use UPNs with
    ‘ Digest authentication.
    oVdir.AuthFlags = AUTH_BASIC
    oVdir.DefaultLogonDomain = "\"
    oVdir.SetInfo

    Set oVdir = Nothing
    
    
    NOTE:

    The "\" domain name also applies to Digest authentication. If you enter the domain name in the Basic authentication user interface or set it using ADSI, Digest authentication will support UPNs also. Digest authentication is discussed later in this chapter.

    Figure 5-8 shows an example of entering a UPN into the Internet Explorer 5 dialog box that appears with Basic authentication.

    Figure 5-8. Entering a UPN into the Basic authentication dialog box.  The danger of Basic authentication  It’s no secret that Basic authentication is an insecure protocol. The password along with some other data sent to the Web server is encoded by base64; it’s a trivial exercise for an attacker to determine the password. However, Basic authentication is still a feasible authentication protocol if used in conjunction with the Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocol. If a virtual directory is configured to use SSL/TLS and Basic authentication, all transmitted data, including the username and password, is encrypted by SSL/TLS first. This makes it infeasible to determine the user’s credentials.


    NOTE:
    It’s commonly thought that using Basic authentication over SSL/TLS still yields some of the HTTP headers in cleartext and that Basic authentication occurs before SSL/TLS is used to encrypt the connection. This is incorrect. When IIS is configured to use any authentication scheme in conjunction with SSL/TLS, the SSL/TLS negotiation happens first and the secure channel is established, after which the authentication happens. Because the channel is now encrypted, the authentication data is secure, including the Basic authentication header information.

    Note that some Web sites using SSL/TLS and Basic authentication make a serious security mistake. The site prompts you to enter your credentials using a channel secured by SSL/TLS, but after the site has authenticated the user account and password it no longer requires SSL/TLS on other parts of the Web property but still uses Basic authentication. The problem is that the browser continues to send the Basic authentication data—the username and password—to the Web site for every request in the clear. In fact, the Web browser will continue to do this until it is restarted. This problem is partially avoided if the Web site requires Basic authentication and uses realms. (See the following sidebar.) This will force the browser to prompt for new credentials because the user might have a different username and/or password in a different part of a Web server.

    Basic Authentication and Realms  Basic authentication includes the notion of realms, a way of naming various portions of a Web site for security purposes. The user agent (usually a Web browser) is expected to temporarily cache a username and password for each realm used by the Web server. If the user attempts to access a realm and the browser does not have a cached copy of the username and password for that realm, it will prompt the user to enter a valid username and password. By default, the realm used in IIS is the name of the Web site.

    You can set the realm only by setting the Realm ADSI property; setting realms is currently not a capability of the Internet Information Services tool. The following Windows Script code shows how to set a new realm named PrivateData on a virtual directory named private on the default Web site (Web site #1):

    Set oVdir = GetObject("IIS://localhost/W3SVC/1/Root/Private")
    oVdir.Realm = "PrivateData"
    oVdir.SetInfo
    Set oVdir = Nothing
    
    Although Basic authentication is an old, insecure protocol, it’s common on the Web today and supported by just about every Web browser and Web server vendor. Because of its serious security problems, use it only for access to low-value data unless SSL/TLS is first used to secure the connection.

    Digest authentication  Digest authentication is a reasonably new authentication scheme that is part of the HTTP 1.1 protocol; like Basic authentication, it’s defined in RFC 2617 at http://www.ietf.org/rfc/rfc2617.inc. Also like Basic authentication, Digest authentication can work through proxy servers and firewalls.

    How Digest Authentication Got Its Name  Digest authentication does not transmit the user’s password to the server in cleartext; rather, it hashes information—such as the resource being accessed, the password, and the realm—and passes the request to the server. The process of hashing is often referred to as creating a digest, hence the name.

    In case you really want to know, the default hash function for Digest authentication is the MD5 hash function developed by RSA Data Security. You can find out more about MD5 in RFC 1321 at http://www.ietf.org/rfc/rfc1321.inc; refer also to Chapter 15, "An Introduction to Cryptography and Certificates in Windows 2000," for further details about hashing and hash functions.

    Digest authentication offers advantages over Basic authentication; most notably, the password does not travel from the browser to the server in cleartext. Digest authentication’s biggest shortcoming at this point is browser and server support. Currently, Internet Explorer 5 and later is the only browser and IIS 5 is one of a very small number of Web servers supporting Digest authentication. The good news, however, is that Digest authentication is being considered for use by Internet protocols other than HTTP, such as LDAP (directory access), IMAP, POP3, SMTP (all e-mail), and ACAP (Application Configuration and Profile).

    Setting up Digest authentication  For Digest authentication to work, the following must be true:

    • The machine running Windows 2000 Server is in an Active Directory domain.
    • IIS 5 is configured to use Digest authentication.
    • A file called IISSUBA.DLL is installed on the domain controller; this is performed at Windows 2000 setup time.


    NOTE:
    You might notice that this is the second time we’ve mentioned IISSUBA.DLL. This DLL performs work during anonymous access and Digest authentication.

    • All accounts logging on using Digest authentication are configured with the Store Password Using Reversible Encryption option enabled on their accounts. This option stores an encrypted copy of the account’s cleartext password in Active Directory; this gives Digest authentication access to a cleartext copy of the account’s password.


    NOTE:
    Simply enabling the Store Password Using Reversible Encryption option does not store a user’s password as cleartext in Active Directory. After setting this option, you must either force the user to change the password or set the password using the Active Directory administration tools. This will allow Windows 2000 to pick up the cleartext copy of the password and store it in Active Directory.

    Figure 5-9 shows the setting on the user account object in Active Directory necessary to support Digest authentication.

    Figure 5-9. Setting the Store Password Using Reversible Encryption option on a user account in Active Directory.  Three Digest authentication caveats  You need to be aware of three issues with Digest authentication: one relates to the IIS 5 implementation of the protocol, one relates to using Digest authentication in conjunction with Basic authentication, and the last relates to the Digest authentication specification.

    Caveat #1: The implementation of Digest authentication in IIS 5 suffers a drawback: the user’s identity cannot leave the IIS 5 server. In other words, you cannot dele.gate identity to another computer. This is because the account is logged on using a subauthentication DLL and Windows 2000 does not trust accounts validated using subauthentication DLLs. There are plans to remedy this in a future version of Windows.

    Caveat #2: If you opt to use Basic authentication and Digest authentication together—by selecting the two protocols on the Directory Security tab in the IIS administrative tool—Digest authentication is listed after Basic authentication in the set of WWW-Authenticate headers sent to the client. The client can then choose Basic authentication rather than Digest authentication. This is the case with Internet Explorer 5.

    Caveat #3: The last issue relates to the overall authentication "strength" of Digest authentication. According to RFC 2617, "Both Digest and Basic authentication are very much at the weak end of the security strength spectrum." The main issue is that both protocols are subject to a replay attack. During a replay attack, an attacker listens, or sniffs, an initial transaction traveling from the client to the Web server and then uses the information to replay that transaction. Basic authentication is particularly weak because the password can be used to access other resources accessible only to the original user.

    Digest authentication is susceptible to replay, but it’s more robust because the attacker cannot use a GET verb to access any other resource other than the original resource requested by the user. The resource being demanded is hashed into the initial request, and it’s infeasible to derive the hash unless the attacker knows the user’s password.

    Storing Cleartext Passwords in Active Directory  As noted in "Setting up Digest authentication," Digest authentication requires cleartext user passwords to operate. Obviously, storing any form of cleartext password is a security risk, and that’s why the Store Password Using Reversible Encryption option is disabled by default. If you opt to use Digest authentication, make sure the servers are well protected from attack.

    You might be wondering why Active Directory doesn’t just store a hash, or digest, of the passwords rather than the requisite cleartext password. First, the Store Password Using Reversible Encryption setting is not just used for Digest authentication; it can be used by other protocols, some of which might require the cleartext password. For example, Internet Authentication Server, which provides RADIUS support and is included with Windows 2000, uses this setting.

    The second reason Active Directory needs to store cleartext passwords is that Digest authentication doesn’t just hash the password. The password and other information, such as the realm, are hashed together before being sent from the client to the server. At the very least, the server would have to store hashes of all users and all possible realms. This is an unmanageable solution because you might change a realm name or add or delete a realm on your Web sites at any stage.

    Integrated Windows authentication and the Negotiate protocol  In Internet Information Server 4, Integrated Windows authentication was referred to as Windows NT Challenge/Response authentication, which is also known as NT LAN Manager (or NTLM) authentication. This is the native authentication protocol in all Windows platforms prior to Windows 2000.

    However, there’s a twist on this in IIS 5, which we’ll explain when we discuss the Negotiate protocol. For the moment, just keep in mind that Integrated Windows authentication is a superset of NTLM authentication.

    NTLM authentication works especially well in an intranet environment where users have Windows accounts, because the browser attempts to use the current user’s credentials from a domain logon. If those credentials are rejected, the Web server will send an HTTP 401 error back to the browser to prompt the user for a username and password so that the request can be made again.

    The user is not prompted for a username and password for each HTTP request; rather, this will happen only when the cached credentials do not have sufficient permissions to access a specific page or file.

    HTTP 401 Errors and HTTP 403 Errors  It’s important to make the distinction between these two HTTP errors. The 401 error means that the user account credentials are incorrect—perhaps the user entered an incorrect name or password or the Caps Lock key was down!

    The 403 error means that the credentials are correct (in the nonanonymous case) but the account does not have access to the requested resource. Examples of this kind of error include ACL conflicts.

    The default browser behavior for either error is to prompt the user to enter a username and password. However, prompting the user to enter a new username and password is somewhat troubling because the user is not told if the account credentials are at fault.

    If you want to find out what the error was, hit the Esc key when the credentials dialog box pops up—you’ll then see the error generated by the server.

    With NTLM authentication, the user’s password is not sent from the browser to the Web server. If a user has logged on as a domain user, the user won’t have to be authenticated again when accessing a Web server configured to use NTLM authentication in that domain. Before Windows 2000, Windows NT used only the Windows NT Challenge/Response authentication protocol. However, Windows 2000 Server supports both NTLM and the Kerberos V5 authentication protocol, which is why IIS 5 no longer lists the Windows NT Challenge/Response authentication protocol in the Authentication Methods dialog box—the authentication scheme used can be Kerberos or NTLM.

    Windows 2000, Internet Explorer 5, and IIS 5 all use the Negotiate protocol to determine whether NTLM or Kerberos authentication is to be used. The process works like this:

    1. The client, using Internet Explorer 5 in Windows 2000, requests a resource from the IIS 5 server running on Windows 2000.
    2. IIS sends an HTTP 401 error response including two WWW-Authenticate headers—one for Negotiate and one for NTLM—back to the browser.
    3. Internet Explorer sees that an HTTP 401 error is raised and examines the response to see which WWW-Authenticate headers it understands. It will choose the first protocol it understands, Negotiate—the browser understands NTLM also, but Negotiate is listed first. Internet Explorer then makes a call to the client-side Negotiate Security Support Provider (SSP). The programmatic interface to SSP is called the Security Support Provider Interface (SSPI), which is a standard way to refer to the multiple authentication schemes in Windows.

    4. NOTE:

      For more information on SSPs and SSPI, refer to the SSPI white paper at /.windows2000/library/howitworks/security/sspi2000.asp, the MSDN CDs, or http://msdn.microsoft.com .

    5. The Negotiate SSP gets appropriate data from the NTLM and Kerberos SSPs and builds up a response blob. The response has enough information to authenticate the client to the server and to determine whether NTLM or Kerberos will be used as the authentication protocol. We’ll explain when Kerberos is used over NTLM shortly.
    6. The client-side Negotiate SSP passes the blob to Internet Explorer.
    7. Internet Explorer builds a new request, this time including the HTTP Authorization header and Negotiate information, and passes it to IIS.
    8. The Web server takes the new request and passes the Negotiate blob into the server-side Negotiate SSP.
    9. The Negotiate SSP determines whether Kerberos or NTLM is used.

    10. NOTE:

      Steps 6, 7, and 8 can be repeated multiple times if NTLM is chosen during the Negotiate phase. Don’t be surprised if you see two HTTP 401 errors sent to the browser by IIS—this is by design for Integrated Windows .authentication.

    11. If all goes well, SSP returns a token to IIS and the Web server impersonates the user represented by the token and accesses the resource.
    12. Access issues aside, IIS returns the requested data back to the client with an HTTP 200 status code – no error message.

    Figure 5-10 outlines the steps taken in this process.

    Challenge/Response Mechanisms in a Nutshell  Most challenge/response systems work in the following manner. Note that the user’s password does not go across the network.

    1. The client wants to access a resource on the server.
    2. The server requires the client to authenticate herself.
    3. The server sends a random value, the challenge, to the client.
    4. The client hashes the random value and her password to create a response.
    5. The client sends the response and her name to the server.
    6. The server receives the response from the client.
    7. The server performs the same hash operations as the client.
    8. If the hash sent by the client is the same as the hash derived by the server, the chances are very good that the client is who she says she is.

    This system is more secure than sending a cleartext password across the network because only hashes, not passwords, travel across the network.

    Figure 5-10. The Negotiate SSP series of interactions.

    The reason for passing both an NTLM and Negotiate header back to the client is for maintaining backward compatibility. Versions of Internet Explorer prior to Internet Explorer 5 and versions of Windows prior to Windows 2000 do not recognize the Negotiate header, but they do recognize NTLM.

    NTLM vs. Kerberos  So, the question remains: when does the Negotiate package use Kerberos, and when does it use NTLM? If the following criteria are true, Kerberos is used. If any one condition is not met, NTLM is used.

    • The client is a Windows 2000 client using Internet Explorer 5 or later.
    • The server is running Windows 2000 and IIS 5 or later.
    • The client and the server are in the same Windows 2000 domain or in trusted domains.
    • IIS 5 is configured to use Integrated Windows authentication.
    • If you are accessing the Web server with a name other than the name of the server running Windows 2000, a new service principal name (SPN) must have been registered using the Setspn tool from the Windows 2000 Server Resource Kit. For example, if the Web server is responding to a Domain Name System (DNS) name of www.exair.com but the server (or servers) is named webservers.development.exair.com, you must register www.exair.com. SPNs and the Setspn tool are explained in detail in .Chapter 14, "An Introduction to Kerberos Authentication in Windows 2000."

    Kerberos’s advantages over NTLM  Kerberos offers a number of significant advantages over NTLM, including the .following:

    • Kerberos can be faster than NTLM.
    • Kerberos is more secure than NTLM.
    • Kerberos authenticates the server and the client; NTLM authenticates the client only. Using NTLM, the client can’t really know whether the server he or she is talking to is valid.

    But here’s the really good news about being authenticated using the Kerberos authentication protocol rather than NTLM: you can pass a client’s identity from one computer to another. In other words, Kerberos solves the delegation problem. We discussed this in Chapter 3, "Windows 2000 Security Overview," and we’ll discuss it in further detail in Chapter 10, "Building a Secure Solution," and Chapter 14.

    X.509 client certificate authentication  Both IIS 4 and IIS 5 support using X.509 client certificates to authenticate users when used in conjunction with the SSL/TLS protocol. If you’re unfamiliar with X.509 client certificates, first read Chapter 15, "An Introduction to Cryptography and Certificates in Windows 2000."

    Authenticating the server  In short, SSL/TLS always uses certificates to authenticate the Web server. When a client connects to a Web server, the server’s certificate is used to authenticate itself. So, let’s take a moment to look at what happens in a normal SSL/TLS connection that does not use client authentication certificates.

    When you connect to the www.exair.com Web site using SSL/TLS by typing https://www.exair.com, the browser compares the Web site’s URL with the common name in the Web server’s certificate. If the two are the same, the Web server is determined to be owned by Exploration Air and not, say, by a competitor. Note the use of https rather than http; this tells the browser to use SSL/TLS on TCP port 443 by default, rather than TCP port 80.

    Actually, there are many more steps than just checking the name in the certificate. These checks include the following:

    • A cryptographic check to determine that the Web site owns the private key associated with the public key in the certificate.
    • A check that the name in the certificate is the same as the name of the Web site.
    • A check that the issuer of the Web site’s certificate is trusted.
    • A check that the certificate has not expired.
    • A check that the certificate has not been revoked. By default, this is not performed by Internet Explorer; it’s performed by IIS.
    • A check that the certificate has not been tampered with.

    If any of these checks fail, a warning is displayed to the user and the connection might be dropped. If your browser informs you that something is possibly wrong with the certificate, it’s recommended that you do not continue with the connection.


    Next




    Top of Page


    Last Updated: Friday, July 6, 2001