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:
A New Feature of IIS 5WebDAV 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.
In the anonymous access scenario, you don’t care who the user isusers 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 servicesyou 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.
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:
Figure 5-3. Overview of Web authentication protocols data flow.
As shipped, the Web server in IIS 5 supports the following authentication .protocols:
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 passwordcomprising uppercase and lowercase letters, numbers, and punctuationand 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:
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.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 speedit takes a certain amount of time to load and store the data.
Nevertheless, you can get the best of both worldsspeed and the ability to "hop" onto a remote server securelyby 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 privilegeagain, the Access This Computer From The Network privilegeyou 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.
Using Basic authentication with Active Directory Basic authentication, when used on a system with Active Directory, offers two other features:
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 UPNsnames in the form firstname.lastname@example.org. The following must be true to use UPNs in conjunction with Basic authentication:
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:
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.
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 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 datathe username and passwordto 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")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 informationsuch as the resource being accessed, the password, and the realmand 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:
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 togetherby selecting the two protocols on the Directory Security tab in the IIS administrative toolDigest 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 incorrectperhaps 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 upyou’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 boxthe 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:
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 .
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 IISthis is by design for Integrated Windows .authentication.
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.
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.
Kerberos’s advantages over NTLM Kerberos offers a number of significant advantages over NTLM, including the .following:
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:
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.
Last Updated: Friday, July 6, 2001