Internet Authentication

[Previous] [Next]

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.

click to view at full size.

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.

click to view at full size.

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.

click to view at full size.

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

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 privileges.

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.
Slower than other logon types because client information is cached.
Network Secure—the user cannot log on to the server even with physical access to the server.
Fast because no client data is cached.
User is unable to make a hop to a remote server.
Batch User can make a hop to a remote server.
Secure—the user cannot 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 logon Secure—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.

click to view at full size.

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.

click to view at full size.

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.
  12. 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.txt. 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.txt; 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 delegate 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.

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

  1. 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.
  2. The client-side Negotiate SSP passes the blob to Internet Explorer.
  3. Internet Explorer builds a new request, this time including the HTTP Authorization header and Negotiate information, and passes it to IIS.
  4. The Web server takes the new request and passes the Negotiate blob into the server-side Negotiate SSP.
  5. The Negotiate SSP determines whether Kerberos or NTLM is used.

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.

  1. 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.
  2. 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.

click to view at full size.

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.

Authenticating the client

SSL/TLS includes an optional step: authenticating the client. As we've mentioned, when an SSL/TLS connection is established, the client authenticates the server by inspecting the Web server's certificate, after which the Web server can optionally ask the Web user to authenticate himself. After such a request, the browser will prompt the user to choose from a list of client certificates, as shown in Figure 5-11.

Figure 5-11. The Client Authentication dialog box in Internet Explorer 5.

When the Web server asks the client to authenticate himself, it sends a list of certificate authorities (CAs) it trusts to the client. For example, if the Web server trusts VeriSign and Thawte and the user has certificates from Thawte and Equifax, the browser will give the user the option to select the Thawte certificate only because that's the only certificate the Web server trusts.

NOTE
Internet Explorer remembers which certificate you selected for client authentication to a particular Web site. In Windows 2000, Internet Explorer credentials are remembered even if they failed to authenticate to the remote Web server. Therefore, if you select an invalid certificate, you'll need to close all open Internet Explorer windows and open a new browser window. You'll then be prompted to select a valid certificate for client authentication.

How IIS uses X.509 client certificates

IIS uses X.509 client certificates in one of four ways:

  • It doesn't require them.
  • It gives users the option of providing a certificate but does not require one.
  • It requires a client certificate from the user.
  • It requires a client certificate from the user and uses this to map to a Windows 2000 user account.

The first option is self-explanatory: the client is not given the option of presenting a certificate. The next two options are somewhat similar; the only difference is that the former option doesn't require the client to provide a certificate and the latter does. In both cases, if the client certificate is provided, its information is used to populate the Active Server Pages (ASP) Request.ClientCertificate collection. Using this data, you can make authentication and authorization decisions in ASP.

For example, the following ASP code will make an authorization decision based on the domain name of the user's e-mail address:

 <%     Dim strValidDomain, strEmail     strValidDomain = "@exair.com"     strEmail = Request.ClientCertificate("SubjectE")     If InStr(strEmail, strValidDomain, 1) Then         ' Certificate contains @exair.com in         '  user's e-mail name.         Response.Write("You have access!")     End If %> 

In this example, the e-mail address cheryl@exair.com would be allowed access, but cheryl@microsoft.com would not.

You should be aware that simply checking a name or another entity in a certificate is insecure. An application should also check the issuer of the certificate. This is a cryptographic operation performed by IIS. If you don't check the issuer, you have no way of knowing that the certificate was issued by someone you trust, such as Thawte, VeriSign, or perhaps your own certification authority, and not by a bogus certification authority issuing certificates to all and sundry! Anyone could use, say, Microsoft Certificate Services to issue a certificate with a subject e-mail name of cheryl@exair.com, but if the Web server doesn't trust the issuer the connection will fail.

In the preceding example, the Exploration Air Web site trusts certificates issued by the Exploration Air User Certification Authority only. In IIS 5, you can configure which roots are trusted by the Web server by using a certificate trust list (CTL). A CTL is a CryptoAPI 2.0 data structure containing a list of root certification authority certificates that have been deemed trustworthy by an administrator. You can set different CTLs on a per-Web site basis. CTLs can be managed at the Web site level, not for individual virtual directories, files, or any service other than the Web service.

The Active Server Pages ClientCertificate Collection

As discussed, ASP exposes a collection of client certificate information through the ClientCertificate collection. This information includes the following:

  • The raw certificate data using Request.ClientCertificate("Certificate")
  • Client certificate issuer information (that is, who issued the certificate to the subject) using Request.ClientCertificate("IssuerX") where X is a subcode discussed below
  • Client certificate subject information (that is, the principal using the certificate) using Request.ClientCertificate("SubjectX") where X is a subcode discussed below
  • The certificate serial number using Request.ClientCertificate("SerialNumber" )
  • The certificate validity period using Request.ClientCertificate("ValidFrom") and Request.ClientCertificate("ValidTo")
When using the Issuer and Subject keys, you can also use subfields such as C for country, CN for common name, O for organization, and so on. Refer to the sidebar on X.500 Naming in Chapter 15 for more subfield options.

WARNING
If you perform many-to-one client certificate mapping, it's highly recommended that you have only one root CA certificate in the CTL so that the name matching is unambiguous.

If you do not set a CTL on a Web server, all client authentication certificates are considered valid.

You can add new CTLs to IIS 5 in two ways: using the CTL wizard from within the IIS tool or using the wizard from within the Global Policy tool. We'll look at the former simply because it's built into IIS, because Global Policy requires Active Directory, and because you cannot create CTLs by using local security policy. Refer to the Windows 2000 online help if you want to use Global Policy to define CTLs.

NOTE
It is recommended that you use the IIS tool to perform CTL manipulation of IIS-specific CTLs, because fewer steps are required than when using Global Policy.

You can create and edit CTLs from within the IIS tool by following these steps:

  1. Right-click the My Computer icon on the desktop of the computer for which you have administrative privileges.
  2. Choose Manage from the context menu.
  3. Expand the Services And Application node.
  4. Expand the Internet Information Services node.
  5. Right-click the Web server in question.
  6. Choose Properties from the context menu.
  7. Click the Directory Security tab.
  8. Click the Edit button in the Secure Communications box. If this option is grayed out, you have not yet selected a server certificate to use for SSL/TLS communication.
  9. Check the Enable Certificate Trust List option.
  10. Click the New button to create a new CTL; this will invoke the CTL wizard. Or click Edit to edit an existing CTL.

You can now add and remove root CA certificates to the CTL. Any root CA certificate you add to a CTL assigned to a Web site is trusted by that Web site for client authentication certificates.

Figure 5-12 shows the CTL wizard being used from within the IIS tool.

click to view at full size.

Figure 5-12. Using the CTL wizard within IIS.

By default, IIS 5 will check to see whether a client authentication certificate has been revoked. If so, it will return a 403.13 error: Client certificate revoked. If IIS cannot reach the location of the certificate revocation list (CRL) defined in the client authentication certificate—the CRL distribution point, or CDP—it will assume the worst: the CDP has been attacked and taken off line. Because of this, IIS will issue a 403.13 error even if the certificate has not been revoked, unless there is a current copy of the CRL cached by IIS indicating that the certificate has not been revoked.

Figure 5-13 shows the process more clearly.

Alternate Means of Manipulating CTLs

You can create and manipulate CTLs from languages such as C++ by using the CryptoAPI 2.0 certificate trust list functions, such as CertAddCTLContextToStore, CertDeleteCTLContextFromStore, and CertFindCTLInStore.

You can also use the MakeCTL and CertMgr tools included with the Microsoft Platform SDK to view, create, and manipulate CTLs.

Refer to the MSDN CDs or DVD, or to http://msdn.microsoft.com for further information on these functions and tools.

click to view at full size.

Figure 5-13. The certificate revocation process performed by IIS 5.

You can disable certificate revocation checking on each Web site by using ADSI; this is not configurable from the user interface. The following code shows how to disable CRL checking:

 Set oWeb = GetObject("IIS://localhost/W3SVC/1") oWeb.CertCheckMode = 1 ' 0 == check CRL; 1 == don't check CRL. oWeb.SetInfo Set oWeb = Nothing 

Client certificate mapping

IIS 5 allows the Web site developer to use client authentication certificates as strong authentication credentials. This process is called certificate mapping because the certificate information is used to map to a Windows 2000 account, at which point the Web site user is accessing resources in the context of the mapped account.

IIS 4 provides a simple method to map client certificates, which IIS 5 also uses. However, it is Microsoft's intention to phase out this method in favor of the Active Directory mapping available in IIS 5, which is even easier to use. Let's look at both options.

WARNING
The two mapping methods are mutually exclusive; you cannot mix them. Therefore, you should determine which method is right for your application before you start building it.

IIS mapping, also available in IIS 4, works in one of two modes: one-to-one mapping and many-to-one mapping. When using one-to-one mapping, IIS looks at the client certificate and, based on its entire contents, uses the certificate to log a user account onto the system. For example, you can say that certificate A maps to cheryl@development.exair.com and certificate B maps to michael@ development.exair.com. This method is quite flexible because you can also say that certificate C and certificate D both map to dev-team@development.exair.com. The downside of this model is scalability: IIS needs to store a copy of each certificate used for mapping purposes, which limits the number of certificates to about 2000-3000.

NOTE
Subject name information held in the certificate is not used to directly identify the client. Indeed, the certificate might reference cheryl@development.exair.com, but you might choose to map the certificate to dev-team@development.exair.com.

Many-to-one certificate mapping is based on rules. The administrator defines a series of certificate content rules and uses these rules to map to a Windows 2000 account. For example, the administrator might define a rule such that all client authentication certificates created by the Exploration Air User CA (that is, the only trusted root in this example) with an organization of ExAir (O = ExAir) and an organizational unit of Development (OU = Development) map to the dev-team@development.exair.com account.

The downside with both of the IIS 4 legacy certificate mapping methods is high administrative overhead: the administrator must enter the user account and the password of each account used in the mapping process. Further overhead is incurred because administrators often incorrectly enter passwords and usernames. Nonetheless, the many-to-one mapping method is supremely flexible.

NOTE
IIS certificate mapping will work with or without Active Directory installed.

Let's look at an example of setting up IIS certificate mapping. We'll set up an IIS server to map all certificates that have the following properties:

  • They are issued by the Exploration Air User CA.
  • They have an organizational unit (OU) set to Development.
  • They have an organization (O) set to ExAir.

This involves setting a CTL on the Web server in question that contains the Exploration Air User CA only, which satisfies requirement 1, and setting two rules to satisfy requirements 2 and 3. First we need to set up the CTL by performing the following steps; this is performed only once per Web site and is a Web site policy.

  1. Right-click the My Computer icon on the desktop, and choose Manage from the context menu.
  2. Expand the Services And Applications node, and then expand the Internet Information Services node.
  3. Right-click the Web server (not the virtual directory or directory) you want to apply certificate mapping to.
  4. Choose Properties from the context menu, and click the Directory Security tab.
  5. Click Edit in the Secure Communications box. If this button is disabled, you have yet to assign a server certificate to the Web site. If this is the case, refer to the section later in this chapter on configuring SSL/TLS in IIS.
  6. Select the Enable Certificate Trust List check box, and then click the New button.
  7. When the CTL wizard comes up, click Next.
  8. Click Add From Store to select the Exploration Air User CA certificate. At this stage, you will add the root certificates you trust.
  9. NOTE
    It is recommended that you have only one root certificate listed in the CTL when performing certificate mapping.

  10. Click Next.
  11. Enter a friendly name and description from the CTL—for example, Client Certificate mapping trusted roots and Root certificates trusted for client certificate mapping. Then click Next.
  12. Click Finish.

Now that we have set the CTL, only client certificates issued by CAs listed in the CTL can be used on this Web site. This satisfies the first requirement. Figure 5-14 shows what the Secure Communications dialog box should look like after applying these settings. Figure 5-15 shows what the CTL dialog box looks like after you've added the Exploration Air root certificate.

click to view at full size.

Figure 5-14. Requiring client certificates and using them for mapping.

click to view at full size.

Figure 5-15. Setting valid root certificates for certificate mapping using a CTL.

To satisfy the other two requirements and set the rules, perform the following steps while still in the Secure Communications dialog box:

  1. Select the Require Secure Channel (SSL) check box.
  2. Select the Require Client Certificates radio button.
  3. Select the Enable Client Certificate Mapping check box.
  4. Click the Edit button in the Enable Client Certificate Mapping box.
  5. Click the Many-to-1 tab.
  6. Click Add.
  7. Enter ExAir Mapping Rules.
  8. Click Next.
  9. Click New.
  10. Select Subject in the Certificate Field combo box and O in the Sub Field combo box, type ExAir in the Criteria field, and click OK.
  11. Once again, click New to enter the next rule.
  12. Select Subject in the Certificate Field combo box and OU in the Sub Field combo box, enter Development in the Criteria field, and click OK.
  13. Click Next.
  14. Make sure the Accept This Certificate For Logon Authentication radio button is selected.
  15. Click Browse, and select the account to which you want to map this set of rules. In our example, we're going to use the dev-team account.
  16. Enter the password for the dev-team account.
  17. Click Finish.
  18. Reenter the password, and click OK.
  19. Click OK.

Now when IIS sees a client certificate matching the criteria defined above, it will log on the dev-team account.

Figure 5-16 shows what the certificate mapping rules dialog box should look like after entering these rules.

IIS also provides a COM+ object to ASP applications for manipulating certificate mapping. Called IIsCertMapper, this object does exactly the same job as one-to-one certificate mapping, but it does so programmatically. The process is simple: you pass a client certificate to the object and provide the object with a username and a password. IIS will automatically attempt to log the user account on to the system when it encounters the client certificate at the start of the SSL/TLS connection. The user account making the call to this object must be a member of the administrator's group.

click to view at full size.

Figure 5-16. A series of certificate mapping rules.

The following, somewhat contrived, sample ASP code requires that IIS be configured to request a client certificate. It then uses the information provided by the user to create a certificate mapping. The data (username, password, and friendly mapping name) is passed to the ASP page as part of the HTTP query string; it could be passed as part of a forms POST instead.

 <%      ' Get the client certificate from the connection.     Dim oCert     oCert = Request.ClientCertificate("Certificate")     If Len(oCert) Then         Dim oMap         Set oMap = _             GetObject("IIS://localhost/w3svc/1/IIsCertMapper")         Dim strUser, strPassword, strMappingName         strUser = Request.QueryString("MapUser")         strPassword = Request.QueryString("MapPassword")         strMappingName = Request.QueryString("MapName")         ' Create an account mapping based on the certificate.         oMap.CreateMapping oCert, strUser, strPassword, _             strMappingName, 1         Response.Write "Done!"     Else         Response.Write "No Client Certificate received."     End If  %> 

Other security settings could be added to this code; for example, the administrator could add ACLs to the ASP page to make sure that only valid users can perform this task. In addition, a check could be made that the account name is derived from the certificate itself rather than the account name entered by the user. For example,

 strUser = Request.ClientCertificate("SubjectE") 

will get the e-mail name held in the client certificate and use it to create the mapping.

Now let's turn our attention to the new certificate mapping capability of IIS 5: Active Directory client certificate mapping, also called Windows Directory Service mapping. Active Directory client certificate mapping uses client certificate information held in Active Directory to map to a user account. For example, suppose that an account, michael@development.exair.com, has a client certificate associated with it in Active Directory. If IIS is configured to use Active Directory mapping, it will compare specific information held in the client certificate and presented during the SSL/TLS handshake phase with client certificate information in Active Directory. If Active Directory finds an account with the appropriate certificate information, it will automatically log the account on. Unlike the IIS client certificate mapping methods, there's no need to enter a password for the user account being mapped to.

So, how does it work? Active Directory client certificate mapping operates in two ways:

  • An Active Directory lookup of the Subject name in the certificate finds the Active Directory user in the directory by that name. This is very fast.
  • An Active Directory search of the Subject Alternative Name in the certificate finds a match for the user in Active Directory.

Once a match is found, by either method, the Local Security Authority Subsystem (LSASS.EXE) automatically maps the client certificate to the appropriate Windows 2000 account; no other administrative intervention is required.

Active Directory client certificate mapping is much easier to configure than IIS client certificate mapping simply because there's little administration overhead. Here are the requirements:

  • Windows 2000 Active Directory is populated with user and associated client authentication certificates.
  • IIS is configured to use Active Directory rather than IIS client certificate mapping.

Selecting Multiple Authentication Schemes

In all versions of IIS, you can select more than one authentication scheme—for example, you could opt to use both Basic and Integrated Windows authentication. This is perfectly valid, but note that if you select more than one authentication scheme, the browser can use any of them. In this example, the browser can choose either Basic or Integrated Windows. According to the HTTP specification, it should select the strongest authentication protocol it understands, but don't rely on this. Internet Explorer, for example, chooses the first authentication protocol it understands.

Select the authentication protocols you are happy supporting. If you think Basic authentication is too weak for your application, do not enable it as an authentication option in IIS. Also, if you select anonymous access authentication and another scheme such as Basic authentication, IIS will try anonymous access first; if anonymous access fails because of an ACL conflict, it will try Basic authentication.

Client certificate mapping is a little different because it does not use a series of HTTP authentication headers to determine the client's identity; rather, it's part of the SSL/TLS handshake. Because of this, you need not select any authentication scheme when using client authentication certificates. If the certificate mapping fails, the connection simply fails.

Once Active Directory client certificate mapping is enabled, IIS will no longer use any other IIS-specific mapping rules you have configured. Note also that the client certificates used for both IIS and Active Directory client certificate mapping can be held in software or on smart cards.

To configure IIS to use client certificates held in Active Directory, perform the following steps:

  1. Right-click the My Computer icon on the desktop.
  2. Choose Manage from the context menu.
  3. Expand the Services And Applications node.
  4. Right-click the Internet Information Services node, and choose Properties from the context menu.
  5. Select WWW Services Master Properties, and click the Edit button.
  6. Click the Directory Security tab.
  7. Select the Enable The Windows Directory Service Mapper check box, as shown in Figure 5-17.

click to view at full size.

Figure 5-17. Enabling Active Directory clientcertificate mapping in IIS

While we're on the subject of SSL/TLS and client authentication certificates, we should take a moment to look at how to configure SSL/TLS in IIS.



Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
Designing Secure Web-Based Applications for Microsoft Windows 2000 with CDROM
ISBN: N/A
EAN: N/A
Year: 1999
Pages: 138

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net